Saml 1

SAML 1.
1
Ir a la navegaciónIr a la búsqueda
El Lenguaje de Marcado para Confirmaciones de Seguridad (SAML) es un
estándar de XML para intercambiar datos de autenticación y de autorización.
SAML es un producto de la organización OASIS (Comité técnico de Servicios
de Seguridad)
SAML 1.1 fue ratificado como un estándar de OASIS en septiembre del año
2003. Los aspectos críticos de SAML 1.1 están cubiertos en detalle en los
documentos oficiales SAMLCore1 and SAMLBind.2 Para empezar a aprender
sobre SAML se debe leer primero la introducción a SAML, y después el
documento SAMLOverview de OASIS.
Con anterioridad a SAML 1.1, SAML 1.0 fue adoptado como un estándar de
OASIS en noviembre de 2002. SAML ha experimentado una actualización
menor (V1.1) y una actualización importante (V2.0) desde la versión V1.0, que
es un protocolo relativamente sencillo. SAML 1.0 ha adquirido mayor
importancia, sin embargo, desde que la Iniciativa de Autentificación del
gobierno federal estadounidense ha adoptado SAML 1.0 cuando como su
tecnología principal.
Las versiones 1.0 y 1.1 de SAML son similares. Consulta SAMLDiff para ver las
diferencias específicas entre los dos estándares. Este artículo se centra en
SAML 1.1 ya que es un estándar importante del que muchos otros estándares
e implementaciones dependen.
Aviso: Los ejemplos de código de este artículo sirven sólo como ilustraciones y
pueden no cumplir la norma. Para conocer los requerimientos de la normativa
consultar las especificaciones de OASIS SAML .
Índice
• 1Aserciones de SAML 1.1

• 2Enlaces SAML 1.1
• 3Perfiles SAML 1.1
o 3.1Perfil Browser/POST
▪ 3.1.1Petición del servicio de transferencia interno del sitio al
proveedor de identidad
▪ 3.1.2Responde con un formulario HTML
▪ 3.1.3Petición del Servicio de aserción del consumidor al
proveedor de servicio
▪ 3.1.4Respuesta a la petición del principal
o 3.2Perfil Browser/Artifact
▪ 3.2.1Petición del servicio de transferencia interna del sitio al
▪ 3.2.2Redirección al Servicio de aserción del consumidor
▪ 3.2.3Petición del Servicio de aserción del consumidor al
proveedor de servicio
▪ 3.2.4Petición del Servicio de Resolución del Artefacto al
▪ 3.2.5Respuesta con una aserción SAML
▪ 3.2.6Respuesta a la petición del principal
• 4Véase también
• 5Referencias
Aserciones de SAML 1.1[editar]

Las aserciones de SAML contienen declaraciones que los proveedores de
servicio utilizan para tomar decisiones de control de acceso. Por ejemplo,
las declaraciones de autenticación confirman al proveedor de servicio que el rol
principal se autenticó con el proveedor de identidad en un momento dado
utilizando un método particular de autenticación. La declaración de
autenticación puede contener información adicional . Por ejemplo, en la
declaración de autenticación del ejemplo siguiente, la dirección de correo
electrónico del rol principal es confirmada al proveedor de servicio:
<saml:Assertion
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">
<saml:Conditions
NotBefore="2002-06-19T17:00:37.795Z"
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2002-06-19T17:05:17.706Z">
<saml:Subject>
<saml:NameIdentifier
Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:emailAddress">
useridp.example.org
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
Una dirección de correo electrónico (como en el ejemplo superior) será

