Le Post Infeeny

Les articles des consultants et experts Infeeny

Hit the ground running with Claims authentication in SharePoint 2010

Session animée par Steve Peschka

Cette session décrit le paramétrage de l’authentification Claims du début à la fin.

On utilise ici ADFS. Nous avons d’abord droit à la description des différentes étapes de l’installation côté ADFS.

On peut ensuite à la démo, c’est quand même plus parlant.

Dans l’interface d’administration de ADFS, on va dans « relying party trust » et on crée une nouvelle entrée en spécifiant son nom, le certificat utilisé, …

Dans le paramétrage de l’url, on spécifie l’url du site SharePoint <URL>/_trust/   qui va utiliser nôtre authentification ADFS  puis on spécifie son identifiant (ex : urn :spc11:sharepoint)

On édite ensuite les règles pour en ajouter une de type « Active Directory ».

Il faut ensuite mapper les attributs LDAP avec des types de claims (email, name, …).

La « relation de confiance » entre SharePoint et ADFS est maintenant en place.

Maintenant, on exporte le certificat utilisé pour l’importer côté SharePoint par la suite

Retour au slide…

Nous devons ajouter ce certificat dans le SPTrustedRootAuthority.

Attention, on doit le faire pour tous les certificats de la chaine. Pour les connaitre, il faut consulter les parents du premier certificat.

Pour ajouter un certificat on utilise la commande PowerShell « New-SPTrustedRootAuthority ».

Un point à connaitre : quand le token SAML est présenté au STS (Security Token Service) de SharePoint, seuls les claims qu’on lui a spécifiés explicitement sont conservés.

Pour cela, on utilise de nouveau PS et on crée un mapping: $map=New-SPTrustedTypeMapping –IncomingClaimType « toto ».

On peut évidemment définir plusieurs mappings.

Les claims du token SAML qui ne sont pas mappés côté SharePoint seront ignorés.

On choisit les claims on fonction des besoins de l’entreprise.

On va créer ensuite le SPTrustedIdentityProvider.

C’est lui qui contient toute la configuration SAML

  • Quelle url pour s’authentifier
  • Quel certificat est utilisé pour signer le Token
  • Quel realm utilisé…

Quelques commandes PS de plus…

La configuration des claims SAML est maintenant terminée.

On peut soit utiliser une nouvelle Web application, soit reparamétrer une Web app existante.

Quelques limites des certificats de « Token signing » :

  • Il ne peut être utilisé qu’avec 1 seul Trusted Identity Token Issuer
  • ADFS ne supporte qu’un seul certificat de « Token signing » principal

On utilise de nouveau Powershell  pour ajouter un nouveau realm associé à notre site collection.

Attention les mappings de claims ne peuvent être mutés.

Nous avons droit à la modification du Token issuer depuis l’administration centrale SharePoint.

On aborde ensuite le cas du people picker.

Il faut savoir que ça ne fonctionne pas très bien « Out of the box ».

Par exemple, la recherche va remonter les utilisateurs en indexant tous les champs.

Jusque-là, tout va bien sauf que si le mot recherché est présent dans  3 claims types, le people picker va remonter 3 résultats !!!

Le workaround :  faire son propre claims provider et faire soit même la recherche. Facile J !

Comment faire son propre provider ? Quelques liens sont proposés pour nous venir en aide.

Steve nous montre un exemple de Powershell pour  faire de notre provider celui  par défaut.

Troubleshooting claims, un exemple : SharePoint n’indique pas la collection de claims qu’il recoit.

On peut activer le logging ADFS pour qu’ils soient visibles dans l’event viewer.

Il montre comment faire et que les types de claims sont bien visibles dans l’event viewer.

Pour s aider, il a développé 2 composants :

  • Un HttpModule qui énumère les claims
  • Une Webpart qui les énumère

Retour à une démo…

Nous allons maintenant avoir droit à un exemple d’authentification depuis Windows live ID, Google, Yahoo,  Facebook, …

Il s’authentifie dans Google et il est authentifié dans SharePoint grâce à l’utilisation des Claims.

Idem avec Facebook…

Un nuage affiche les interactions possibles entre Facebook, Google, SharePoint, Azure, SQL Azure qui peuvent tous communiquer entre eux grâce à l’utilisation de SAML.

Une feature Partner Access permet d’utiliser l’authentification SAML dans Office 365.

On nous présente ensuite un exemple d’architecture pour les accès partenaires avec 2 fermes SharePoint, un STS Microsoft, 2 STS de clients, 2 STS de partenaires.

Apparemment, les possibilités sont multiples.

Quand on s’identifie avec un SAML Trusted Identity Provider  et que les métadonnées du user profile sont vides, certains claims types sont copiés automatiquement : work e-mail, job, name, …

S’il a déjà des valeurs, rien ne sera écrasé.

Il nous montre ensuite un exemple de people picker amélioré avec des claims envoyés à un service WCF.

Pour résumer la session : vive l’authentification Claims 🙂

3 réponses à “Hit the ground running with Claims authentication in SharePoint 2010

  1. David 20 janvier 2012 à 16 04 17 01171

    Bonjour,

    la vidéo de cette session est-elle dispo en ligne ?
    j’ai cherché sur le site de la BUILD mais ne l’ai pas trouvée

    Merci d’avance

    David

  2. marcyeuillaz 24 janvier 2012 à 14 02 33 01331

    Bonjour,

    Il s’agit d’une session présentée lors de la SharePoint Conference et non la BUILD.
    Elle n’est, à ma connaissance, plus disponible.

    Je t’invite à faire un tour sur le blog de Steve Peschka (http://blogs.technet.com/b/speschka/archive/tags/claims/) qui contient pas mal d’informations sur l’authentification par claims.

    Marc

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :