Plusieurs types d’authentification/d’identification
Lors de la création d’une Web-App SharePoint, vous avez sûrement remarqué qu’il existe deux méthodes d’authentification réparties dans deux catégories Lien Technet:
Classique : NTLM, Kerberos, Anonyme, de base, digest Lien Technet
Revendication (Claims) : NTLM, Kerberos, de base, AspNet Membership(Formulaires: LDAP, Base SQL, fournisseurs tiers), Trusted Identity Provider (Fournisseur tiers, par jeton SAML) Lien Technet
Petit rappel concernant les différentes méthodes d’authentification :
NTLM : Protocole d’identification très répandu dans les technologies Microsoft, Active Directory se base dessus, https://fr.wikipedia.org/wiki/NTLM , fourni nativement dans SharePoint (aucune configuration nécessaire)
Kerberos : Protocole d’authentification par tickets très répandu dans les infrastructures réseau d’entreprises https://fr.wikipedia.org/wiki/Kerberos , pour le mettre en place dans SharePoint il va falloir effectuer des configurations du côté SharePoint et du côté de votre infrastructure KDC.
De base : Challenge d’identification 401 tel que spécifié dans le protocole HTTP https://fr.wikipedia.org/wiki/HTTP_Authentification , pris en charge nativement dans SharePoint, c’est le mode d’identification utilisé lorsque l’on a des utilisateurs locaux SharePoint.
AspNet Membership/Forms : Authentification par formulaire POST (champs de saisie directement sur la page et non boite d’identification du navigateur comme en Basic), dans SharePoint il s’agit simplement d’utiliser une mécanique/base d’identification standard ASP.Net qui s’appuie généralement sur une base SQL Server ou qu’on peut développer soit même https://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
Trusted Identity Provider : Faire Confiance à un fournisseur tiers pour l’authentification, ceci repose sur les mécaniques claims, je détaille tout cela plus bas car c’est la solution que j’ai choisie.
Digest : méthode consistant à hasher et/ou chiffrer des informations d’identification, cette méthode doit être configurée directement depuis IIS, de plus la méthode d’authentification par certificat n’est pas prise en charge par SharePoint actuellement
L’authentification par revendication est différente de l’authentification en mode classique car elle permet de joindre un ensemble de revendications (claims) à l’identité de l’utilisateur (ex âge, nationalité…) qui pourront être réutilisées par l’application « consommant » cette identité. Si vous partez d’une installation fraiche, il n’y a plus réellement de raison de sélectionner une authentification en mode classique, même si vous n’avez pas besoin de faire du SSO. L’authentification en mode classique a été conservée pour des raisons de compatibilité et de migration. Elle peut être nécessaire pour des problématiques d’accès à des données externes dont l’application ne serait pas compatible (mais là encore il y a le service claims to windows, de plus les applications tendent de plus en plus à intégrer la méthode normée par revendications pour s’affranchir des divers standards)