suficiente en la mayoría de los casos. En algunos casos, sin embargo, se
requiere información adicional antes de que un proveedor de servicio pueda
tomar una decisión de control de acceso. Como ejemplo, supongamos que al
alumnado se le permite acceder a los datos de las becas. Una declaración de
atributo puede indicar si el rol principal tiene una afiliación de "estudiante" o no,
que usará el proveedor de servicio para permitir o denegar el acceso a la
aplicación de las becas:
<saml:Assertion
Issuer="https://idp.example.org/saml" ...>
<saml:Conditions NotBefore="..." NotAfter="..."/>
AuthenticationMethod="..."
AuthenticationInstant="...">
<saml:Subject>...</saml:Subject>
<saml:AttributeStatement>
<saml:Attribute
AttributeName="urn:mace:dir:attribute-
def:eduPersonAffiliation"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<saml:AttributeValue>member</saml:AttributeValue>
<saml:AttributeValue>student</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
Los atributos son a menudo obtenidos de un directorio LDAP, por lo tanto las
representaciones consistentes de los atributos a través de dominios de
seguridad es crucial. En el ejemplo superior que muestra cómo un estudiante
podría obtener acceso a una aplicación de becas, el proveedor de servicio tiene
dos papeles, uno como punto de aplicación de la norma (policy enforcement
point) y el otro como punto de decisión de la norma (policy decision point). En
ocasiones, es preferible asociar el punto de decisión de la norma al proveedor
de identidad. En tal caso, el proveedor de servicio pasa un URI al proveedor de
identidad, que entonces envía una declaración de decisión de la
autorización que determina si el rol principal tiene o no acceso al recurso
protegido en el URI facilitado.
<saml:Assertion
Issuer="https://idp.example.org/saml" ...>
<saml:Conditions .../>
<saml:AuthorizationDecisionStatement
Decision="Permit"
Resource="https://sp.example.com/confidential_report.html">
<saml:Action>read</saml:Action>
</saml:AuthorizationDecisionStatement>
</saml:Assertion>
Los tres tipos de declaración no son mutuamente exclusivos. Por ejemplo, tanto
las declaraciones de autenticación como las declaraciones de atributo pueden
ser incluidas en una única aserción (cómo se muestra en el ejemplo superior).
Esto evita que el proveedor de servicio tenga que realizar múltiples consultas
del al proveedor de identidad. El protocolo SAML es del tipo petición-respuesta.
Un requester de SAML envía un elemento de Petición SAML a un responder:
<samlp:Request
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
RequestID="aaf23196-1773-2113-474a-fe114412ab72"
IssueInstant="2006-07-17T22:26:40Z">

</samlp:Request>
De igual modo, un responder SAML devuelve un elemento de Respuesta SAML

al requester:
<samlp:Response
ResponseID="b07b804c-7c29-ea16-7300-4f3d6f7928ac"
InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
IssueInstant="2006-07-17T22:26:41Z">

</samlp:Response>
Las dependencias y los perfiles necesarios para este intercambio de mensajes

son detallados en las siguientes secciones.
Enlaces SAML 1.1[editar]

SAML 1.1 define formalmente un único protocolo de enlace, el enlace SAML
SOAP. Una implementación de SAML 1.1 debe implementar SAML
sobre SOAP sobre HTTP (un protocolo de enlace síncrono). Otros mecanismos
de transporte además de HTTP son permitidos, suponiendo que los aspectos
independientes del protocolo del enlace SAML SOAP son observados (see
section 3.1.2 of SAMLBind2).
El enlace SAML 1.1 SOAP está hecho sobre la versión 1.1 de SOAP (la
coincidencia en la numeración es pura coincidencia). Un requester SAML
envuelve un elemento SAML de tipo Petición en el cuerpo de un mensaje
SOAP. Similarmente, un responder SAML devuelve un elemento SAML de
tipo Respuesta en el cuerpo del mensaje SOAP devuelto. En caso de cualquier
error, el responder devuelve un código de error SOAP.
Cualquier markup SAML debe ser incluido in el cuerpo del mensaje SOAP.
SAML 1.1 no define ninguna cabecera SOAP especifica para SAML. Un
requester puede insertar las cabeceras SOAP que desee (aunque no se
requiere ninguna).
Recuerda que en SOAP 1.1, una cabecera HTTP SOAPAction debe ser incluida
con cada petición HTTP (aunque su valor esté vacío). Un requester SAML
puede dar el valor siguiente a la cabecera SOAPAction :
SOAPAction: http://www.oasis-open.org/committees/security
Sin embargo, un responder SAML no debe depender de este valor.

