jueves, 6 de septiembre de 2012

The Saml2SecurityToken is rejected because the SAML2:Assertion's NotBefore condition is not satisfied

Actualmente estamos convirtiendo una aplicación ASP.NET Web Forms para usar Identidad Federada con ACS (Access Control Service). Durante el proceso (que aún no termina), hemos encontrado con muchos issues que poco a poco fuimos resolviendo.

Recientemente me encontré con esta exception y muy poca información en Internet:

ID4147: The Saml2SecurityToken is rejected because the SAML2:Assertion's NotBefore condition is not satisfied.
NotBefore: '9/6/2012 1:03:00 AM'
Current time: '9/5/2012 8:01:55 PM'

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: Microsoft.IdentityModel.Tokens.SecurityTokenNotYetValidException: ID4147: The Saml2SecurityToken is rejected because the SAML2:Assertion's NotBefore condition is not satisfied.
NotBefore: '9/6/2012 1:03:00 AM'

Current time: '9/5/2012 8:01:55 PM'

Este error ocurría después de autenticar satisfactoriamente al usuario contra el proveedor de Identidad (ADFS) y al intentar validar el token emitido, WIF (Windows Identity Foundation) lanzaba esta exception.

Básicamente, el error ocurre porque el Token emitido por el Identity Provider (ADFS en nuestro caso) tiene una fecha futura respecto al servidor donde está hosteada la aplicación (Relying Party). Esto es cierto porque el ADFS que estamos usando está en Inglaterra y la aplicación que valida el Token emitido está en Argentina y obviamente hay una diferencia horaria.

Desafortunadamente solo encontré un post relevante con este mismo issue donde como solución recomendaban que actualice la hora de la máquina.
http://social.msdn.microsoft.com/Forums/en-CA/windowsazuresecurity/thread/f25e9b1b-0063-41f8-98a9-6c26af94bbf2

Después de largas horas de desorientación, recordé un issue similar con WCF y entonces encontré una solución al problema gracias al elemento maximumClockSkew que permite especificar un desfasaje de hora para el token. He agregado la siguiente configuración al web.config de mi aplicación (Relying Party):

<microsoft.identityModel>
<service>
<maximumClockSkew value="23:59:59" />
Con esta configuración estoy indicando hasta casi 24 horas de diferencia para la validación del token.
Después de reiniciar el web server, intenté nuevamente y la aplicación funcionó correctamente!!!
Espero esto sea util para alguien que esté lidiando con estos temas. 
Comentarios y sugerencias son bienvenidos.
Saludos, Gustavo

No hay comentarios: