Fonctionnement théorique des revendications (claims), du SAML et d’AD FS
Le fonctionnement diffère selon la version des claims configurée (1.1 ou 2.0). SharePoint supporte les deux dans sa version 2010. Pour les plus curieux d’entre vous les différences entre la v1.1 et la v2 résident dans une amélioration des schémas de descriptions des données et des méthodes de communication (le détail ici https://wiki.shibboleth.net/confluence/display/SHIB/SAMLDiffs ).
Voici brièvement le fonctionnement :
1. Connexion du CLIENT à l’Application Web SharePoint (RELYING-PARTY STS)
2. Vérification par le RP-STS de la présence et de la validité d’un token d’authentification chez le client ET chez le Identity-Provider Secure Token Service (IP-STS).
§ Si ce n’est pas le cas le RP-STS redirige le client vers l’IP-STS (identity provider, son rôle est de délivrer des jetons).
§ Une fois sur l’IP-STS le client s’identifie soit par appel de l’IP-STS fera soit appel à la base d’identification (Active Directory, KDC, forms…) pour vérifier l’identité, soit par remontée en cascade de la demande à un autre IP-STS.
C’est grâce à mise en cascade que l’on peut faire de la fédération d’identité, on pourrait parfaitement imaginer que votre entreprise fasse confiance à ses partenaires pour donner accès à des ressources internes à des intervenants externes.
Vous pourriez aussi faire confiance à des services d’identité (à ne pas confondre avec des fournisseurs d’identité) tels que FaceBook, LiveID etc etc…
3. Enfin le client est authentifié et redirigé vers le RP-STS (notre web application SharePoint) par l’IP-STS ou bien par le client avec le jeton, la mécanique d’autorisation entre en jeu.
Dans le cas où notre client aurait déjà son jeton d’authentification à la première étape, nous pouvons directement passer à la partie autorisation. C’est de cette façon que nous retrouvons le fonctionnement voulu, il n’y a pas besoin de réauthentification. Voilà donc notre Single-Sign-On.
Dernier composant optionnel sur ce schéma, le sélecteur d’identité qui peut être installé sur le client, qui mémorise une partie des jetons et permet à l’utilisateur de choisir le jeton à présenter s’il en a plusieurs sans avoir à retaper le mot de passe. Windows CardSpace est par exemple un sélecteur d’identité.
Détails supplémentaires à connaitre :
Chaque RP-STS est identifié par un IP-STS par un domaine d’identification (realm, de la forme urn:foo:bar que vous définissez vous-même à la manière d’une clef) et par une url d’appel (qui est passée automatiquement par le RP-STS à chaque appel de l’IP-STS)
Pour des raisons de sécurité, tout passe obligatoirement en HTTPS pour la communication.
De manière optionnelle et pour plus de sécurité, il est possible de chiffrer les jetons avec un autre certificat qui seront ensuite chiffrés une nouvelle fois dans le canal HTTPS, mais ce n’est pas obligatoire.
Chaque IP-STS est identifié par un certificat SSL et une url d’authentification auprès d’un RP-STS ou d’un autre IP-STS, du point de vue d’un RP-STS, un même certificat ne peut pas servir pour plusieurs IP-STS. (1 certificat <=> 1 IP-STS)
Remarque importante : AD FS ne peut être installé sur un contrôleur de domaine pour des raisons de sécurité, si l’installation réussit, vous aurez des problèmes de configuration par la suite.
Lien de téléchargement d’AD FS v2 (c’est la version 1 qui est inclue dans Windows Server 2008 R2, et dans notre cas de figure nous avons besoin de la V2)
Je vous conseille de lire ces deux ressources pour améliorerer grandement votre compréhension de la chose :
https://msdn.microsoft.com/en-us/magazine/ee335707.aspx (avant la partie de code, qui est aussi intéressante mais qui s’écarte un peu de notre sujet)