No se requiere una conexión segura para peticiones y respuestas SAML, pero
en aquellas situaciones en las que la integridad y confidencialidad del mensaje
sean necesarias, se requiere HTTP sobre SSL 3.0 o TLS 1.0 con un certificado
del lado del servidor.
Un requester SAML puede devolver una respuesta "403" cuando quiera
rechazar a un cierto requester de SAML. Un responder debe devolver una
respuesta "Error Interno de Servidor 500" cuando haya un error SOAP (además
se debe incluir un elemento de error SOAP). En cualquier otro caso, se
devuelve una respuesta "200 OK", incluso en el caso de un error de procesado
SAML. Tal respuesta incluirá un elemento SAML Status en el cuerpo del
mensaje SOAP.
Perfiles SAML 1.1[editar]

En general, los perfiles describen los casos de uso e intercambios de mensajes
requeridos para en última instancia transferir aserciones de un proveedor de
identidad a un proveedor de servicio. SAML 1.1 especifica dos perfiles SSO
para navegadores web:
1. Perfil Browser/POST
2. Perfil Browser/Artifact
El Perfil Browser/POST se basa en una operación "push" que pasa una
aserción SSO por valor a través del navegador usando HTTP POST. Decimos
que el proveedor de identidad "pushes" la aserción al proveedor de servicio.
El Perfil Browser/Artifact emplea un mecanismo de "pull". Básicamente el perfil
envía una aserción SSO del proveedor de identidad al proveedor de
servicio por referencia (a través del navegador que utiliza HTTP Redirect), el
cual es posteriormente desreferenciado a través de un intercambio back-
channel (por ejemplo, el proveedor de servicio "pulls" la aserción del proveedor
de identidad utilizando SAML sobre SOAP sobre HTTP).
Estos perfiles soportan single sign-on (SSO) en distintos dominios. La
especificación no define perfiles adicionales. En particular, SAML 1.1 no
soporta un perfil para asegurar un mensaje de servicio web ni soporta un perfil
de logout único.
Ambos perfiles SAML 1.1 empiezan en el servicio de transferencia interno del
sitio web, que está gestionado por el proveedor de identidad. La forma en la
que el principal llega al servicio de transferencia en primer lugar no está
indicada por la especificación. Para ver los escenarios posibles consultar las
secciones 4.1 y 4.2 de SAMLOverview. En la práctica, un cliente que accede a
un recurso protegido en un proveedor de servicio será redirigido al servicio de
transferencia interno del sitio en el proveedor de identidad, pero la secuencia
precisa de pasos necesarios para cumplir esto no está indicada por SAML 1.1.
(Consultar la sección 4.3 de SAMLOverview para más información.) Este
escenario está exhaustivamente desarrollado en SAML 2.0.
Después de visitar el servicio de transferencia interno del sitio, el principal es
transferido al servicio de aserción del consumidor en el proveedor de servicio.
Los detalles de cómo el principal es transferido del servicio de transferencia
interno del sitio al servicio de aserción del consumidor dependen del perfil
utilizado. En el caso del Perfil Browser/Artifact, se usa una redirección; en el
caso del Perfil Browser/POST Profile, el cliente emite una petición de tipo
POST (con o sin intervención del usuario).
Para emitir un procesamiento por el servicio de aserción, se especifican dos
URLs distintas:
1. Assertion consumer URL (Perfil Browser/POST)

2. Artifact Receiver URL (Perfil Browser/Artifact)
Estas y otras URLs pueden almacenarse en archivos de metadatos. La forma
exacta en la que un proveedor de identidad obtiene un fichero confiable de
metadatos, o determina las localizaciones confiables de un proveedor de
servicios específico está fuera de las competencias de SAML 1.1.
Notése que un proveedor de identidad SAML 1.1 debe proporcionar servicio de
transferencia interno. Similarmente, un proveedor de servicio SAML 1.1 debe
proporcionar un servicio de aserción del consumidor.
Perfil Browser/POST[editar]
El perfil SAML 1.1 Browser/POST especifica los siguientes cuatro pasos. La
terminología utilizada en la especificación original ha sido modificada
ligeramente para conformar a lo específico de la especificación SAML 2.0.
El flujo de mensaje empieza con una petición dirigida al proveedor de identidad.
Petición del servicio de transferencia interno del sitio al proveedor de
identidad[editar]
El principal (a través de un agente HTTP) solicita servicio de transferencia
interno del sitio al proveedor de identidad:
https://idp.example.org/TransferService?TARGET=target
donde target es el recurso solicitado al proveedor de servicio, por ejemplo,

https://sp.example.com/home. En otras palabras, la siguiente petición GET está
emitida por el agente usuario sobre SSL/TLS:
GET /TransferService?TARGET=target HTTP/1.1

Host: idp.example.org
El perfil no especifica cómo el URL al Servicio de Transferencia (con parámetro

de TARGET ) está obtenido por el agente de usuario.
Responde con un formulario HTML[editar]
El servicio de transferencia interno del sitio devuelve un documento HTML que
contiene un elemento FORM :
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: nnnn
...
<form method="post" action="https://sp.example.com/ACS/POST" ...>
<input type="hidden" name="TARGET" value="target" />
<input type="hidden" name="SAMLResponse" value="''response''" />
...
<input type="submit" value="Submit" />
</form>
...
donde el parámetro TARGET ha sido guardado del paso 1. El valor del

parámetro SAMLResponse es la codificación base64 de un elemento
SAML Response como el siguiente:
<samlp:Response
ResponseID="_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="
IssueInstant="2002-06-19T17:05:37.795Z">
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="samlp:Success"/>
</samlp:Status>
<saml:Assertion
IssueInstant="2002-06-19T17:05:37.795Z">
<saml:Conditions
NotBefore="2002-06-19T17:00:37.795Z"
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
<saml:Subject>
useridp.example.org
urn:oasis:names:tc:SAML:1.0:cm:bearer
</saml:Subject>
</saml:Assertion>
</samlp:Response>
La respuesta SAML debe ser digitalmente firmada por el proveedor de

identidad.
Importante: se presupone que el principal ya ha establecido un contexto de
seguridad en el proveedor de identidad, de otra manera el servicio de
transferencia interno del sitio sería incapaz de proporcionar una declaración de
autenticación en el elemento SAML Respuesta .
Petición del Servicio de aserción del consumidor al proveedor de servicio[editar]
El agente usuario solicita el Servicio de aserción del consumidor al proveedor
de servicio:
POST /ACS/POST HTTP/1.1
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
TARGET=target&SAMLResponse=response
donde los valores de los parámetros TARGET y SAMLResponse se obtienen 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:
window.onload = function () { document.forms[0].submit(); }
Este código sólo funciona si existe un único elemento FORM ( forms[0] ) en la

página.
Respuesta a la petición del principal[editar]
El Servicio de aserción del consumidor consume el elemento SAML Respuesta ,
crea un contexto de seguridad en el proveedor de servicio y redirige el agente
usuario al recurso objetivo.
Perfil Browser/Artifact[editar]
El perfil SAML 1.1 Browser/Artifact especifica los seis siguientes pasos. La
terminología utilizada en la especificación original ha sido modificada
ligeramente para conformar la especificación SAML 2.0.
El flujo del mensaje empieza con una petición dirigida al proveedor de
identidad.
Petición del servicio de transferencia interna del sitio al proveedor de
identidad[editar]
El principal (a través de un agente usuario del HTTP) solicita el servicio de
transferencia interna del sitio al proveedor de identidad:
https://idp.example.org/transferservice?Objetivo=de OBJETIVO
donde el target es el recurso requerido del proveedor de servicio, por ejemplo,

https://sp.example.com/home. En otras palabras, la siguiente petición GET es
emitida por el agente usuario sobre SSL/TLS:
GET /TransferService?TARGET=target HTTP/1.1

El perfil no especifica cómo la URL al servicio de transferencia (con el

parámetro TARGET ) es obtenida por el agente usuario.
Redirección al Servicio de aserción del consumidor[editar]
El principal es redirigido al Servicio de aserción del consumidor al proveedor de
servicio, es decir, la siguiente respuesta es devuelta al agente usuario:
HTTP/1.1 302 Found
Location:
https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifact
donde artifact es una referencia a una aserción que el proveedor de

identidad está dispuesto a proporcionar sobre una petición.
Importante: se asume que el principal ya ha establecido un contexto de
seguridad en el proveedor de identidad, de otra manera el servicio de
transferencia interno del sitio sería incapaz de proporcionar una declaración de
autenticación.
Petición del Servicio de aserción del consumidor al proveedor de servicio[editar]
El agente usuario solicita el servicio de aserción del consumidor al proveedor
de servicio:
https://sp.example.com/acs/artifact?Objetivo=de
OBJETIVO&SAMLart=artefacto
donde el target y el artifact son como en los ejemplos previos. En otras

palabras, la siguiente petición GET es emitida por el agente usuario sobre
SSL/TLS:
GET /ACS/Artifact?TARGET=target&SAMLart=artifact HTTP/1.1

Host: sp.example.com
Petición del Servicio de Resolución del Artefacto al proveedor de identidad[editar]

El Servicio de aserción del consumidor en el proveedor de servicio comienza
un intercambio de canal de vuelta con el Servicio de resolución del artefacto en
el proveedor de identidad. Un mensaje SAML SOAP está enlazado a una
petición HTTP POST:
POST /ArtifactResolutionService HTTP/1.1

Content-Type: text/xml
Content-Length: nnn
SOAPAction: http://www.oasis-open.org/committees/security
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<samlp:Request
RequestID="_192.168.16.51.1024506224022"
IssueInstant="2002-06-19T17:03:44.022Z">
<samlp:AssertionArtifact>
artifact
</samlp:AssertionArtifact>
</samlp:Request>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
donde artifact ha sido previamente enviado del proveedor de identidad al

proveedor de servicio en los pasos 2 y 3.
Respuesta con una aserción SAML[editar]
El proveedor de identidad completa el intercambio de canal de vuelta
respondiendo con una aserción SAML unida a un mensaje SAML SOAP:
HTTP/1.1 200 OK
Content-Type: text/xml
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<samlp:Response
ResponseID="_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="
InResponseTo="_192.168.16.51.1024506224022"
IssueInstant="2002-06-19T17:05:37.795Z">
<samlp:Status>
<samlp:StatusCode Value="samlp:Success"/>
</samlp:Status>
<saml:Assertion
IssueInstant="2002-06-19T17:05:37.795Z">
<saml:Conditions
NotBefore="2002-06-19T17:00:37.795Z"
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
<saml:Subject>
useridp.example.org
urn:oasis:names:tc:SAML:1.0:cm:artifact
</saml:Subject>
</saml:Assertion>
</samlp:Response>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
En este caso, la declaración de autenticación incluye
un NameIdentifier conteniendo la dirección de correo electrónico del principal.
Respuesta a la petición del principal[editar]
El Servicio de aserción del consumidor parsea el elemento SAML Respuesta ,
crea un contexto de seguridad en el proveedor de servicio y redirige el agente
de usuario al recurso objetivo.

Saml 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Saml 1

Cargado por

Copyright:

Formatos disponibles

SAML 1.

• 1Aserciones de SAML 1.1

Aserciones de SAML 1.1[editar]

Una dirección de correo electrónico (como en el ejemplo superior) será

De igual modo, un responder SAML devuelve un elemento de Respuesta SAML

Las dependencias y los perfiles necesarios para este intercambio de mensajes

Enlaces SAML 1.1[editar]

Sin embargo, un responder SAML no debe depender de este valor.

Perfiles SAML 1.1[editar]

1. Assertion consumer URL (Perfil Browser/POST)

donde target es el recurso solicitado al proveedor de servicio, por ejemplo,

GET /TransferService?TARGET=target HTTP/1.1

El perfil no especifica cómo el URL al Servicio de Transferencia (con parámetro

donde el parámetro TARGET ha sido guardado del paso 1. El valor del

La respuesta SAML debe ser digitalmente firmada por el proveedor de

donde los valores de los parámetros TARGET y SAMLResponse se obtienen del

window.onload = function () { document.forms[0].submit(); }

Este código sólo funciona si existe un único elemento FORM ( forms[0] ) en la

donde el target es el recurso requerido del proveedor de servicio, por ejemplo,

GET /TransferService?TARGET=target HTTP/1.1

El perfil no especifica cómo la URL al servicio de transferencia (con el

donde artifact es una referencia a una aserción que el proveedor de

donde el target y el artifact son como en los ejemplos previos. En otras

GET /ACS/Artifact?TARGET=target&SAMLart=artifact HTTP/1.1

Petición del Servicio de Resolución del Artefacto al proveedor de identidad[editar]

POST /ArtifactResolutionService HTTP/1.1

donde artifact ha sido previamente enviado del proveedor de identidad al

También podría gustarte