Security Assertion Markup Language (SAML) es un estándar XML para intercambiar datos de autenticación y autorización entre dominios de seguridad. SAML es un producto del Comité Técnico de Servicios de Seguridad de OASIS (organización) .
SAML 1.1 fue ratificado como estándar OASIS en septiembre de 2003. Los aspectos críticos de SAML 1.1 se tratan en detalle en los documentos oficiales SAMLCore [1] y SAMLBind. [2] Si es nuevo en SAML, probablemente debería leerprimero el temaintroductorio de SAML y luego el documento SAMLOverview [3] de OASIS.
Antes de SAML 1.1, SAML 1.0 se adoptó como estándar OASIS en noviembre de 2002. SAML ha pasado por una revisión menor (V1.1) y una revisión mayor (V2.0) desde V1.0, que en sí mismo es un protocolo relativamente simple. Sin embargo, SAML 1.0 tiene un interés más que histórico, ya que la Iniciativa Federal de Autenticación Electrónica de EE. UU. Ha adoptado SAML 1.0 como su tecnología principal.
Las versiones 1.0 y 1.1 de SAML son similares. Consulte SAMLDiff [4] para conocer las diferencias específicas entre los dos estándares. Este artículo se concentra en SAML 1.1 ya que es un estándar importante del que dependen muchos otros estándares e implementaciones.
Advertencia: los implementadores y los implementadores deben tener en cuenta que todos los ejemplos de código de este artículo no son normativos y solo tienen fines ilustrativos. Consulte las especificaciones SAML de OASIS para conocer los requisitos normativos.
Afirmaciones SAML 1.1
Las afirmaciones de SAML contienen declaraciones que los proveedores de servicios utilizan para tomar decisiones de control de acceso. Por ejemplo, las declaraciones de autenticación afirman al proveedor de servicios que el principal sí se autenticó con el proveedor de identidad en un momento particular utilizando un método particular de autenticación. Se puede divulgar otra información sobre el principal en una declaración de autenticación. En la siguiente declaración de autenticación, por ejemplo, la dirección de correo electrónico del principal se confirma al proveedor de servicios:
xmlns: saml = "urn: oasis: names: tc: SAML: 1.0: assertion" MajorVersion = "1" MinorVersion = "1" AssertionID = "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer = "https://idp.example.org / saml " IssueInstant = " 2002-06-19T17: 05: 37.795Z " > NotBefore = " 2002-06-19T17: 00: 37.795Z " NotOnOrAfter = " 2002-06-19T17: 10: 37.795Z " /> AuthenticationMethod = "urn: oasis: nombres: tc: SAML: 1.0: am: contraseña" AuthenticationInstant = "2002-06-19T17: 05: 17.706Z" > Format = "urn: oasis: names: tc: SAML: 1.1: nameid-format: emailAddress" > [email protected] urna: oasis: nombres: tc: SAML: 1.0: cm: portador
Una dirección de correo electrónico (como en el ejemplo anterior) será suficiente en una gran cantidad de situaciones. En algunos casos, sin embargo, se necesita información adicional antes de que un proveedor de servicios pueda tomar una decisión de control de acceso. Como ejemplo, suponga que los estudiantes pueden acceder a los datos de becas. Una declaración de atributo puede indicar si el director tiene o no una afiliación de "estudiante", que el proveedor de servicios utiliza para permitir o denegar el acceso (resp.) A la solicitud de becas:
xmlns: saml = "urn: oasis: names: tc: SAML: 1.0: assertion" MajorVersion = "1" MinorVersion = "1" Issuer = "https://idp.example.org/saml" .. . > NotBefore = "..." NotAfter = "..." /> AuthenticationMethod = "..." AuthenticationInstant = "..." > ... < / saml: Subject> ... AttributeName = "urn: mace: dir: attribute-def: eduPersonAffiliation" AttributeNamespace = "urn: mace: shibboleth: 1.0: attributeNamespace: uri" > miembro estudiante
Los atributos a menudo se obtienen de un directorio LDAP , por lo que las representaciones consistentes de los atributos en todos los dominios de seguridad son cruciales.
En el ejemplo anterior que muestra cómo un estudiante puede obtener acceso a una solicitud de beca, el proveedor de servicios funciona como un punto de aplicación de políticas y un punto de decisión de políticas . En algunas situaciones, puede ser preferible asociar el punto de decisión de la política con el proveedor de identidad. En este caso, el proveedor de servicios pasa un URI al proveedor de identidad, quien afirma una declaración de decisión de autorización que dicta si se debe permitir o no al principal el acceso al recurso protegido en el URI dado.
xmlns: saml = "urn: oasis: names: tc: SAML: 1.0: assertion" MajorVersion = "1" MinorVersion = "1" Issuer = "https://idp.example.org/saml" .. . > ... /> Decision = "Permit" Resource = "https://sp.example.com/confidential_report.html" > ... leído
Los tres tipos de declaraciones no son mutuamente excluyentes. Por ejemplo, tanto las declaraciones de autenticación como las declaraciones de atributos pueden incluirse en una sola declaración (como se muestra arriba). Esto excluye la necesidad de realizar viajes de ida y vuelta posteriores entre el proveedor de servicios y el proveedor de identidad.
Protocolos SAML 1.1
Un protocolo SAML es un protocolo de solicitud-respuesta simple. Un solicitante SAML envía un Request
elemento SAML a un respondedor:
xmlns: samlp = "urn: oasis: names: tc: SAML: 1.0: protocol" MajorVersion = "1" MinorVersion = "1" RequestID = "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant = "2006 -07-17T22: 26: 40Z " >
De manera similar, un respondedor SAML devuelve un Response
elemento SAML al solicitante:
xmlns: samlp = "urn: oasis: names: tc: SAML: 1.0: protocol" MajorVersion = "1" MinorVersion = "1" ResponseID = "b07b804c-7c29-ea16-7300-4f3d6f7928ac" InResponseTo = "aaf23196 -1773-2113-474a-fe114412ab72 " IssueInstant = " 2006-07-17T22: 26: 41Z " >
Los enlaces y perfiles necesarios para afectar este intercambio de mensajes se detallan en las siguientes secciones.
Enlaces SAML 1.1
SAML 1.1 define formalmente solo un enlace de protocolo , el enlace SAML SOAP. Una implementación de SAML 1.1 compatible debe implementar SAML sobre SOAP sobre HTTP (un enlace de protocolo síncrono). Se permiten otros mecanismos de transporte además de HTTP, siempre que se observen los aspectos independientes del protocolo del enlace SAML SOAP (consulte la sección 3.1.2 de SAMLBind [2] ).
El enlace SOAP de SAML 1.1 se basa en la versión 1.1 de SOAP (la numeración es pura coincidencia). Un solicitante SAML envuelve un Request
elemento SAML dentro del cuerpo de un mensaje SOAP. De manera similar, un respondedor SAML devuelve un Response
elemento SAML dentro del cuerpo de un mensaje SOAP devuelto. Si hay un error, el respondedor devuelve un código de falla SOAP en su lugar.
Cualquier marcado SAML debe incluirse en el cuerpo de SOAP. SAML 1.1 no define ningún encabezado SOAP específico de SAML. Un solicitante es libre de insertar cualquier encabezado SOAP que desee (aunque no se requiere ninguno).
Recuerde que en SOAP 1.1, se SOAPAction
debe incluir un encabezado HTTP con cada solicitud HTTP (aunque su valor puede estar vacío). Un solicitante de SAML puede dar el siguiente valor al SOAPAction
encabezado:
SOAPAction: http://www.oasis-open.org/committees/security
Sin embargo, un respondedor SAML no debe depender de este valor.
No se requiere una conexión segura para las solicitudes y respuestas de SAML, pero en aquellas situaciones en las que se requiere integridad y confidencialidad del mensaje, se requiere HTTP sobre SSL 3.0 o TLS 1.0 con un certificado del lado del servidor.
Un respondedor SAML puede devolver una respuesta "403 Prohibido" cuando se niega a responder a un solicitante SAML. Un respondedor debe devolver una respuesta "500 Internal Server Error" en caso de un error SOAP (también se debe incluir un elemento de falla SOAP). De lo contrario, se devuelve una respuesta "200 OK", incluso en presencia de un error de procesamiento SAML. Dicha respuesta incluirá un Status
elemento SAML en el cuerpo SOAP.
Perfiles SAML 1.1
En general, los perfiles describen los casos de uso y los intercambios de mensajes necesarios para, en última instancia, transferir afirmaciones de un proveedor de identidad a un proveedor de servicios. SAML 1.1 especifica dos perfiles de SSO del navegador web:
- Perfil de navegador / POST
- Perfil de navegador / artefacto
El perfil del navegador / POST se basa en una operación de "inserción" que pasa una afirmación SSO por valor a través del navegador mediante HTTP POST. Decimos que el proveedor de identidad "empuja" la afirmación al proveedor de servicios.
El Browser / Artifact Profile emplea un mecanismo de "extracción". Básicamente, el perfil pasa una aserción SSO del proveedor de identidad al proveedor de servicios por referencia (a través del navegador usando HTTP Redirect), que posteriormente se desreferencia a través de un intercambio de canal de retorno (es decir, el proveedor de servicios "extrae" la aserción de la identidad proveedor que utiliza SAML sobre SOAP sobre HTTP).
Estos perfiles admiten el inicio de sesión único (SSO) entre dominios. La especificación no define ningún perfil adicional. En particular, SAML 1.1 no admite un perfil para proteger un mensaje de servicio web ni admite un solo perfil de cierre de sesión.
Ambos perfiles SAML 1.1 comienzan en el servicio de transferencia entre sitios , que es administrado por el proveedor de identidad. La forma en que el director llega al servicio de transferencia en primer lugar no está dictada por la especificación. Consulte las secciones 4.1 y 4.2 de SAMLOverview [3] para conocer los posibles escenarios. En la práctica, un cliente que accede a un recurso seguro en un proveedor de servicios será redirigido al servicio de transferencia entre sitios en el proveedor de identidad, pero SAML 1.1 no describe la secuencia precisa de pasos necesarios para lograr esto. (Consulte la sección 4.3 de SAMLOverview [3] para obtener algunas ideas aproximadas en este sentido). Este escenario se aborda a fondo en SAML 2.0.
Después de visitar el servicio de transferencia entre sitios, el principal se transfiere al servicio de consumidor de aserción en el proveedor de servicios. Exactamente cómo se transfiere el principal del servicio de transferencia entre sitios al servicio de consumidor de aserción depende del perfil utilizado. En el caso del perfil de navegador / artefacto, se utiliza una redirección; en el caso del Navegador / Perfil POST, el cliente emite una solicitud POST (con o sin intervención del usuario).
Para acelerar el procesamiento por parte del servicio de consumidor de aserción, se especifican dos URL independientes:
- URL del consumidor de aserción (navegador / perfil POST)
- URL del receptor de artefactos (navegador / perfil de artefacto)
Estas y otras ubicaciones de puntos finales pueden registrarse en archivos de metadatos. Exactamente cómo el proveedor de identidad obtiene un archivo de metadatos confiable, o determina de otro modo las ubicaciones confiables de los puntos finales de un proveedor de servicios en particular, está fuera del alcance con respecto a SAML 1.1.
Tenga en cuenta que un proveedor de identidad SAML 1.1 conforme debe proporcionar un servicio de transferencia entre sitios. De manera similar, un proveedor de servicios SAML 1.1 debe proporcionar un servicio de consumidor de aserción.
Perfil de navegador / POST
El perfil SAML 1.1 Browser / POST especifica los siguientes cuatro (4) pasos. La terminología utilizada en la especificación original se ha modificado ligeramente para ajustarse a la de la especificación SAML 2.0.
El flujo de mensajes comienza con una solicitud dirigida al IdP.
Solicite el servicio de transferencia entre sitios en el IdP
El principal (a través de un agente de usuario HTTP) solicita el Servicio de transferencia entre sitios en el proveedor de identidad:
https://idp.example.org/TransferService?TARGET= target
donde target
está el recurso deseado en el proveedor de servicios, digamos, https://sp.example.com/home. En otras palabras, el agente de usuario emite la siguiente solicitud GET a través de SSL / TLS:
GET / TransferService? TARGET = destino HTTP / 1.1Anfitrión : idp.example.org
El perfil no especifica cómo el TARGET
agente de usuario obtiene la URL del Servicio de transferencia (con parámetro).
Responder con un formulario HTML
El Servicio de transferencia entre sitios devuelve un documento HTML que contiene un FORM
elemento:
HTTP / 1.1 200 OK Tipo de contenido : texto / html Longitud de contenido : nnnn ... < form method = "post" action = "https://sp.example.com/ACS/POST" ... > < input type = "hidden" name = "TARGET" value = "target" /> < input type = "hidden" name = "SAMLResponse" value = "'' respuesta ''" /> ... < input type = "submit" value = "Submit" /> form >...
donde el TARGET
parámetro se ha conservado del paso 1. El valor del SAMLResponse
parámetro es la codificación base64 de un Response
elemento SAML como el siguiente:
xmlns: samlp = "urn: oasis: names: tc: SAML: 1.0: protocol" MajorVersion = "1" MinorVersion = "1" ResponseID = "_P1YaA + Q / wSM / t / 8E3R8rNhcpPTM =" IssueInstant = " 2002-06-19T17: 05: 37.795Z " > xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " > ... Value = "samlp: Success" /> xmlns: saml = "urn: oasis: names: tc: SAML: 1.0: assertion" MajorVersion = "1" MinorVersion = "1" AssertionID = "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer = "https://idp.example.org/saml" IssueInstant = "2002-06-19T17: 05: 37.795Z" > NotBefore = "2002-06 -19T17: 00: 37.795Z " NotOnOrAfter = " 2002-06-19T17: 10: 37.795Z " /> AuthenticationMethod = " urn: oasis: nombres: tc: SAML: 1.0: am: contraseña " AuthenticationInstant = " 2002-06-19T17: 05: 17.706Z " > Format = " urn: oasis: names: tc: SAML: 1.1: nameid-format: emailAddress " > [email protected] urna: oasis: nombres: tc: SAML: 1.0: cm: portador
La respuesta SAML debe estar firmada digitalmente por el proveedor de identidad.
Importante: Se supone que el principal ya ha establecido un contexto de seguridad en el proveedor de identidad; de lo contrario, el Servicio de transferencia entre sitios no podría proporcionar una declaración de autenticación en el Response
elemento SAML .
Solicite el Servicio de Atención al Consumidor de Afirmación en el SP
El agente de usuario solicita el Servicio al consumidor de afirmación en el proveedor de servicios:
POST / ACS / POST HTTP / 1.1 Host : sp.example.com Content-Type : application / x-www-form-urlencoded Content-Length : nnnnTARGET = objetivo y SAMLResponse = respuesta
donde los valores de los parámetros TARGET
y SAMLResponse
se toman del formulario HTML en el paso 2.
Nota: Para automatizar el envío del formulario, la siguiente línea de JavaScript puede aparecer en cualquier lugar de la página:
ventana . onload = function () { document . formas [ 0 ]. enviar (); }
Esto supone, por supuesto, que la página contiene un solo FORM
elemento ( forms[0]
).
Responder a la solicitud del director
El Servicio de consumidor de afirmación consume el Response
elemento SAML , crea un contexto de seguridad en el proveedor de servicios y redirige al agente de usuario al recurso de destino.
Perfil de navegador / artefacto
El perfil de navegador / artefacto de SAML 1.1 especifica los siguientes seis (6) pasos. La terminología utilizada en la especificación original se ha modificado ligeramente para ajustarse a la de la especificación SAML 2.0.
El flujo de mensajes comienza con una solicitud dirigida al IdP.
Solicite el servicio de transferencia entre sitios en el IdP
El principal (a través de un agente de usuario HTTP) solicita el Servicio de transferencia entre sitios en el proveedor de identidad:
https://idp.example.org/TransferService?TARGET= target
donde target
está el recurso deseado en el proveedor de servicios, digamos, https://sp.example.com/home. En otras palabras, el agente de usuario emite la siguiente solicitud GET a través de SSL / TLS:
GET / TransferService? TARGET = destino HTTP / 1.1Anfitrión : idp.example.org
El perfil no especifica cómo el TARGET
agente de usuario obtiene la URL del servicio de transferencia (con parámetro).
Redirigir al Servicio al consumidor de afirmaciones
El principal se redirige al Servicio al consumidor de afirmaciones en el proveedor de servicios, es decir, se devuelve la siguiente respuesta al agente de usuario:
HTTP / 1.1 302 encontradoUbicación : https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifact
donde artifact
es una referencia a una afirmación que el proveedor de identidad está dispuesto a proporcionar a pedido.
Importante: Se supone que el principal ya ha establecido un contexto de seguridad en el proveedor de identidad; de lo contrario, el Servicio de transferencia entre sitios no podría proporcionar una declaración de autenticación.
Solicite el Servicio de Atención al Consumidor de Afirmación en el SP
El agente de usuario solicita el Servicio al consumidor de afirmación en el proveedor de servicios:
https://sp.example.com/ACS/Artifact?TARGET= target & SAMLart = artifact
donde target
y artifact
son como antes. En otras palabras, el agente de usuario emite la siguiente solicitud GET a través de SSL / TLS:
GET / ACS / Artifact? TARGET = target & SAMLart = artifact HTTP / 1.1Anfitrión : sp.example.com
Solicite el servicio de resolución de artefactos en el IdP
El Servicio al consumidor de afirmaciones en el proveedor de servicios comienza un intercambio de canal de retorno con el Servicio de resolución de artefactos en el proveedor de identidad. Un mensaje SAML SOAP está vinculado a una solicitud HTTP POST:
POST / ArtifactResolutionService HTTP / 1.1Anfitrión: idp.example.orgTipo de contenido: texto / xmlLongitud del contenido: nnnSOAPAction: http://www.oasis-open.org/committees/security xmlns: SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" > xmlns: samlp = "urn: oasis: names: tc: SAML: 1.0: protocol" MajorVersion = "1" MinorVersion = "1" RequestID = "_192.168.16.51.1024506224022" IssueInstant = "2002-06-19T17: 03: 44.022Z" > artefacto
donde artifact
se envió previamente desde el proveedor de identidad al proveedor de servicios en los pasos 2 y 3.
Responder con una afirmación SAML
El proveedor de identidad completa el intercambio de canal de retorno respondiendo con una aserción SAML vinculada a un mensaje SOAP SAML:
HTTP / 1.1 200 OKTipo de contenido: texto / xmlLongitud del contenido: nnnn xmlns: SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" > xmlns: samlp = "urn: oasis: names: tc: SAML: 1.0: protocol" MajorVersion = "1" MinorVersion = "1" ResponseID = "_P1YaA + Q / wSM / t / 8E3R8rNhcpPTM =" InResponseTo = "_192.168.16.51.10" 24506224022 IssueInstant = "2002-06-19T17: 05: 37.795Z" > Value = "samlp: Success" /> xmlns: saml = "urn: oasis: nombres: tc: SAML: 1.0: aserción " MajorVersion = " 1 " MinorVersion = " 1 " AssertionID = " buGxcG4gILg5NlocyLccDz6iXrUa " Issuer = " https://idp.example.org/saml " IssueInstant = " 2002-06-19T17 : 05: 37.795Z " > NotBefore = " 2002-06-19T17: 00: 37.795Z " NotOnOrAfter = " 2002-06-19T17: 10: 37.795Z " /> AuthenticationMethod = " urn: oasis: nombres: tc: SAML: 1.0: am: contraseña " AuthenticationInstant = " 2002-06-19T17: 05: 17.706Z " > Format = " urn: oasis: nombres: tc: SAML : 1.1: nombreid-formato: emailAddres s " > [email protected] urna: oasis: nombres: tc: SAML: 1.0: cm: artefacto
En este caso, la declaración de autenticación incluye una que NameIdentifier
contiene la dirección de correo electrónico del principal.
Responder a la solicitud del director
El Servicio de consumidor de afirmación analiza el Response
elemento SAML , crea un contexto de seguridad en el proveedor de servicios y redirige al agente de usuario al recurso de destino.
Ver también
Referencias
- ^ E. Maler et al., Afirmaciones y protocolos para el lenguaje de marcado de afirmación de seguridad (SAML) V1.1 de OASIS. Estándar OASIS, septiembre de 2003. ID de documento oasis-sstc-saml-core-1.1 http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
- ^ a b E. Maler et al., Enlaces y perfiles para el lenguaje de marcado de afirmación de seguridad de OASIS (SAML) V1.1. Estándar OASIS, septiembre de 2003. ID de documento oasis-sstc-saml-bindings-profiles-1.1 http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf
- ^ a b c J. Hughes et al., Descripción técnica del lenguaje de marcado de afirmación de seguridad de OASIS (SAML) V1.1. Borrador del Comité OASIS, mayo de 2004. ID de documento sstc-saml-tech-overview-1.1-cd http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-1.1- cd.pdf
- ^ P. Mishra et al., Diferencias entre OASIS Security Assertion Markup Language (SAML) V1.1 y V1.0. Borrador de OASIS, mayo de 2003. ID de documento sstc-saml-diff-1.1-draft-01 http://www.oasis-open.org/committees/download.php/3412/sstc-saml-diff-1.1-draft-01 .pdf
- E. Maler et al., Consideraciones de seguridad y privacidad para el lenguaje de marcado de afirmaciones de seguridad (SAML) V1.1 de OASIS. Estándar OASIS, septiembre de 2003. ID de documento oasis-sstc-saml-sec-consider-1.1 http://www.oasis-open.org/committees/download.php/3404/oasis-sstc-saml-sec-consider-1.1 .pdf
- E. Maler et al., Especificación del programa de conformidad para el lenguaje de marcado de afirmación de seguridad (SAML) V1.1 de OASIS. Estándar OASIS, septiembre de 2003. ID de documento oasis-sstc-saml-conform-1.1 http://www.oasis-open.org/committees/download.php/3402/oasis-sstc-saml-conform-1.1.pdf
- E. Maler et al., Glosario para el lenguaje de marcado de afirmaciones de seguridad (SAML) V1.1 de OASIS. Estándar OASIS, septiembre de 2003. ID de documento oasis-sstc-saml-glossary-1.1 http://www.oasis-open.org/committees/download.php/3401/oasis-sstc-saml-glossary-1.1.pdf