Configuración correcta de la caducidad del token de inicio de sesión para usuarios de notificaciones de SAML de SharePoint 2010

  • Article

Configuración correcta de la caducidad del token de inicio de sesión para usuarios de notificaciones de SAML de SharePoint 2010

Hace poco, mientras intentaba comprender el proceso de caducidad de las cookies de inicio de sesión, encontré lo que parecía un problema bastante grave. Una vez que los usuarios de notificaciones de SAML obtenían la cookie de inicio de sesión de AD FS, parecía que nunca se agotaba el tiempo de espera. Esto significa que podían cerrar el explorador y, al volver a abrirlo varios minutos o incluso horas más tarde, navegar directamente al sitio sin tener que volver a autenticarse en AD FS. Además, las aplicaciones cliente de Office 2010 funcionaban del mismo modo. Al final di con todas las piezas que ocasionaban ese problema, así que decidí documentarlas aquí.

Primero proporcionaré información básica muy breve. Cuando navega a un sitio de SharePoint protegido con notificaciones de SAML por primera vez, se le redirige para autenticarse y obtener las notificaciones. Su proveedor de identidades SAML (también conocido como STS de IP) realiza esas tareas y lo redirige a SharePoint. Cuando vuelve a SharePoint, creamos una cookie FedAuth y, de esta manera, sabemos que ha sido autenticado. Para que la experiencia del usuario final no tenga complicaciones, escribimos el valor de la cookie FedAuth en la carpeta de cookies local. En las solicitudes posteriores de dicho sitio, si encontramos una cookie FedAuth válida para el sitio, la leemos y dirigimos al usuario directamente al contenido de SharePoint, sin necesidad de autenticarse de nuevo. Esto puede sorprender a aquellos que están acostumbrados a AD FS 1.x y SharePoint 2007, porque con ellos todas las cookies SSO web se basaban en la sesión, por lo que no las guardábamos en disco. Por ejemplo, cuando el usuario cerraba el explorador, la cookie desaparecía y el usuario tenía que volver a autenticarse cada vez que cerraba y abría el explorador. Esto no ocurre con SharePoint 2010.

Actualización Nº 1: se encontró un cambio que se puede realizar en STS de SharePoint para que funcione con las cookies de la sesión nuevamente, como ocurría en SharePoint 2007. Con este PowerShell se podrá efectuar el cambio:

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

Después de realizar el cambio, verá que ya no existe una cookie FedAuth escrita en disco. Para que las cosas vuelvan al comportamiento predeterminado, solo debe invertir los pasos:

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

Entonces, ¿cómo se configura este comportamiento para obtener un token deSAML con una duración interesante, que se pueda administrar? Estas son las cosas que debe tener en cuenta:

  1. Se puede establecer la propiedad TokenLifetime por usuario de confianza en AD FS. Lamentablemente, parece que solo se puede establecer en el momento en que se crea el usuario de confianza. Esto es un problema, porque significa que el comportamiento predeterminado es que una vez que obtiene una cookie, es válida por un tiempo realmente largo (todavía no he comprobado exactamente qué validez tiene la cookie).

Actualización Nº 2: Rich Harrison ha tenido la amabilidad de proporcionar este fragmento de código para actualizar TokenLifetime de AD FS para el usuario de confianza:

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

donde "SPS 2010 ADFS" es el nombre de la entidad de confianza del usuario de confianza en AD FS 2.0.

Por lo tanto, si desea establecer TokenLifetime del usuario de confianza en AD FS en el momento de la creación, deberá hacerlo mediante PowerShell. Este es el pequeño script de una línea que usé para crear mi usuario de confianza:

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

Después de crear el usuario de confianza de esta manera, debe realizar manualmente las siguientes tareas:

  1. Agregar el dominio kerberos a la lista de identificadores (por ejemplo, urn:sharepoint:foo)
  2. Agregar una regla de autorización de emisión para permitir el acceso a todos los usuarios
  3. Agregar una regla de transformación de emisión para enviar direcciones de correo electrónico y roles

 

  1. Si intenta iniciar sesión ahora, probablemente notará que después de autenticarse en AD FS, quedará atrapado en este bucle sin fin, en el que debe ir y volver entre SharePoint y AD FS. Si observa el tráfico en Fiddler, verá que se autenticó correctamente en AD FS, volvió a SharePoint y se emitió correctamente la cookie FedAuth, se lo redirigió a /_trust/authenticate.aspx en el sitio de SharePoint que elimina la cookie FedAuth y se lo redirigió de nuevo al sitio de AD FS. Básicamente va y viene hasta que AD FS detiene este proceso y muestra un mensaje de error que dice algo similar a: "La misma sesión de explorador de cliente ha realizado '6' solicitudes en los últimos '12' segundos". En realidad, esto tiene sentido. Ocurre porque el LogonTokenCacheExpirationWindow predeterminado para el STS de SharePoint es 10 minutos. En este caso, cuando creé mi usuario de confianza, establecí la duración del token en AD FS en 2 minutos. Por lo tanto, en cuanto lo autenticó, supe que la cookie era válida por menos tiempo que el valor de LogonTokenCacheExpirationWindow; por eso volvió a AD FS para autenticarlo de nuevo. De esta manera, fue hacia atrás y hacia adelante. Para solucionar el problema, solo necesita cambiar LogonTokenCacheExpirationWindow para que sea menor que TokenLifetime de SAML; luego puede iniciar sesión en el sitio. Aquí se muestra un ejemplo de configuración de LogonTokenCacheExpirationWindow en SharePoint:

$sts = Get-SPSecurityTokenServiceConfig

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

$sts.Update()

Iisreset

 

Entonces, una vez que configura estas opciones correctamente, la caducidad de inicio de sesión para usuarios de SAML funcionará correctamente. Puedo abrir y cerrar la ventana del explorador durante 2 minutos, y volver al sitio sin ser redirigido a SharePoint. Después de ese tiempo, sin embargo, debo volver a autenticarme en AD FS.

Esta entrada de blog es una traducción. Puede consultar el artículo original en Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users