SharePoint et le SSO : la pratique
Nous allons maintenant rapprocher la théorie des claims avec leur mise en pratique dans SharePoint en décortiquant ses composants pour mieux comprendre comment SharePoint vient s’articuler avec AD FS.
1) Les Applications de Service
Petit rappel, vous vous souvenez qu’au début de cette série j’évoquais deux types de SSO : inter-web app et accès à une ressource. Nous traitons dans cette série du premier cas de figure, mais sachez que le Secure Store Service Application sert à stocker/paramétrer des credentials et/ou des transmissions de credentials pour accéder à des ressources externes depuis SharePoint sans avoir à se reloguer.
Revenons au vif du sujet, le SSO entre Web Apps. La Security Token Service Application sert quant à elle de RP-STS, ou du moins partiellement. Elle va permettre de centraliser et d’unifier les communications et les configurations des/avec les IP-STS. Elle matérialise essentiellement tout ce qui est information à propos des fournisseurs d’authentification.
Puisque nous sommes encore dans les applications de service et pour éviter toute confusion, vous n’êtes pas sans savoir qu’il existe deux autres applications de service :
State Service : (et son proxy) permet de faciliter les communications et transmissions de données entre les différentes WebApp, base de données. Elle est également obligatoire pour faire fonctionner les forms services.
Session State Service : (Non activé et caché par défaut) permet la transition de données de sessions entre plusieurs instances d’une même WebApp (topologies à plusieurs serveurs frontaux) et pour certaines solutions spécifiques.
Ces deux briques ne sont pas des éléments indispensables pour pouvoir faire du SSO sur SharePoint mais peuvent rapidement être nécessaire pour d’autres briques Sharepoint. Pour plus de détails sur le SharePoint Session State : https://blogs.msdn.com/b/markarend/archive/2010/05/27/using-session-state-in-sharepoint-2010.aspx
2) Les services
En termes de services Windows, nous en avons deux à disposition :
Le Secure Store Service (qui porte la service app du même nom)
Le « Claims to Windows Token Service » qui permet la conversion des jetons de revendications en jetons NTLM lorsqu’un utilisateur connecté sur une web app en claims accède à une ressource qui ne gère pas le NTLM (Exemple : dans le cadre d’une liste externe)
Aucun de ces deux services n’est obligatoire dans le cadre de notre « simple » SSO inter web app.
3) Les web apps
Enfin les web apps SharePoint constituent la deuxième partie du RP-STS. C’est d’ailleurs l’utilisation du répertoire virtuel /_trust/ qui permet la récupération du jeton lors du rappel de l’IP-STS.
4) Récapitulatif
En résumé pour faire fonctionner notre SSO inter web app sur SharePoint nous avons besoin :
- D’une (ou plusieurs) web app configurée en mode claims
-D’une application de service Secure Token Service démarrée
D’un service AD FS fonctionnel avec la base d’identification correctement configurée et un (ou plusieurs, un par web app) RP-STS configuré
D’un certificat HTTPS/SSL valide par web app + 1 certificat pour la web app qui porte le IP-STS
D’une IP par web app qui fera partie du SSO + 1 pour l’IP-STS (contrainte due à la manière dont IIS gère le SSL dans ses bindings)
D’un ou plusieurs fournisseur d’authentification configurés côté SharePoint (dans notre cas un seul avec un domaine d’identification par web app)