metadatos SAML

El término metadatos estáticos se refiere a un archivo de metadatos configurado directamente en la aplicación SAML por un administrador. De esta forma, el administrador se responsabiliza del mantenimiento de los metadatos, independientemente de cómo se hayan obtenido inicialmente. Por lo tanto, los metadatos estáticos contribuyen a la configuración estática general de la aplicación SAML.

Lamentablemente, los metadatos SAML son inherentemente dinámicos, como lo ilustra el siguiente escenario típico entre un proveedor de identidad SAML (IdP) y un proveedor de servicios SAML (SP). Supongamos que el propietario del IdP obtiene metadatos SAML de un socio SP. Estos metadatos pueden transmitirse al propietario del IdP por correo electrónico, o bien, el propietario del IdP accede a una aplicación web protegida y descarga los metadatos del SP a través de un navegador. Independientemente de cómo se obtengan los metadatos, el resultado es el mismo: el propietario del IdP configura los metadatos del SP directamente en el software del IdP.

Supongamos ahora que los metadatos del proveedor de servicios (SP) contienen una clave de cifrado pública. Presumiblemente, la clave de descifrado privada correspondiente está configurada en el software del SP. Si la clave de descifrado privada se ve comprometida (o necesita ser reemplazada por cualquier otro motivo), la clave de cifrado pública en los metadatos del SP deja de ser confiable y también debe ser reemplazada.

Dado que los metadatos del proveedor de servicios (SP) se configuran estáticamente en el software del proveedor de identidad (IdP), solo el propietario del IdP puede reemplazar la clave de cifrado pública en dichos metadatos. En este sentido, el propietario del IdP es responsable de los metadatos del SP. Esta discrepancia genera problemas de interoperabilidad.

Lo mismo ocurre en el lado del proveedor de servicios (SP). Al configurar estáticamente los metadatos del proveedor de identidad (IdP) en el software del SP, el propietario del SP acepta implícitamente la responsabilidad de mantenerlos actualizados cuando se produzcan cambios. Dado que un IdP (o SP) suele tener muchos socios, la configuración estática de metadatos claramente no es escalable y, además, la gestión de cambios asociada a los metadatos estáticos resulta, en el mejor de los casos, complicada.

Como era de esperar, los procesos de intercambio de metadatos buscan automatizarse. Cada archivo de metadatos configurado estáticamente en la aplicación SAML por un administrador genera deuda técnica. Esta acumulación impide que la implementación de SAML alcance su máximo potencial.

Para evitar una deuda técnica excesiva, el proceso de intercambio de metadatos debe automatizarse. Una opción es recurrir a un tercero de confianza encargado de recopilar, gestionar y distribuir los metadatos en la red. Los metadatos gestionados tienen un formato uniforme, presentan menos probabilidades de contener vulnerabilidades (intencionadas o no) y, por lo tanto, son seguros de usar.

En el caso de los metadatos SAML, este tercero de confianza se denomina federación SAML. La comunidad de implementadores SAML que conforman la federación se adhiere voluntariamente a uno o más perfiles SAML para promover la interoperabilidad y la confianza. Con este fin, los participantes de la federación suelen compartir una infraestructura central para el intercambio de metadatos, lo que permite que la federación escale a miles de implementaciones SAML interoperables.

En respuesta a Microsoft Passport , Liberty Alliance concibió el Identity Federation Framework (ID -FF), una tecnología de federación desarrollada durante un período de tres años entre 2002 y 2004. (La historia de SAML mencionada anteriormente proporciona contexto para ID-FF). El 14  de noviembre de 2003, Liberty contribuyó con ID-FF  1.2 a OASIS . La contribución incluyó un documento titulado Liberty Metadata Description and Discovery Specification Version  1.0, ^{[ LibertyMeta 1 ]} que incluía los siguientes objetivos de diseño:

1. " whois para federaciones SAML" (basado en los elementos Organizationy ContactPersonen los metadatos)
2. Descubrimiento dinámico de metadatos (con resolución mediante DNS y ubicación conocida)
3. Seguridad a nivel de documento mediante firma XML.

Resulta que todos esos objetivos se conservaron en el  estándar de metadatos OASIS SAML V2.0 que se describe más adelante en este artículo.

El documento de esquema incluido en el archivo heredado Liberty ID-FF  1.2 se identifica como Liberty Metadata Versión  1.1, mientras que Liberty Metadata Versión  1.0 se aportó a OASIS. El autor del esquema explicó esta aparente contradicción. (Peter Davis, Comunicación personal) Entre noviembre de 2003 (cuando  se aportó la Versión 1.0 a OASIS) y diciembre de 2004 (cuando  Liberty completó la Versión 1.1), el desarrollo de la especificación de metadatos de Liberty continuó en paralelo con el flujo de trabajo de OASIS. Consulte el siguiente diagrama para una representación visual. Las flechas en el diagrama indican dependencias, mientras que las líneas discontinuas indican equivalencias.

Las referencias pertinentes al flujo de trabajo de Liberty se incluyen al final de este artículo. El esquema de metadatos original aportado a OASIS se detalla íntegramente en la sección  7 de la especificación Liberty Metadata Versión  1.0 ^{[ LibertyMeta 1 ]} . Del mismo modo, la especificación para Liberty Metadata Versión  1.1 ^{[ LibertyMeta 2 ]} incluye una lista del  esquema de la Versión 1.1. Ambos esquemas, el de la Versión  1.0 y el de la Versión  1.1, están enlazados aquí gracias a la Wayback Machine de Internet Archive .

Durante los siguientes trece meses, de noviembre de 2003 a diciembre de 2004, el Comité Técnico de Servicios de Seguridad (SAML) de OASIS (SSTC) adaptó la especificación de metadatos Liberty a lo que posteriormente se conocería como metadatos SAML. En ese tiempo, el SSTC generalizó la especificación de metadatos para incluir compatibilidad con múltiples protocolos (incluidos protocolos que no son SAML), pero, lo que es más importante, el esquema de metadatos Liberty se adaptó con numerosos puntos de extensión. Históricamente, la extensibilidad de los metadatos SAML ha tenido consecuencias importantes, como veremos.

Para marzo de 2004, la mayor parte de la contribución de Liberty se había incorporado al flujo de trabajo de OASIS. ^{[ SAMLMeta 1 ]} A partir de ese momento, los flujos de trabajo de Liberty y OASIS progresaron simultáneamente (pero no de forma independiente, ya que las mismas personas trabajaban en ambas especificaciones). Entre marzo y julio de 2004, la incipiente especificación de metadatos SAML sufrió cambios significativos.

En julio de 2004, el SSTC emitió una convocatoria pública para comentarios sobre un conjunto completo de  especificaciones preliminares de SAML V2.0. Dicho conjunto de especificaciones incluía un borrador de trabajo de una  especificación de metadatos SAML V2.0 de reciente creación. ^{[ SAMLMeta 2 ]}

En retrospectiva, parece que la mayor parte de la  especificación de metadatos SAML V2.0 se desarrolló entre marzo y julio de 2004, pero claramente el  estándar de metadatos SAML V2.0 surgió de las entrañas de Liberty Alliance, específicamente de Liberty Metadata Versión  1.0. ^{[ LibertyMeta 1 ]} En consecuencia, para comprender los orígenes de los metadatos SAML, es necesario estudiar la procedencia de los metadatos Liberty.

El resto de la historia de los metadatos SAML se centra principalmente en el proceso administrativo de OASIS. Tras la publicación del borrador final del Comité en noviembre de 2004, ^{[ SAMLMeta 3 ]} el SSTC inició el proceso de estandarización en enero de 2005. Finalmente, el 5  de marzo de 2005, OASIS anunció la ratificación del  estándar SAML V2.0.

El conjunto de especificaciones V2.0 (consulte la sección Referencias para obtener una lista completa) incluía la  especificación final de metadatos SAML V2.0. ^{[ OS 1 ]} Una década después, en septiembre de 2015, OASIS publicó una especificación de metadatos SAML revisada con erratas. ^{[ OS 3 ]} Como resultado, la especificación de metadatos original quedó obsoleta, al igual que los demás documentos del conjunto de especificaciones 2.0 original.

Durante la década transcurrida entre 2005 y 2015, el SSTC elaboró ​​varios borradores de especificaciones posteriores a la versión 2.0. Algunos de estos borradores se convirtieron en especificaciones del Comité. Una selección de estas especificaciones del Comité se incluye en la sección de Referencias al final de este artículo.

Resulta que la influencia del Liberty Identity Federation Framework en los metadatos SAML es anterior a la contribución de ID-FF  1.2 en noviembre de 2003. Aparentemente, el SSTC estaba explorando el tema de los metadatos en paralelo con la Liberty Alliance. Un extracto de un borrador de especificación de metadatos publicado en septiembre de 2003 lo confirma:

Este documento define los metadatos que describen los elementos y atributos necesarios para usar los perfiles de inicio de sesión único (SSO) del navegador web SAML. Dado que los perfiles SSO web de Liberty Alliance se basan directamente en los perfiles SSO web SAML, los metadatos definidos en este documento toman prestados muchos elementos de las definiciones de metadatos de las  especificaciones preliminares de Liberty Alliance 1.2. (Extraído de "Metadatos para  los perfiles SSO del navegador web SAML 2.0" ^{[ SAMLMeta 4 ]} )

El historial de revisiones al final de ese borrador se caracteriza de la siguiente manera: "Borrador inicial basado en el Borrador  07 de la  especificación de metadatos SAML 1.1". En otras palabras, se publicaron borradores anteriores. De hecho, el historial de revisiones al final del borrador anterior ^{[ SAMLMeta 5 ]} muestra un rastro de especificaciones de metadatos que se remontan a noviembre de 2002.

Siguiendo el rastro documental, la influencia de Liberty ID-FF en los metadatos SAML se remonta a un borrador de especificación publicado en abril de 2003. ^{[ SAMLMeta 6 ]} Este es el primer documento OASIS conocido que hace referencia a Liberty ID-FF, específicamente, Liberty Metadata Versión  1.0-06, ^{[ LibertyMeta 3 ]} una versión temprana de la especificación de Liberty Metadata sobre la cual se sabe poco. Sin embargo, está claro que "Metadatos para  perfiles de navegador web SAML 1.1" estaba destinado a ser un complemento del  estándar SAML V1.1, pero por supuesto sabemos que V1.1 no especifica el uso de metadatos. Consulte la siguiente sección para ver las conjeturas relevantes.

Dos esquemas de metadatos antiguos pueden resultar de interés:

1. En junio de 2002, apenas un mes después de que el SSTC finalizara su trabajo en lo que se convertiría en el  estándar SAML V1.0, el proyecto Shibboleth desarrolló un esquema de metadatos compuesto por <OriginSite>elementos <DestinationSite>. Este esquema impulsaría las versiones iniciales del software IdP de Shibboleth.
2. En febrero de 2003, el SSTC publicó un borrador de esquema para una especificación de metadatos titulada "Metadatos para perfiles de navegadores web SAML 1.0". ^{[ SAMLMeta 7 ]} Sin embargo, ese esquema sigue siendo una curiosidad, ya que la siguiente versión de ese flujo de documentos (y todas las versiones posteriores) exhibirían la sintaxis de metadatos Liberty.

No existen pruebas que sugieran que ninguno de estos primeros intentos de definir un esquema de metadatos haya tenido un efecto apreciable en el desarrollo del esquema de metadatos de Liberty.

Sabemos que los estándares de metadatos para SAML  V1.0 o SAML  V1.1 nunca se publicaron. También sabemos que los derechos de propiedad intelectual necesarios para Liberty Metadata no se establecieron hasta noviembre de 2003. Dicho esto, ofrecemos el siguiente resumen y conjetura:

1. Un borrador de especificación titulado "Metadatos para  perfiles de navegador web SAML 1.0" ^{[ SAMLMeta 8 ]} fue la primera especificación de metadatos SAML conocida. El documento está fechado el 12  de noviembre de 2002, una semana después del anuncio del estándar SAML  V1.0, lo cual resulta curioso. En cualquier caso, la sintaxis de metadatos utilizada en ese documento es completamente diferente de lo que hoy conocemos como metadatos SAML. Dicho documento nunca se publicó y su origen sigue siendo un misterio.
2. Un borrador de especificación titulado "Metadatos para  perfiles de navegador web SAML 1.1" ^{[ SAMLMeta 6 ]} fue la primera especificación de metadatos SAML conocida basada en Liberty ID-FF. Se completó en abril de 2003. El título del borrador de especificación deja claro que el SSTC sabía que SAML  V1.1 estaba por llegar y, además, que los metadatos SAML se incluirían en el  estándar SAML V1.1.
3. Lamentablemente, esto no sucedió, ya que no existían los derechos de propiedad intelectual necesarios cuando  se anunció el estándar SAML V1.1. De hecho, la contribución formal de Liberty ID-FF 1.2 a OASIS se produjo dos meses después del anuncio del  estándar SAML V1.1 en septiembre de 2003.
4. En septiembre de 2003, menos de dos semanas después del anuncio del  estándar SAML V1.1, el SSTC puso su mirada en SAML  V2.0 bifurcando el flujo de documentos y renombrando el borrador del documento: "Metadatos para  perfiles de navegador web SAML 2.0". ^{[ SAMLMeta 4 ]}
5. SAML Metadata surgió entre marzo y julio de 2004. El SSTC emitió una convocatoria pública para comentarios que incluía una especificación candidata de SAML Metadata. ^{[ SAMLMeta 2 ]}
6. La especificación final de metadatos SAML ^{[ OS 1 ]} se incluyó en el  conjunto de especificaciones del estándar SAML V2.0 anunciado en marzo de 2005.
7. Durante los siguientes 10 años, los documentos de especificación evolucionaron (pero el esquema se mantuvo estable). En septiembre de 2015 se publicó una especificación para  los metadatos SAML V2.0 con erratas (SAMLMeta20Errata ^{[ OS 3 ] ).}

Como se mencionó anteriormente, el  esquema de metadatos SAML V2.0 ^{[ OS 4 ]} cuenta con numerosos puntos de extensión. Esta característica propició la proliferación de especificaciones posteriores a la versión 2.0 que ampliaron el estándar en diversas direcciones. A continuación, se enumeran las extensiones de metadatos más populares para mayor comodidad (consulte los ejemplos para casos de uso específicos):

1. Extensiones de metadatos SAML  V2.0 para información de registro y publicación Versión  1.0. ^{[ CS 1 ]}
2. Extensión de metadatos SAML  V2.0 para atributos de entidad. ^{[ CS 2 ]}
3. Extensiones de metadatos SAML  V2.0 para la interfaz de usuario de inicio de sesión y descubrimiento, versión  1.0. ^{[ CS 3 ]}
4. Protocolo y perfil del servicio de descubrimiento de proveedores de identidad. ^{[ CS 4 ]}
5. Protocolo y perfil de inicio de solicitud del proveedor de servicios, versión  1.0. ^{[ CS 5 ]}
6. Perfil de metadatos SAML  V2.0 para soporte de algoritmos versión  1.0. ^{[ CS 6 ]}

Una especificación importante posterior a la versión 2.0 es el Perfil de Interoperabilidad de Metadatos SAML V2.0  ^{[ CS 7 ]} , que parte de la premisa de que una infraestructura formal de clave pública (PKI) puede ser extremadamente compleja y, en algunos casos, intratable (es bien sabido, por ejemplo, que la revocación de certificados TLS orientada al navegador está rota ^{[ Misc 1 ]} ). En esencia, el Perfil de Interoperabilidad de Metadatos es un intento de proporcionar un mecanismo de revocación de claves viable para las federaciones SAML.

Desde su publicación en agosto de 2009, el Perfil de Interoperabilidad de Metadatos ha sido un documento particularmente influyente, especialmente en la educación superior (véase, por ejemplo, los requisitos relacionados con los certificados para los implementadores ^{[ Misc 2 ]} en una gran federación de I+D). La interoperabilidad de metadatos desempeña un papel clave en un perfil de implementación formal publicado por la Iniciativa Kantara:

Las implementaciones DEBEN admitir la interpretación y aplicación de metadatos según lo definido por el  Perfil de Interoperabilidad de Metadatos SAML V2.0. Por consiguiente, las implementaciones DEBEN ser capaces de interoperar (con éxito o fracaso según lo determine la configuración predeterminada) con cualquier número de pares SAML para los que haya metadatos disponibles, sin entradas adicionales ni configuración separada. ^{[ Varios 3 ]}

De hecho, la característica clave que distingue una implementación SAML escalable (de una que no lo es) es la interoperabilidad de los metadatos.

El siguiente ejemplo de código ilustra las características técnicas comunes de un <md:EntityDescriptor>elemento SAML:

<md:EntityDescriptor entityID= "https://sso.example.info/entity" validUntil= "2017-08-30T19:10:29Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:mdrpi= "urn:oasis:names:tc:SAML:metadata:rpi" xmlns:mdattr= "urn:oasis:names:tc:SAML:metadata:attribute" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- insertar elemento ds:Signature (omitido) --> <md:Extensions> <mdrpi:RegistrationInfo registrationAuthority= "https://registrar.example.net" /> <mdrpi:PublicationInfo creationInstant= "2017-08-16T19:10:29Z" publisher= "https://registrar.example.net" /> <mdattr:EntityAttributes> <saml:Attribute Name= "http://registrar.example.net/entity-category" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:AttributeValue> https://registrar.example.net/category/self-certified </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> <!-- insertar una o más instancias concretas de la md:RoleDescriptor tipo abstracto (ver más abajo) --> <md:Organization> <md:OrganizationName xml:lang= "en" > ... </md:OrganizationName> <md:OrganizationDisplayName xml:lang= "en" > ... </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.info/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> Soporte técnico SAML </md:SurName> <md:EmailAddress> mailto:technical-support@example.info </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

Tenga en cuenta los siguientes detalles sobre este descriptor de entidad general:

• El entityIDatributo es el identificador único de la entidad. Es importante tener en cuenta que se entityIDtrata de un nombre inmutable para la entidad, no de una ubicación.
• Este validUntilatributo indica la fecha de caducidad de los metadatos.
• El <ds:Signature>elemento (omitido por simplicidad) contiene una firma digital que garantiza la autenticidad e integridad de los metadatos. Se presume que el firmante es un tercero de confianza denominado registrador de metadatos .
• El <mdrpi:RegistrationInfo>elemento de extensión ^{[ CS 1 ]} afirma un identificador para el registrador de metadatos.
• El <mdrpi:PublicationInfo>elemento de extensión ^{[ CS 1 ]} indica el editor de metadatos (que resulta ser el mismo que el registrador). El creationInstantatributo proporciona el instante preciso en que se crearon los metadatos. Al comparar el valor del creationInstantatributo con el valor del validUntilatributo, vemos que los metadatos son válidos durante dos semanas.
• El <mdattr:EntityAttributes>elemento de extensión ^{[ CS 2 ]} incluye un único atributo de entidad. El atributo de entidad afirma que la entidad está "autocertificada", una cualidad presumiblemente deseable.
• La organización identificada en el <md:Organization>elemento es "responsable de la entidad" descrita por el descriptor de entidad (sección  2.3.2 de SAMLMeta ^{[ OS 3 ]} ). El <md:Organization>elemento contiene uno o más elementos secundarios calificados por idioma de cada tipo.
• La información de contacto en el <md:ContactPerson>elemento identifica a un contacto técnico responsable de la entidad. Es posible incluir varios contactos y tipos de contacto. Consulte la sección  2.3.2.2 de SAMLMeta. ^{[ OS 3 ]}

El descriptor de rol, de vital importancia, se ha omitido en este ejemplo inicial por brevedad. La especificación de metadatos SAML define numerosas instancias concretas del tipo abstracto md:RoleDescriptor  (sección 2.4.1 de SAMLMeta ^{[ OS 3 ]} ). Los dos roles más importantes se describen mediante el <md:IDPSSODescriptor>elemento y el <md:SPSSODescriptor>elemento. Cada uno de estos descriptores de rol se ilustra en las subsecciones siguientes.

Un proveedor de identidad SAML administra un punto final de servicio de inicio de sesión único ^{[ OS 2 ]} que recibe solicitudes de autenticación de proveedores de servicios. El descriptor de entidad para un proveedor de identidad en ese rol contiene un <md:IDPSSODescriptor>elemento, que a su vez contiene al menos un <md:SingleSignOnService>punto final. El siguiente ejemplo ilustra dos de dichos puntos finales:

<md:EntityDescriptor entityID= "https://sso.example.org/idp" validUntil= "2017-08-30T19:10:29Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:mdrpi= "urn:oasis:names:tc:SAML:metadata:rpi" xmlns:mdattr= "urn:oasis:names:tc:SAML:metadata:attribute" xmlns:mdui= "urn:oasis:names:tc:SAML:metadata:ui" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- insertar elemento ds:Signature (omitido) --> <md:Extensions> <mdrpi:RegistrationInfo registrationAuthority= "https://registrar.example.net" /> <mdrpi:PublicationInfo creationInstant= "2017-08-16T19:10:29Z" publisher= "https://registrar.example.net" /> <mdattr:EntityAttributes> <saml:Attribute Name= "http://registrar.example.net/entity-category" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:AttributeValue> https://registrar.example.net/category/self-certified </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> <md:IDPSSODescriptor protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:Extensions> <mdui:UIInfo> <mdui:DisplayName xml:lang= "en" > Example.org </mdui:DisplayName> <mdui:Description xml:lang= "en" > El proveedor de identidad en Example.org </mdui:Description> <mdui:Logo height= "32" width= "32" xml:lang= "en" > https://idp.example.org/myicon.png </mdui:Logo> </mdui:UIInfo> </md:Extensions> <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= "https://idp.example.org/SAML2/SSO/Redirect" /> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://idp.example.org/SAML2/SSO/POST" /> </md:IDPSSODescriptor> <md:Organization><md:OrganizationName xml:lang= "en" > Example.org Organización sin fines de lucro </md:OrganizationName> <md:OrganizationDisplayName xml:lang= "en" > Example.org </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.org/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> Soporte técnico SAML </md:SurName> <md:EmailAddress> mailto:technical-support@example.org </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

El contenido del <md:IDPSSODescriptor>elemento describe el servicio de inicio de sesión único del proveedor de identidad. Tenga en cuenta los siguientes detalles sobre este elemento:

