Plusieurs façons de faire du « SSO » dans SharePoint

La première, par défaut et qu’une majorité d’entreprises utilise. C’est la méthode via authentification par NTLM classique. En effet, nombreuses sont les entreprises qui ont une infrastructure de domaine Active Directory, des postes joints au domaine, etc.

Comment fonctionne cette méthode ?

Lorsque les applications web SharePoint sont inscrites dans des zones de confiance, qui se fait via les options de sécurité des options Internet à travers le menu Outils d’Internet Explorer, ce dernier va rejouer automatiquement le jeton d’identification dont il dispose. L’utilisateur est donc ré-identifié de manière transparente lorsqu’il passe d’une application web à une autre (mais ce n’est pas un « vrai » SSO dans le sens où une identification est rejouée à chaque premier accès à la ressource).

Vient ensuite une méthode plus complexe et assez connue, Kerberos, qui demande plus de configuration que la précédente (vous trouverez des tutoriels sur internet). Il existe plusieurs modes mais voici le fonctionnement global de cette technologie : Le client s’authentifie auprès du KDC, il obtient un ticket de type TGT, il tente d’accéder à la ressource, les mécaniques Kerberos agissent en amont et le client présente son TGT, qui est validé par des mécaniques de confiance. Ceci donne lieu à un TGS qui est renvoyé au client et présenté par le client à la ressource à laquelle il veut accéder. Lorsque le client veut accéder à une seconde ressource, il présente son TGT, obtient un second TGS et accède à la ressource…

Le tout sachant que Kerberos peut s’appuyer sur une installation Active Directory pour procéder à l’identification en vue de délivrer initialement le TGT.

AspNetMemberShip/Authentification par formulaires : Permet l’authentification d’un utilisateur via un formulaire web en s’appuyant sur une base d’identification pour laquelle le fournisseur a été développé. (Ex : Active Directory, base SQL…) Selon le fournisseur utilisé/développé il est possible que les sessions soient stockées dans le STS SharePoint afin de faire du SSO mais cela demande une configuration assez particulière et/ou ne permet pas d’utiliser les comptes Active Directory et/ou demandera un développement supplémentaire. (Et en fait, il utilisera les mécaniques claims pour la partie SSO)

Reverse proxy : Voici une autre méthode alternative et non incluse nativement dans SharePoint. Cette méthode consiste à mettre un reverse proxy entre SharePoint et les clients De cette façon, le reverse proxy pourra stocker et rejouer les informations d’identification à SharePoint au besoin. Nous rejouons les jetons comme via la zone de confiance Internet Explorer mais de manière sécurisée et sur Internet. Cette solution est une fonctionnalité de ForeFront TMG 2010 et se retrouve dans bon nombre d’appliances de sécurité.

Revendication (Claims) / Fournisseur d’identités tiers : L’idée est de faire confiance à une infrastructure tierce ou à un ensemble d’infrastructures qui auront la possibilité de délivrer, transmettre et rejouer des jetons d’identification Le mode d’authentification par revendication est basé sur les mécanismes SAML (Lien Wiki). Utilisés et poussés par AD FS, ces mécanismes ont un avantage puisqu’ils permettent d’encapsuler des jetons ou des propriétés (et c’est pour cela qu’on retrouve à nouveau NTLM et KDC dans ce mode), délivrés par d’autres bases d’authentification/d’identification, nous y reviendrons en détail un peu plus tard.

Après avoir défini et compris le fonctionnement des différentes méthodes d’authentification, nous avons donc pris en compte certaines contraintes et exigences pour déterminer notre mode d’authentification. Mon choix s’est porté sur la revendication. Pourquoi ?

– La problématique initiale faisant référence à des utilisateurs provenant d’Internet les solutions NTLM et Kerberos étaient forcément proscrites.

– La solution se doit de limiter au maximum le développement, le but étant d’utiliser les comptes Active Directory comme base d’authentification.

– L’utilisation d’un Reverse Proxy de type Forefront TMG n’est pas envisageable non plus du fait de son coût hors budget pour ce projet.