Réglage correct de l’expiration du jeton de connexion pour les utilisateurs des revendications SAML de SharePoint 2010

  • Article

Réglage correct de l’expiration du jeton de connexion pour les utilisateurs des revendications SAML de SharePoint 2010

Alors que j’étudiais le processus d’expiration des cookies de connexion récemment, j’ai découvert ce qui semblait être un problème assez important. Pour les utilisateurs des revendications SAML, une fois qu’ils avaient obtenu leur cookie de connexion auprès d’ADFS, aucun délai d’expiration ne se manifestait. Cela signifiait qu’ils pouvaient fermer le navigateur, puis le rouvrir plusieurs minutes ou même plusieurs heures après et accéder directement au site, sans avoir à s’authentifier à nouveau auprès d’ADFS. En outre, les applications clientes Office 2010 fonctionnaient de la même façon. Je suis finalement arrivé à comprendre les divers éléments qui causaient cela, que je vais documenter ici.

Tout d’abord, voici très brièvement le contexte. Lorsque vous accédez à un site SharePoint sécurisé avec des revendications SAML pour la première fois, vous êtes redirigé pour vous authentifier et obtenir vos revendications. Votre fournisseur d’identités SAML (anciennement IP-STS) effectue ces opérations et vous redirige vers SharePoint. Lorsque vous revenez dans SharePoint, un cookie FedAuth est créé pour indiquer que vous êtes authentifié. Pour rendre l’expérience utilisateur plus conviviale, la valeur du cookie FedAuth est écrite dans le dossier local des cookies. Lors des requêtes ultérieures à ce site, si un cookie FedAuth valide existe pour le site, ce cookie est lu et vous êtes dirigé directement vers le contenu SharePoint sans avoir à vous authentifier à nouveau. Ceci peut faire un choc à tous ceux qui sont habitués à ADFS 1.x et SharePoint 2007, car avec ces versions tous les cookies SSO Web étaient basés sur la session et n’étaient pas enregistrés sur le disque. Lorsque vous fermiez le navigateur, par exemple, le cookie disparaissait et vous deviez vous authentifier à nouveau, et ceci à chaque fermeture et réouverture du navigateur. Ce n’est pas le cas avec SharePoint 2010.

Mise à jour 1 : Nous avons trouvé un changement qui peut être apporté à SharePoint STS pour qu’il fonctionne à nouveau avec les cookies de session, comme c’était le cas dans SharePoint 2007. La commande PowerShell suivante effectue ce changement :

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset

Après l’exécution de cette commande, vous constaterez que le cookie FedAuth n’est plus écrit sur le disque. Pour rétablir le comportement par défaut, il suffit de faire l’opération inverse :

$sts.UseSessionCookies = $false
$sts.Update()
iisreset

Alors, comment configurer ce comportement pour obtenirun jeton SAML ayant une durée de vie gérable convenable ? Voici les éléments à prendre en considération :

  1. La propriété TokenLifetime peut être définie par la partie de confiance dans ADFS. Malheureusement, il semble qu’elle ne soit réglable qu’au moment où vous créez la partie de confiance. Cela constitue un problème, car cela signifie que, par défaut, une fois le cookie obtenu vous disposez de l’accès pour très très longtemps (je n’ai en fait pas testé cette durée de validité).

Mise à jour 2 : Rich Harrison nous a aimablement fourni cette pépite pour mettre à jour la propriété TokenLifetime dans ADFS pour la partie de confiance :

Set-ADFSRelyingPartyTrust -TargetName "SPS 2010 ADFS" -TokenLifetime 5

où "SPS 2010 ADFS" est le nom de l’entité Relying Party Trust (partie de confiance) dans AD FS 2.0.

Donc, si vous voulez définir la propriété TokenLifetime de la partie de confiance dans ADFS au moment de la création, vous devez utiliser PowerShell pour effectuer cette opération. Voici le petit script d’une ligne que j’ai utilisé pour créer ma partie de confiance :

Add-ADFSRelyingPartyTrust -Name "FC1" -Identifier "https://fc1/_trust/" -WsFedEndpoint "https://fc1/_trust/" -TokenLifetime 2 -SignatureAlgorithm https://www.w3.org/2000/09/xmldsig#rsa-sha1

Après avoir créé la partie de confiance de cette manière, vous devez manuellement :

  1. Ajouter le domaine à la liste des identificateurs (c.-à-d. urn:sharepoint:foo)
  2. Ajouter une règle d’autorisation d’émission (Issuance Authorization Rule) pour permettre l’accès à tous les utilisateurs
  3. Ajouter une règle de transformation d’émission (Issue Transform Rule) pour envoyer l’adresse de messagerie et les rôles

 

  1. Si vous essayez simplement et vous connectez maintenant, vous allez probablement découvrir qu’après vous être authentifié auprès d’ADFS, vous êtes pris dans une boucle sans fin de va-et-vient entre SharePoint et ADFS. Si vous observez le trafic dans Fiddler, il s’avère que vous êtes authentifié avec succès auprès d’ADFS, puis revenez dans SharePoint qui émet avec succès le cookie FedAuth, vous redirige vers /_trust/authenticate.aspx sur le site SharePoint qui se débarrasse du cookie FedAuth et vous redirige à nouveau vers le site ADFS. Vous effectuez ce va-et-vient en ping pong jusqu’à ce qu’ADFS l’arrête et vous indique un message d’erreur “The same client browser session has made ‘6’ requests in the last ‘12’ seconds” (La même session de navigateur client a effectué 6 requêtes lors des 12 dernières secondes). Cela s’avère avoir un sens. En effet, la valeur par défaut de LogonTokenCacheExpirationWindow (délai d’expiration en cache du jeton de connexion) pour SharePoint STS est 10 minutes. Dans ce cas, lorsque j’ai créé ma partie de confiance, j’ai défini la durée de vie du jeton dans ADFS à 2 minutes, donc dès l’authentification, le cookie était reconnu comme valide pendant une durée inférieure à la valeur LogonTokenCacheExpirationWindow, d’où le retour vers ADFS pour une nouvelle authentification. Et ainsi de suite... Pour corriger ce point, il suffit de changer la valeur de LogonTokenCacheExpirationWindow pour la rendre inférieure à TokenLifetime (durée de vie du jeton) SAML, puis vous pouvez vous connecter au site. Voici un exemple de réglage de LogonTokenCacheExpirationWindow dans SharePoint :

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

$sts.Update()

Iisreset

 

Maintenant, après avoir configuré ces paramètres correctement, l’expiration de connexion pour les utilisateurs SAML fonctionne correctement. Je peux ouvrir et fermer la fenêtre de mon navigateur et continuer à retourner sur le site sans être redirigé vers SharePoint pendant une période de 2 minutes. Au bout de ce délai, pourtant, je dois bien m’authentifier à nouveau auprès d’ADFS.

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible ici : Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users