• El <mdui:UIInfo>contenedor ^{[ CS 3 ]} contiene un conjunto de elementos de extensión calificados por lenguaje que se utilizan para construir interfaces de usuario dinámicas en el proveedor de servicios. La interfaz de usuario más importante en el proveedor de servicios es la interfaz de descubrimiento del proveedor de identidad.
• Se supone que el software del proveedor de identidad está configurado con una clave privada de firma SAML. La clave pública correspondiente se incluye en el <md:KeyDescriptor use="signing">elemento. En el ejemplo anterior, el material de la clave se ha omitido del descriptor de clave por brevedad.
• Los Bindingatributos de los <md:SingleSignOnService>elementos son URI estándar especificados en la  especificación de enlace SAML 2.0 (SAMLBind ^{[ OS 5 ]} ).

Los valores de los md:SingleSignOnService/@Locationatributos en los metadatos del proveedor de identidad son utilizados por un proveedor de servicios para enrutar los mensajes SAML, lo que minimiza la posibilidad de que un proveedor de identidad malintencionado orqueste un ataque de intermediario .

Un proveedor de servicios SAML administra un punto final de servicio de consumidor de aserciones ^{[ OS 2 ]} que recibe aserciones de autenticación de proveedores de identidad. El descriptor de entidad para un proveedor de servicios en ese rol contiene un <md:SPSSODescriptor>elemento, que a su vez contiene al menos un <md:AssertionConsumerService>punto final. El siguiente ejemplo ilustra dicho punto final:

<md:EntityDescriptor entityID= "https://sso.example.com/portal" validUntil= "2017-08-30T19:10:29Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:mdrpi= "urn:oasis:names:tc:SAML:metadata:rpi" xmlns:mdattr= "urn:oasis:names:tc:SAML:metadata:attribute" xmlns:mdui= "urn:oasis:names:tc:SAML:metadata:ui" xmlns:idpdisc= "urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- insertar elemento ds:Signature (omitido) --> <md:Extensions> <mdrpi:RegistrationInfo registrationAuthority= "https://registrar.example.net" /> <mdrpi:PublicationInfo creationInstant= "2017-08-16T19:10:29Z" publisher= "https://registrar.example.net" /> <mdattr:EntityAttributes> <saml:Attribute Name= "http://registrar.example.net/entity-category" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:AttributeValue> https://registrar.example.net/category/self-certified </saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> <md:SPSSODescriptor WantAssertionsSigned= "true" protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:Extensions> <mdui:UIInfo> <mdui:DisplayName xml:lang= "en" > Servicio de proveedor de Example.com </mdui:DisplayName> <mdui:InformationURL xml:lang= "en" > https://service.example.com/about.html </mdui:InformationURL> <mdui:PrivacyStatementURL xml:lang= "en" > https://service.example.com/privacy.html </mdui:PrivacyStatementURL> <mdui:Logo height= "32" width= "32" xml:lang= "en" > https://service.example.com/myicon.png </mdui:Logo> </mdui:UIInfo> <idpdisc:DiscoveryResponse index= "0" Binding= "urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location= "https://service.example.com/SAML2/Login" /> </md:Extensions> <md:KeyDescriptor use= "encryption"> <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:AssertionConsumerService index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://service.example.com/SAML2/SSO/POST" /> <md:AttributeConsumingService index= "0" > <md:ServiceName xml:lang= "en" > Portal de empleados de Example.com </md:ServiceName> <md:RequestedAttribute isRequired= "true" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.13" FriendlyName= "eduPersonUniqueId" /> <md:RequestedAttribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:0.9.2342.19200300.100.1.3" FriendlyName= "mail" /> </md:AttributeConsumingService> </md:SPSSODescriptor> <md:Organization> <md:OrganizationName xml:lang= "en" > Example.com Inc. </md:OrganizationName> < md:OrganizationDisplayName xml:lang= "en" > Example.com </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.com/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> Soporte técnico SAML </md:SurName> <md:EmailAddress> mailto:technical-support@example.com </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

El contenido del <md:SPSSODescriptor>elemento describe el Servicio de Consumidor de Aserciones del proveedor de servicios. Tenga en cuenta los siguientes detalles sobre este elemento:

• El WantAssertionsSignedatributo del <md:SPSSODescriptor>elemento declara que el proveedor de servicios desea que el <saml:Assertion>elemento esté firmado digitalmente. Este atributo provoca que un proveedor de identidades con capacidad de reconocimiento de metadatos se configure automáticamente en tiempo de ejecución.
• El <mdui:UIInfo>elemento de extensión ^{[ CS 3 ]} contiene un conjunto de elementos de extensión calificados por idioma que se utilizan para construir interfaces de usuario dinámicas en el proveedor de identidad. Dos interfaces de usuario importantes en el proveedor de identidad son la página de inicio de sesión y la interfaz de consentimiento del usuario.
• El <idpdisc:DiscoveryResponse>elemento de extensión ^{[ CS 4 ]} define un punto final que se utiliza junto con el descubrimiento del proveedor de identidad.
• Se presume que el software del proveedor de servicios está configurado con una clave de descifrado SAML privada. El elemento incluye una clave de cifrado SAML pública <md:KeyDescriptor use="encryption">. En el ejemplo anterior, el material de la clave se ha omitido del descriptor de clave por brevedad.
• Este <md:NameIDFormat>elemento proporciona el formato deseado para el <saml:NameID>elemento en la aserción SAML. La presencia de este elemento provoca que un proveedor de identidades con capacidad de reconocimiento de metadatos se autoconfigure en tiempo de ejecución.
• El indexatributo de un <md:AssertionConsumerService>elemento se utiliza como valor del AssertionConsumerServiceIndexatributo en un <samlp:AuthnRequest>elemento.
• El Bindingatributo del <md:AssertionConsumerService>elemento es una URI estándar especificada en la  especificación de enlace SAML 2.0 (SAMLBind ^{[ OS 5 ]} ).
• <md:AttributeConsumingService>El proveedor de identidad utiliza este elemento para formular otro <saml:AttributeStatement>elemento que se envía al proveedor de servicios junto con el inicio de sesión único (SSO) del navegador web SAML.
• El indexatributo del <md:AttributeConsumingService>elemento se utiliza como valor del AttributeConsumingServiceIndexatributo en un <samlp:AuthnRequest>elemento.

El valor del md:AssertionConsumerService/@Locationatributo en los metadatos del proveedor de servicios es utilizado por un proveedor de identidad para enrutar los mensajes SAML, lo que minimiza la posibilidad de que un proveedor de servicios malintencionado orqueste un ataque de intermediario .

Un usuario de navegador solicita un recurso de aplicación web protegido por un proveedor de servicios SAML:

https://sp.example.com/myresource

Si ya existe un contexto de seguridad válido para la entidad principal del usuario en el proveedor de servicios, omita los pasos 2 a 13.

Antes de que el proveedor de servicios pueda iniciar el flujo del protocolo SAML en el paso  6, debe conocerse el proveedor de identidad preferido del usuario del navegador. Existen numerosas maneras de hacerlo. A modo de ejemplo, el proveedor de servicios utilizará un Servicio de Descubrimiento local que cumpla con el Protocolo y Perfil del Servicio de Descubrimiento del Proveedor de Identidad. ^{[ CS 4 ]}

El proveedor de servicios redirige al usuario del navegador al Servicio de descubrimiento:

Redirección 302 Ubicación: https://ds.example.com/idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal

Tenga en cuenta que el SP entityIDestá incluido en la URL de redireccionamiento tal como lo especifica el protocolo de descubrimiento.

El usuario del navegador solicita el Servicio de Descubrimiento en virtud de la redirección:

GET /idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal HTTP / 1.1 Host : ds.example.com

(Descubra el proveedor de identidad preferido del usuario)

El Servicio de Descubrimiento identifica el proveedor de identidad preferido del usuario del navegador mediante métodos no especificados.

El Servicio de Descubrimiento ahora redirige al usuario del navegador a un punto final de Respuesta de Descubrimiento en el proveedor del servicio:

Redirección 302 Ubicación: https://sp.example.com/SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp

Tenga en cuenta que el IdP entityIDestá incluido en la URL de redireccionamiento tal como lo especifica el protocolo de descubrimiento.

El usuario del navegador solicita el punto final de respuesta de descubrimiento en el proveedor de servicios en virtud de la redirección:

GET /SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp HTTP / 1.1 Host : sp.example.com

El punto final de respuesta de descubrimiento en el proveedor de servicios cumple con el protocolo y perfil del servicio de descubrimiento del proveedor de identidad. ^{[ CS 4 ]}

El proveedor de servicios genera un elemento relevante <samlp:AuthnRequest>, codifica una solicitud SAML en una cadena de consulta URL y luego redirige al usuario del navegador al servicio de inicio de sesión único del proveedor de identidad:

Redirección 302 Ubicación: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

Para obtener una descripción general de cómo construir la cadena de consulta, consulte el flujo del protocolo SAML correspondiente en el artículo de SAML 2.0. Consulte SAMLCore ^{[ OS 6 ]} para obtener más detalles.

