saml saml-2.0

saml - NotOnOrAfter en SubjectConfirmationData and Conditions and SessionNotOnOrAfter



saml-2.0 (2)

En la especificación SAML2 hay varios lugares en una aserción donde es posible especificar una vida útil.

  • El elemento <SubjectConfirmationData> contiene un atributo NotOnOrAfter .
  • El elemento <Conditions> contiene un atributo NotOnOrAfter .
  • El elemento <AuthnStatement> contiene un atributo SessionNotOnOrAfter .

¿Cuál es el significado de cada uno de ellos? ¿Cómo se relacionan entre sí?

Específicamente, cuál de ellos debe ser revisado cuando ...

  • ... consumiendo un Saml2Response entrante utilizando Web SSO
  • ... estableciendo una sesión de aplicación en el SP
  • ... refrescando (extendiendo) una sesión de aplicación en el SP
  • ... reenviar una aserción a un servicio web, para actuar en nombre del sujeto (como lo describe @Thuan)
  • ... emitir una única solicitud de cierre de sesión al idp, para garantizar que el idp todavía sepa de la sesión?

Cada uno de los NotOnOrAfters se describe en la especificación principal de SAML2 . He incluido las partes que puedo encontrar que describen estos atributos aquí.

SubjectConfirmationData / @ NotOnOrAfter

Un instante de tiempo en el que el sujeto ya no puede ser confirmado. El valor de tiempo se codifica en UTC, como se describe en la Sección 1.3.3.

Tenga en cuenta que el período de tiempo especificado por los atributos opcionales NotBefore y NotOnOrAfter, si están presentes, DEBE estar dentro del período de validez de aserción general según lo especificado por los atributos NotBefore y NotOnOrAfter del elemento. Si ambos atributos están presentes, el valor para NotBefore DEBE ser menor que (antes que) el valor para NotOnOrAfter.

Condiciones / @ NotOnOrAfter

Especifica el instante de tiempo en el que ha caducado la aserción. El valor de tiempo se codifica en UTC, como se describe en la Sección 1.3.3.

Los atributos NotBefore y NotOnOrAfter especifican límites de tiempo en la validez de la aserción dentro del contexto de su (s) perfil (es) de uso. No garantizan que las declaraciones en la aserción serán correctas o exactas durante todo el período de validez. El atributo NotBefore especifica el instante de tiempo en el que comienza el intervalo de validez. El atributo NotOnOrAfter especifica el instante de tiempo en el que ha finalizado el intervalo de validez. Si se omite el valor para NotBefore o NotOnOrAfter, entonces se considera no especificado. Si el atributo NotBefore no está especificado (y si todas las demás condiciones que se suministran se evalúan como válidas), la aserción es válida con respecto a las condiciones en cualquier momento antes del instante de tiempo especificado por el atributo NotOnOrAfter. Si el atributo NotOnOrAfter no está especificado (y si todas las demás condiciones que se suministran se evalúan como válidas), la aserción es válida con respecto a las condiciones del instante de tiempo especificado por el atributo NotBefore sin vencimiento. Si no se especifica ninguno de los atributos (y si cualquier otra condición que se suministra se evalúa como válida), la aserción es válida con respecto a las condiciones en cualquier momento.

Si ambos atributos están presentes, el valor para NotBefore DEBE ser menor que (antes que) el valor para NotOnOrAfter.

AuthnStatement / @ SessionNotOnOrAfter

Indica un límite superior en las sesiones con el tema derivado de la aserción adjunta. El valor de tiempo se codifica en UTC, como se describe en la Sección 1.3.3. No hay una relación requerida entre este atributo y un atributo de condición NotOnOrAfter que puede estar presente en la aserción. Se deja a los perfiles para proporcionar reglas de procesamiento específicas para las partes dependientes basadas en este atributo.

En mi opinión, solo los autores de la especificación Saml2 pueden responder claramente a esta pregunta. También creo que pueden escribir un libro de 10000 páginas para explicar muchas preguntas "por qué" sobre las especificaciones que las personas han preguntado durante años. De todos modos, en base a mi conocimiento limitado y en los casos de uso que he experimentado, mi interpretación de esas propiedades es:

Veamos un ejemplo:

  1. SSO: un SP recibe una aserción de un IdP e inicia sesión en el usuario.
  2. Token de arranque: el SP guarda la aserción como un token de arranque para su uso posterior.
  3. El SP usa el token de arranque para intercambiar por un token de ActAs para que pueda usarse para acceder a otro servicio web. También almacenará en caché el token para otros usos para evitar tener que intercambiar un token nuevo a menudo, siempre que ese token siga siendo válido.

Para (1), una aserción es válida cuando y solo cuando ambos SubjectConfirmationData.NotOnOrAfter y Conditions.NotOnOrAfter son válidos. Dado que la aserción es válida, el SP creará una sesión de inicio de sesión para el usuario. La duración de la sesión debe estar especificada por el valor SessionNotOnOrAfter.

¿Qué tal 3? Yo diría que el token se considera válido cuando Conditions.NotOnOrAfter sigue siendo válido. Según Scott Cantor: "Las reglas de procesamiento son específicas de los perfiles y el contexto de uso". Fuente: https://lists.internet2.edu/sympa/arc/mace-opensaml-users/2011-05/msg00007.html En ese enlace también se habló sobre las vidas de los sujetos y las condiciones en las que las condiciones generalmente duran más que las La del sujeto.

Crucé esta pregunta en la lista de correo de SAML-dev y obtuve una respuesta de Scott Cantor, que ha sido editor de las especificaciones.

  • Los tiempos en <SubjectConfirmationData> cuánto tiempo se puede vincular la aserción con el sujeto. En el SSO web donde se suele utilizar el método de confirmación de asunto "portador", significa que dentro de este tiempo podemos confiar en que la afirmación se aplica a la que proporciona la afirmación. La afirmación puede ser válida por un tiempo más largo, pero debemos crear una sesión dentro de este marco de tiempo. Esto se describe en la sección 4.1.4.3 del perfil de SSO web . Los tiempos en <SubjectConfirmationData> deben estar dentro del intervalo de aquellos en <Conditions> .

  • Los tiempos en <Conditions> son la validez de toda la aserción. No debe consumirse después de este tiempo. Sin embargo, no hay nada que impida que una sesión de usuario en un SP se extienda más allá de este punto en el tiempo.

  • SessionNotOnOrAfter es algo completamente diferente que no está directamente relacionado con la vida útil de la afirmación o el tema. Es un parámetro que el IDP puede usar para controlar la duración de una sesión de SP. Tenga en cuenta que este parámetro se define que DEBE ser manejado por un SP de acuerdo con la especificación SAML2Core, pero lejos de todas las implementaciones de SP. Un ejemplo de una implementación que hace es como de costumbre Shibboleth, que siempre respetará la aparición de este parámetro. Cuando se utiliza el cierre de sesión único, este parámetro es más crítico, ya que sincroniza el tiempo de espera de la sesión tanto en el SP como en el Idp, para garantizar que un SP no emita una solicitud de cierre de sesión para una sesión que el Idp ya no conoce.