El usuario del navegador solicita el punto final del Servicio de inicio de sesión único en el proveedor de identidad en virtud de la redirección:

GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP / 1.1 Host : idp.example.org

El proveedor de identidad devuelve una página de inicio de sesión al navegador del usuario. La página de inicio de sesión contiene un formulario HTML similar al siguiente:

< form method = "post" action = " https://idp.example.com/login-response" ... > Nombre de usuario: <br> < input type = "text" name = " username " > <br> Contraseña : <br> < input type = "password" name = " password" > ... < input type = "submit" value = " Enviar" / > </form>

El usuario del navegador envía el formulario HTML al proveedor de identidad:

POST /login-response HTTP / 1.1 Host : idp.example.com Content-Type : application/x-www-form-urlencoded Content-Length : nnn username = username & password = password

(Emitir una aserción SAML para el usuario)

En este punto, el proveedor de identidad conoce la identidad del usuario principal y, por lo tanto, construye una aserción SAML en nombre de dicho usuario principal. Para un ejemplo concreto de dicha aserción, consulte el flujo del protocolo SAML correspondiente en el artículo sobre SAML 2.0. Como siempre, consulte SAMLCore ^{[ OS 6 ]} para obtener más detalles.

El <saml:NameID>elemento en la aserción SAML codifica un identificador para el principal de usuario. En este caso, el proveedor de identidad incluye un SAML2 Transient NameID (SAMLCore ^{[ OS 6 ]} ) en la aserción SAML.

El proveedor de identidad incluye dos atributos de usuario en la aserción SAML: eduPersonUniqueIdy mail.

En la práctica, el proveedor de identidad firma digitalmente y cifra la aserción SAML, la encapsula en una respuesta SAML y, a continuación, firma también el objeto de respuesta. Normalmente, el proveedor de identidad firma solo la respuesta, pero en este caso tanto la aserción como la respuesta están firmadas digitalmente.

El proveedor de identidad devuelve un documento XHTML al navegador del usuario. El documento contiene una respuesta SAML codificada en formato XHTML de la siguiente manera:

< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> < input type = "hidden" name = "RelayState" value = "token" /> ... < input type = "submit" value = " Enviar" / > </form>

El formulario XHTML es enviado automáticamente por el navegador (debido a un pequeño fragmento de JavaScript en la página):

POST /SAML2/SSO/POST HTTP / 1.1 Host : sp.example.com Content-Type : application/x-www-form-urlencoded Content-Length : nnn SAMLResponse = response & RelayState = token

El proveedor de servicios crea un contexto de seguridad para el usuario principal y redirige al usuario del navegador al recurso de la aplicación web original:

Redirección 302 Ubicación: https://sp.example.com/myresource

Finalmente, el usuario del navegador solicita el recurso de destino al proveedor de servicios en virtud de la redirección:

https://sp.example.com/myresource

Dado que existe un contexto de seguridad, el proveedor de servicios devuelve el recurso al agente de usuario del navegador según lo solicitado.

Nota: El esquema de metadatos de Liberty se encuentra textualmente en los documentos de especificación que se enumeran a continuación. Dado que el enlace directo al  documento XSD de la versión 1.1 en el sitio web de Liberty está roto, se ha subido una copia del documento XSD de los metadatos de Liberty versión  1.1 a la web. Dicho documento también se incluye en el archivo heredado de Liberty ID-FF  1.2 .

Los estándares SAML  V2.0 originales, publicados en marzo de 2005, han sido reemplazados por las especificaciones revisadas, cuyas erratas se detallan más abajo.

• S.  Cantor et al. Aserciones y protocolos para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del documento:  saml-core-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
• S.  Cantor et al. Enlaces para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del documento:  saml-bindings-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
• J.  Hughes et al. Perfiles para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del documento:  saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
• S.  Cantor et al. Metadatos para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del documento:  saml-metadata-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

Salvo las referencias históricas al  estándar de metadatos SAML V2.0 original, las siguientes notas al pie remiten a las especificaciones SAML  V2.0 con erratas . Estas últimas especificaciones incluyen todas las erratas aprobadas por el Comité Técnico de Servicios de Seguridad (SAML) de OASIS desde la  publicación de los estándares SAML V2.0 en marzo de 2005. Para obtener la versión más reciente de cualquier especificación SAML, consulte la wiki de OASIS SAML .

Este es un pequeño subconjunto de las especificaciones del comité "Post-V2.0" publicadas por el Comité Técnico de Servicios de Seguridad (SAML) de OASIS. Para obtener la versión más reciente de cualquier especificación SAML, consulte la wiki de OASIS SAML .