De Wikipedia, la enciclopedia libre
Ir a navegaciónSaltar a buscar

[CS 1] Elestándar de metadatos SAML pertenece a la familia de estándares basados ​​en XML conocidos como Security Assertion Markup Language (SAML) publicado por OASIS en 2005. Un documento de metadatos SAML describe una implementación SAML como un proveedor de identidad SAML o un SAML proveedor de servicios . Las implementaciones comparten metadatos para establecer una línea de base de confianza e interoperabilidad.

Introducción a los metadatos SAML

Para interoperar de forma segura, los socios comparten metadatos en cualquier forma y por cualquier medio posible. En cualquier caso, se deben compartir al menos los siguientes metadatos:

  • ID de entidad
  • Claves criptográficas
  • Puntos finales de protocolo (enlaces y ubicaciones)

Cada entidad del sistema SAML tiene un ID de entidad, un identificador único global que se utiliza en las configuraciones de software, las bases de datos de las partes que confían y las cookies del lado del cliente. En el cable, cada mensaje del protocolo SAML contiene el ID de entidad del emisor.

Para fines de autenticación, el emisor puede firmar digitalmente un mensaje SAML. Para verificar la firma en el mensaje, el receptor del mensaje usa una clave pública que se sabe que pertenece al emisor. De manera similar, para cifrar un mensaje, el emisor debe conocer una clave de cifrado pública que pertenezca al receptor final. En ambas situaciones, firma y encriptación, las claves públicas confiables deben compartirse con anticipación.

Una vez que el mensaje está firmado y cifrado, el emisor envía el mensaje a un punto final de protocolo confiable, cuya ubicación debe conocerse de antemano. Una vez recibido, el receptor del mensaje descifra el mensaje (utilizando su propia clave de descifrado privada) y verifica la firma (utilizando una clave pública de confianza en los metadatos) antes de asignar el ID de entidad en el mensaje a un socio de confianza.

El escenario anterior requiere que cada parte se conozca de antemano. Para establecer una línea de base de confianza, las partes comparten metadatos entre sí. Inicialmente, esto puede ser tan simple como compartir información por correo electrónico. Con el tiempo, a medida que crece el número de socios de SAML, la tendencia natural es automatizar el proceso de intercambio de metadatos.

Para automatizar completamente el proceso de intercambio de metadatos, se necesita un formato de archivo estándar. Con este fin, la especificación de metadatos SAML V2.0 [OS 1] define una representación estándar para los metadatos SAML que simplifica la configuración del software SAML y hace posible crear procesos seguros y automatizados para compartir metadatos.

Interoperabilidad basada en metadatos

A medida que la tecnología SAML ha madurado, la importancia de los metadatos SAML ha aumentado constantemente. Hoy en día, una implementación que admita el inicio de sesión único del navegador web SAML requiere un archivo de metadatos SAML válido para el esquema para cada socio SAML. (Consulte la especificación SAML V2.0 Profiles [OS 2] para obtener más información sobre el SSO del navegador web SAML).

SSO del navegador web SAML con configuración de metadatos estáticos

Configuración de metadatos estáticos

El término metadatos estáticos se refiere a un archivo de metadatos que un administrador configura directamente en la aplicación SAML. Al hacerlo, el administrador se convierte en responsable del mantenimiento de los metadatos independientemente de cómo se obtuvieron los metadatos en primer lugar. Por lo tanto, los metadatos estáticos contribuyen a la configuración estática general de la aplicación SAML.

Desafortunadamente, los metadatos SAML son intrínsecamente no estáticos, como se ilustra en el siguiente escenario típico entre un proveedor de identidad (IdP) SAML y un proveedor de servicios (SP) SAML . Suponga que el propietario de un IdP obtiene metadatos SAML de un socio de SP. Quizás los metadatos del SP se transmitan al propietario del IdP por correo electrónico, o tal vez el propietario del IdP inicie sesión en una aplicación web protegida y descargue los metadatos del SP a través de un navegador. Independientemente de cómo se obtengan los metadatos, el resultado final es el mismo: el propietario del IdP configura los metadatos del SP directamente en el software del IdP.

Ahora suponga que los metadatos del SP contienen una clave de cifrado pública. Presumiblemente, la clave de descifrado privada correspondiente está configurada en el software SP. Si la clave de descifrado privada se ve comprometida (o necesita ser reemplazada), la clave de cifrado pública en los metadatos del SP ya no es confiable y también debe ser reemplazada.

Dado que los metadatos del SP están configurados estáticamente en el software del IdP, solo el propietario del IdP puede reemplazar la clave de cifrado pública en los metadatos del SP. En este sentido, el propietario del IdP es responsable de los metadatos del SP. Esta discrepancia conduce a problemas de interoperabilidad.

Lo mismo ocurre en el lado SP. Al configurar estáticamente los metadatos del IdP en el software del SP, el propietario del SP acepta implícitamente la responsabilidad de mantener los metadatos del IdP cuando algo cambia. Dado que un IdP (o SP) normalmente tiene muchos socios, la configuración de metadatos estáticos claramente no se escala y, además, la gestión de cambios asociada con los metadatos estáticos es, en el mejor de los casos, difícil.

SSO del navegador web SAML con intercambio automático de metadatos

Intercambio dinámico de metadatos

No es sorprendente que los procesos de intercambio de metadatos anhelen automatizarse. Cada archivo de metadatos que un administrador configura estáticamente en la aplicación SAML genera una deuda técnica. La acumulación de esta deuda evita que la implementación de SAML alcance su potencial.

Para evitar una deuda técnica excesiva, el proceso de intercambio de metadatos debe automatizarse. Un enfoque consiste en solicitar la ayuda de un tercero de confianza cuya responsabilidad es recopilar, seleccionar y distribuir metadatos en la red. Los metadatos seleccionados tienen un formato coherente, es más probable que estén libres de vulnerabilidades (intencionales o de otro tipo) 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 de SAML que comprende la federación se ajusta voluntariamente a uno o más perfiles de SAML para promover la interoperabilidad y la confianza. Con ese fin, los participantes de la federación a menudo comparten una infraestructura central para compartir metadatos, lo que permite a la federación escalar a miles de implementaciones SAML interoperables.

Un historial de metadatos SAML

Ahora, recordemos algunos de los pasos que llevaron a la publicación de la especificación de metadatos SAML V2.0 en marzo de 2005. El 14 de noviembre de 2003 se produjo un punto de inflexión: nuestra historia comienza allí.

Orígenes históricos

En respuesta a Microsoft Passport , Liberty Alliance concibió Identity Federation Framework , 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 Versión 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 a través de 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 con el archivo legado de Liberty ID-FF 1.2 se identifica como Liberty Metadata Version 1.1, mientras que Liberty Metadata Version 1.0 se contribuyó a OASIS. La aparente contradicción fue explicada por el autor del esquema. (Peter Davis, Comunicación personal) Entre noviembre de 2003 (cuando se contribuyó con 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 cuadro a continuación para obtener una representación visual. Las flechas del gráfico indican dependencias, mientras que las líneas discontinuas indican equivalencias.

Dependencias de metadatos SAML

Las referencias relevantes al flujo de trabajo de Liberty se dan al final de este artículo. El esquema de metadatos original aportado a OASIS se enumera en su totalidad en la sección 7 de la especificación Liberty Metadata Version 1.0 [LibertyMeta 1] . De manera similar, la especificación de Liberty Metadata Versión 1.1 [LibertyMeta 2] incluye una lista del esquema de la Versión 1.1. Tanto el esquema de la Versión 1.0 como el esquema de la Versión 1.1 están vinculados aquí por cortesía de Wayback Machine de Internet Archive.

Posterior a noviembre de 2003

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

En marzo de 2004, la mayor parte de la contribución de Liberty se incorporó al flujo de trabajo de OASIS. [SAMLMeta 1] A partir de ese momento, los flujos de trabajo de Liberty y OASIS progresaron al mismo tiempo (pero no de forma independiente, ya que las mismas personas estaban trabajando en ambas especificaciones). Entre marzo y julio de 2004, la incipiente especificación de metadatos SAML experimentó una rotación significativa.

En julio de 2004, la SSTC emitió una convocatoria pública de comentarios sobre un conjunto completo de especificaciones preliminares de SAML V2.0. En ese conjunto de especificaciones se incluyó un borrador de trabajo de una especificación de metadatos SAML V2.0 recién forjada. [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 los lomos de Liberty Alliance, específicamente Liberty Metadata Version 1.0. [LibertyMeta 1] En consecuencia, para comprender los orígenes de los metadatos SAML, uno debe estudiar la procedencia de los metadatos Liberty.

El historial restante de los metadatos SAML es principalmente el proceso administrativo de OASIS. Después de que se publicó el Borrador final del Comité en noviembre de 2004, [SAMLMeta 3] la SSTC comenzó el proceso de estandarización en enero de 2005. Finalmente, el 5 de marzo de 2005, OASIS anunció el estándar SAML V2.0 recientemente ratificado.

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 revisada de metadatos SAML con erratas. [OS 3] Como resultado, la especificación de metadatos original quedó obsoleta, al igual que los otros documentos del conjunto de especificaciones 2.0 original.

Durante la década intermedia, entre 2005 y 2015, la SSTC desarrolló una serie de especificaciones preliminares "Post-V2.0". Algunos de estos borradores de documentos se convirtieron en Especificaciones del Comité. Un subconjunto selecto de estas Especificaciones del Comité se enumera en la sección de Referencias al final de este artículo.

Antes de noviembre de 2003

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, la SSTC estaba incursionando en metadatos en paralelo con Liberty Alliance. Un extracto de un borrador de especificación de metadatos publicado en septiembre de 2003 lo confirma:

Este documento define metadatos que describen los elementos y atributos necesarios para utilizar los perfiles SSO del navegador web SAML. Dado que los perfiles de SSO web de Liberty Alliance se basan directamente en los perfiles de SSO web de SAML, los metadatos definidos en este documento se basan en gran medida en las definiciones de metadatos del borrador de las especificaciones de Liberty Alliance 1.2. (Extraído de "Metadatos para perfiles de SSO del navegador web SAML 2.0" [SAMLMeta 4] )

El historial de revisiones al final de ese documento borrador da la siguiente caracterización de sí mismo: "Borrador inicial basado en el Borrador 07 de la especificación de metadatos SAML 1.1". En otras palabras, se publicaron borradores de documentos anteriores. De hecho, el historial de revisiones al final del borrador anterior [SAMLMeta 5] muestra un rastro de especificaciones de metadatos que se remonta a noviembre de 2002.

Siguiendo el rastro del documento, la influencia de Liberty ID-FF en los metadatos SAML se puede rastrear hasta 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 Version 1.0-06, [LibertyMeta 3] una versión temprana de la especificación de metadatos de Liberty acerca de la cual se sabe poco. Sin embargo, está claro que "Metadata for SAML 1.1 Web Browser Profiles" tenía la intención de 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 tempranos pueden ser de interés:

  1. En junio de 2002, apenas un mes después de que la SSTC completara su trabajo en lo que se convertiría en el estándar SAML V1.0, el proyecto Shibboleth desarrolló un esquema de metadatos que constaba de elementos <OriginSite>y <DestinationSite>. Este esquema impulsaría las versiones iniciales del software Shibboleth IdP.
  1. En febrero de 2003, la SSTC publicó un esquema preliminar para una especificación de metadatos titulado "Metadatos para perfiles de navegador 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ía la sintaxis de metadatos de Liberty.

No hay evidencia que sugiera 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.

Resumen histórico

Sabemos que los estándares de metadatos para SAML V1.0 o SAML V1.1 nunca se publicaron. También sabemos que el IPR necesario para los metadatos de Liberty no estuvo vigente hasta noviembre de 2003. Con eso, 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 tiene fecha del 12 de noviembre de 2002, que es una semana después de que se anunciara el estándar SAML V1.0, lo cual es curioso. En cualquier caso, la sintaxis de metadatos utilizada en ese documento es completamente diferente de lo que ahora conocemos como metadatos SAML. Ese documento nunca se publicó y sus orígenes siguen 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 la especificación deja en claro que la SSTC sabía que SAML V1.1 estaba por llegar y, además, los metadatos de SAML se incluirían en el Estándar SAML V1.1.
  3. Desafortunadamente, eso no sucedió ya que el IPR necesario no estaba vigente cuando se anunció el estándar SAML V1.1. De hecho, la contribución formal de Liberty ID-FF 1.2 a OASIS ocurrió 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, la SSTC puso su mirada en SAML V2.0 bifurcando el flujo de documentos y cambiando el nombre del documento borrador: "Metadatos para perfiles de navegador web SAML 2.0". [SAMLMeta 4]
  5. Los metadatos SAML cobraron vida entre marzo y julio de 2004. La SSTC emitió una convocatoria pública de comentarios que incluía una especificación de metadatos SAML candidata. [SAMLMeta 2]
  6. La especificación final de metadatos SAML [OS 1] se incluyó en el conjunto de especificaciones 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 metadatos SAML V2.0 con erratas (SAMLMeta20Errata [OS 3] ).

Especificaciones posteriores a la versión 2.0

Como se mencionó anteriormente, el esquema de metadatos SAML V2.0 [OS 4] tiene numerosos puntos de extensión. Esta característica llevó a una proliferación de especificaciones "Post-V2.0" que extendieron el estándar en varias direcciones. Las extensiones de metadatos más populares se enumeran a continuación 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 de inicio de solicitud de proveedor de servicios y perfil Versión 1.0. [CS 5]
  6. Perfil de metadatos SAML V2.0 para compatibilidad con algoritmos Versión 1.0. [CS 6]

Una especificación importante "Post-V2.0" es el perfil de interoperabilidad de metadatos SAML V2.0, [CS 7] que se basa en la premisa de que una infraestructura de clave pública formal (PKI) puede ser extremadamente compleja y, en algunos casos, intratable (es bien conocido, por ejemplo, que la revocación del certificado TLS en el navegador no funciona [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 (ver, por ejemplo, los requisitos relacionados con certificados para implementadores [Misc 2] en una gran federación de I + E). La interoperabilidad de metadatos juega un papel clave en un perfil de implementación formal publicado por la Iniciativa Kantara:

Las implementaciones DEBEN soportar la interpretación y aplicación de metadatos según lo definido por el perfil de interoperabilidad de metadatos SAML V2.0. De ello se desprende que las implementaciones DEBEN ser capaces de interoperar (conduciendo al éxito o al fracaso según lo dictado por la configuración predeterminada) con cualquier número de pares SAML para los cuales hay metadatos disponibles, sin entradas adicionales o configuración separada. [Misc 3]

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

Ejemplos de metadatos SAML

En esta sección damos ejemplos concretos del descriptor de entidad SAML , la unidad básica de política e interoperabilidad en metadatos SAML. Cada uno de los ejemplos incluye los siguientes bits de metadatos:

  • ID de entidad y atributos de entidad
  • Descriptor de rol (que describe un proveedor de identidad SAML o un proveedor de servicios SAML )
    • Elementos de la interfaz de usuario
    • Firma de claves o claves de cifrado
    • Puntos finales de protocolo de inicio de sesión único
  • Información de registro y publicación
  • Organización y información de contacto (para lectores humanos)

En los ejemplos a continuación, un URI particular en los metadatos (como una entityIDubicación de punto final) se asigna a una parte responsable a través del componente de dominio del URI:

  • La organización propietaria del dominio example.infoes responsable de una entidad SAML no especificada (como un proveedor de identidad o un proveedor de servicios)
  • La organización propietaria del dominio example.orges responsable de un proveedor de identidad SAML
  • La organización propietaria del dominio example.comes responsable de un proveedor de servicios SAML
  • La organización propietaria del dominio example.netes un tercero de confianza responsable del registro y la publicación de metadatos.

Tenga en cuenta que los metadatos SAML describen a todas las partes involucradas en el SSO del navegador web SAML basado en metadatos, excepto el usuario del navegador. (Consulte la especificación SAML V2.0 Profiles [OS 2] para obtener más información sobre el SSO del navegador web SAML).

Metadatos de la entidad

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: nombres: tc: SAML: 2.0: metadatos "  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# " >  <! - insert ds: Signature element (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- categoría "  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>  <! - inserte una o más instancias concretas del tipo abstracto md: RoleDescriptor (ver más abajo) ->  <md: Organization>  <md:  Nombre de la organización 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 de SAML </ md: SurName>  <md: EmailAddress> mailto: [email protected] < / 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. Tenga en cuenta que entityIDes un nombre inmutable para la entidad, no una ubicación.
  • El validUntilatributo da la fecha de vencimiento de los metadatos.
  • El <ds:Signature>elemento (que se ha omitido por simplicidad) contiene una firma digital que asegura la autenticidad e integridad de los metadatos. Se supone 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] afirma el editor de metadatos (que resulta ser el mismo que el registrador). El creationInstantatributo da el instante preciso en que se crearon los metadatos. Comparando el valor del creationInstantatributo con el valor del validUntilatributo, vemos que los metadatos son válidos por dos semanas.
  • El <mdattr:EntityAttributes>elemento de extensión [CS 2] incluye un atributo de entidad única. El atributo de entidad afirma que la entidad está "autocertificada", una cualidad presuntamente 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 el idioma de cada tipo.
  • La información de contacto en el <md:ContactPerson>elemento identifica un contacto técnico responsable de la entidad. Son posibles múltiples contactos y tipos de contactos. Consulte la sección 2.3.2.2 de SAMLMeta. [OS 3]

El descriptor de rol de suma importancia se ha omitido de 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 están descritos por el <md:IDPSSODescriptor>elemento y el <md:SPSSODescriptor>elemento. Cada uno de estos descriptores de funciones se ilustra en las subsecciones siguientes.

Metadatos del proveedor de identidad

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 estos 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# " >  <! - insert ds: Signature element (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: // registrador. 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: Extensiones>  <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 : nombres: tc: SAML: 2.0: enlaces: 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 de SAML </ md: SurName>  <md: EmailAddress > mailto: [email protected] </ md: EmailAddress>  </ md: ContactPerson>  </ md: EntityDescriptor>

El contenido del <md:IDPSSODescriptor>elemento describe el servicio de inicio de sesión único en el 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 el lenguaje que se utilizan para construir interfaces de usuario dinámicas en el proveedor de servicios. La interfaz de usuario más importante del proveedor de servicios es la interfaz de descubrimiento del proveedor de identidad.
  • Es de suponer que el software del proveedor de identidad está configurado con una clave de firma SAML privada. La clave pública correspondiente se incluye en el <md:KeyDescriptor use="signing">elemento. En el ejemplo anterior, el material clave se ha omitido del descriptor 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 mensajes SAML, lo que minimiza la posibilidad de que un proveedor de identidad deshonesto orquesta un ataque de intermediario .

Metadatos del proveedor de servicios

Un proveedor de servicios SAML gestiona un punto final de servicio de consumidor de afirmaciones [OS 2] que recibe afirmaciones 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 un punto final de este tipo:

 <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- protocolo "  xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " >  <! - insertar ds: elemento de firma (omitido) -> <md: Extensiones>  <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 = "verdadero" 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: // servicio. 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" > Example.com Employee Portal </ 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 " Nombre = "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 de SAML </ md: SurName>  <md: EmailAddress>mailto: [email protected] </ md: EmailAddress>  </ md: ContactPerson>  </ md: EntityDescriptor>

El contenido del <md:SPSSODescriptor>elemento describe el Servicio al consumidor de afirmaciones en el 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 hace que un proveedor de identidad con reconocimiento de metadatos se autoconfigure en tiempo de ejecución.
  • El <mdui:UIInfo>elemento de extensión [CS 3] contiene un conjunto de elementos de extensión calificados por el lenguaje 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 utilizado junto con el descubrimiento del proveedor de identidad.
  • Es de suponer que el software del proveedor de servicios está configurado con una clave de descifrado SAML privada. Se incluye una clave de cifrado SAML pública en el <md:KeyDescriptor use="encryption">elemento. En el ejemplo anterior, el material clave se ha omitido del descriptor clave por brevedad.
  • El <md:NameIDFormat>elemento da el formato deseado del <saml:NameID>elemento en la aserción SAML. La presencia de este elemento hace que un proveedor de identidad con reconocimiento de metadatos se autoconfigure en tiempo de ejecución.
  • El indexatributo de un <md:AssertionConsumerService>elemento se usa como el valor del AssertionConsumerServiceIndexatributo en un <samlp:AuthnRequest>elemento.
  • El Bindingatributo del <md:AssertionConsumerService>elemento es un URI estándar especificado en la especificación de enlace SAML 2.0 (SAMLBind [OS 5] ).
  • El <md:AttributeConsumingService>proveedor de identidad utiliza el <saml:AttributeStatement>elemento para formular un elemento que se envía al proveedor de servicios junto con el SSO del navegador web SAML.
  • El indexatributo del <md:AttributeConsumingService>elemento se usa como el valor del AttributeConsumingServiceIndexatributo en un <samlp:AuthnRequest>elemento.

Un md:AssertionConsumerService/@Locationproveedor de identidad utiliza el valor del atributo en los metadatos del proveedor de servicios para enrutar los mensajes SAML, lo que minimiza la posibilidad de que un proveedor de servicios deshonesto orquesta un ataque de intermediario .

Navegador web SAML basado en metadatos

El siguiente flujo del protocolo SAML está destinado a ilustrar el uso de metadatos en varias etapas del SSO del navegador web SAML. (Consulte la especificación SAML V2.0 Profiles [OS 2] para obtener más información sobre el SSO del navegador web SAML).

SSO del navegador web SAML con descubrimiento e inicio de sesión

Los metadatos SAML confiables garantizan una transacción segura entre un proveedor de identidad SAML (IdP) y un proveedor de servicios SAML (SP). Antes de los metadatos, la información de confianza se codificaba en la implementación de forma patentada. Ahora, los metadatos estándar facilitan el intercambio de información de confianza. El estándar de metadatos SAML 2.0 [OS 3] proporciona un formato de metadatos interoperable bien definido que las entidades pueden utilizar para iniciar el proceso de confianza.

La siguiente secuencia ilustra el uso de metadatos SAML para impulsar el flujo del protocolo SAML.

1. Solicite el recurso de destino en el SP

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 el principal de usuario en el proveedor de servicios, omita los pasos 2 a 13.

2. Redirigir al Servicio de descubrimiento

Antes de que el proveedor de servicios pueda iniciar el flujo del protocolo SAML en el paso 6, se debe conocer el proveedor de identidad preferido del usuario del navegador. Existen numerosas formas de hacer esto. Con fines ilustrativos, el proveedor de servicios utilizará un servicio de descubrimiento local que se ajuste al perfil y protocolo del servicio de descubrimiento del proveedor de identidad. [CS 4]

El proveedor de servicios redirige al usuario del navegador al Discovery Service:

Ubicación de redireccionamiento 302 : 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 según lo especificado por el protocolo de descubrimiento.

3. Solicite el servicio de descubrimiento

El usuario del navegador solicita el Discovery Service en virtud del redireccionamiento:

GET  /idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal  HTTP / 1.1 Host :  ds.example.com
Proveedores de servicios de confianza en metadatos

¿Cómo sabe el Servicio Discovery que el proveedor del servicio es auténtico y no un impostor malvado que intenta conocer el proveedor de identidad del usuario con fines nefastos?

Discovery Service consulta su lista de proveedores de servicios de confianza en metadatos antes de emitir una respuesta.

(Descubra el IdP preferido del usuario)

El Servicio de descubrimiento descubre el proveedor de identidad preferido del usuario del navegador por medios no especificados.

Elementos de la interfaz de usuario en metadatos

¿Cómo construye Discovery Service una interfaz de descubrimiento adecuada?

Discovery Service consulta su almacén de metadatos de confianza para determinar una lista adecuada de proveedores de identidad de confianza para presentar al usuario del navegador. Los <mdui:UIInfo>elementos de la interfaz de usuario en los metadatos pueden usarse para construir una interfaz de descubrimiento dinámica.

4. Redirigir al punto final de Discovery Response en el SP

Discovery Service ahora redirige al usuario del navegador a un punto final de Discovery Response en el proveedor de servicios:

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

Tenga en cuenta que el IdP entityIDse incluye en la URL de redireccionamiento según lo especificado por el protocolo de descubrimiento.

Ubicaciones confiables de endpoints en metadatos

¿Cómo sabe el Servicio de descubrimiento adónde enviar al usuario con el IdP entityID?

Discovery Service busca una ubicación de punto final de Discovery Response preestablecida del proveedor de servicios de confianza en los metadatos .

5. Solicite el punto final de Discovery Response en el SP

El usuario del navegador solicita el punto final de Discovery Response 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 Discovery Response en el proveedor de servicios se ajusta al perfil y protocolo de servicio de descubrimiento del proveedor de identidad. [CS 4]

Proveedores de identidad de confianza en metadatos

¿Cómo sabe el proveedor de servicios que el proveedor de identidad propuesta por el entityIDen la URL de protocolo de detección es auténtico y no un proveedor de identidad del mal tratando de phishing contraseña del usuario?

El proveedor de servicios consulta su lista de proveedores de identidad confiables en metadatos antes de emitir una Solicitud SAML en el siguiente paso. Si el proveedor de servicios no puede determinar si el proveedor de identidad en cuestión es de confianza, el usuario del navegador no debe ser redirigido al IdP. Por esta razón, es imperativo que IdP metadatos debe confiar en los metadatos.

6. Redirigir al servicio SSO en el IdP

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

Ubicación de redireccionamiento 302 : 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.

Ubicaciones confiables de endpoints en metadatos

¿Cómo sabe el proveedor de servicios adónde enviar al usuario con la solicitud SAML?

El proveedor de servicios busca una ubicación de punto final preestablecida del proveedor de identidad de confianza en los metadatos .

7. Solicite el servicio SSO en el IdP

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
Proveedores de servicios de confianza en metadatos

¿Cómo sabe el proveedor de identidad que el proveedor de servicios es auténtico y no un proveedor de servicios malvado que intenta recopilar información de identificación personal sobre el usuario?

El proveedor de identidad consulta su lista de proveedores de servicios de confianza en metadatos antes de emitir una respuesta.

8. Responda con la página de inicio de sesión

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:

 < Forma  método = "post"  acción = "https://sp.example.com/login-response"  ... > Usuario: < br >  < entrada de  tipo = "texto"  nombre = "nombre de usuario" > < br > Contraseña : < br >  < entrada  tipo = "contraseña"  nombre = "contraseña" > ... < input  type = "submit"  value = "Submit"  />  </ form >
Elementos de la interfaz de usuario en los metadatos
Para tranquilizar al usuario del navegador, el IdP personaliza la página de inicio de sesión utilizando los <mdui:UIInfo>elementos de la interfaz de usuario en los metadatos.

9. Envíe el formulario de inicio de sesión

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

POST  / login-response  HTTP / 1.1 Host :  sp.example.com Content-Type :  application / x-www-form-urlencoded Content-Length :  nnn nombre de usuario = nombre de usuario y contraseña = contraseña

(Emita una afirmación SAML para el usuario)

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

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

Formato de NameID en metadatos

¿Por qué el proveedor de identidad utiliza un formato de Id. De nombre transitorio en la afirmación SAML (a diferencia de algún otro formato)?

Suponiendo que el <samlp:AuthnRequest>elemento emitido por el proveedor de servicios no solicite lo contrario, un IdP consciente de los metadatos consultará los <md:NameIDFormat>elementos en los metadatos (si los hay) para determinar el formato de NameID.

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

Atributos solicitados en metadatos

¿Por qué el proveedor de identidad incluye atributos eduPersonUniqueIdy mailen la aserción y no algunos otros atributos?

Un IdP consciente de los metadatos consultará los <md:RequestedAttribute>elementos de los metadatos (si los hubiera) para conocer los requisitos de atributos del proveedor de servicios.

Desde el punto de vista operativo, el proveedor de identidad firma y cifra digitalmente la afirmación SAML, envuelve la afirmación en una respuesta SAML y, a continuación, también firma el objeto Respuesta. Normalmente, el proveedor de identidad firma solo la Respuesta, pero en este caso tanto la Afirmación como la Respuesta están firmadas digitalmente.

Atributo WantAssertionsSigned en metadatos

¿Cómo sabe el proveedor de identidad que el proveedor de servicios desea que la afirmación se firme digitalmente?

En tiempo de ejecución, el proveedor de identidad observa que el WantAssertionsSignedatributo XML en los metadatos está establecido en verdadero.
Certificado de cifrado confiable en metadatos

¿Cómo cifra el proveedor de identidad la afirmación SAML para que el proveedor de servicios (y solo el proveedor de servicios) pueda descifrarla?

En tiempo de ejecución, el proveedor de identidad utiliza el certificado de cifrado del proveedor de servicios en los metadatos para cifrar la afirmación.

10. Responda con la página de respuesta SAML

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

 < form  method = "post"  action = "https://sp.example.com/SAML2/SSO/POST"  ... >  < input  type = "hidden"  name = "SAMLResponse"  value = "response"  />  < tipo de entrada  = "oculto" nombre = "RelayState" valor = "token" />    ... < input  type = "submit"  value = "Submit"  />  </ form >
Ubicaciones confiables de endpoints en metadatos

¿Cómo sabe el proveedor de identidad adónde enviar al usuario con la respuesta SAML?

El proveedor de identidad busca una ubicación de punto final preestablecida del proveedor de servicios de confianza en los metadatos .

11. Solicite el Servicio al Consumidor de Afirmación en el SP

El navegador envía automáticamente el formulario XHTML (debido a un poco 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 = respuesta & RelayState = token
Certificado de firma confiable en metadatos

¿Cómo sabe el proveedor de servicios que la respuesta SAML proviene de un proveedor de identidad de confianza?

El proveedor de servicios verifica la firma digital en la Respuesta utilizando la clave pública del proveedor de identidad en los metadatos . Después de descifrar la firma en el objeto Assertion, el proveedor de servicios verifica también la firma en el Assertion.

12. Redirigir al recurso de destino

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

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

13. Solicite el recurso de destino en el SP nuevamente

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

14. Responder con el recurso solicitado

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

Ver también

  • Lenguaje de marcado de aserción de seguridad (SAML)
  • SAML 2.0
  • XML (lenguaje de marcado extensible)
  • Esquema XML (W3C)
  • Firma XML
  • Cifrado XML

Referencias

Especificaciones de metadatos de Liberty

Nota: El esquema de metadatos de Liberty se enumera literalmente en los documentos de especificación que se enumeran a continuación. Dado que el enlace directo al documento XSD Versión 1.1 en el sitio web de Liberty está roto, se ha cargado una copia del documento XSD para Liberty Metadata Versión 1.1 en la web. Ese documento también se incluye en el archivo legado de Liberty ID-FF 1.2 .

  1. ^ a b c P. Davis (Editor). Descripción de metadatos de Liberty y especificación de descubrimiento. Versión 1.0, 12 de noviembre de 2003. Identificador del documento: liberty-metadata-v1.0. http://www.projectliberty.org/liberty/content/download/2024/13989/file/liberty-metadata-v1.0.pdf
  2. ^ P. Davis (editor). Descripción de metadatos de Liberty y especificación de descubrimiento. Versión 1.1, 14 de diciembre de 2004. Identificador del documento: liberty-metadata-v1.1. http://www.projectliberty.org/liberty/content/download/1224/7973/file/liberty-metadata-v1.1.pdf
  3. ^ P. Davis (editor). Descripción de metadatos de Liberty y especificación de descubrimiento. Versión preliminar 1.0-06, 13 de abril de 2003.

Especificaciones de metadatos SAML anteriores a 2005

  1. ^ J. Moreh y S. Cantor (Editores). Metadatos para SAML 2.0. Borrador de trabajo 01, 15 de marzo de 2004. ID de documento sstc-saml-Metadata-2.0-draft-01.
  2. ^ a b J. Moreh y col. (editores). Metadatos para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS. Borrador de trabajo de última convocatoria 08, 13 de julio de 2004. ID de documento sstc-saml-metadata-2.0-draft-08. http://xml.coverpages.org/SSTC-SAMLMetadataV20Draft08-7750.pdf ( https://drive.google.com/file/d/0B7vociYknAbCelh1TmhjRVBZdmc/view?usp=sharing )
  3. ^ J. Moreh y col. (editores). Metadatos para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS. Borrador del Comité 02e, 11 de noviembre de 2004. ID de documento sstc-saml-metadata-2.0-cd-02e. https://www.oasis-open.org/committees/download.php/10037/sstc-saml-metadata-2.0-cd-02e.pdf
  4. ^ a b J. Moreh (Editor). Metadatos para perfiles de SSO del navegador web SAML 2.0. Borrador de trabajo 00, 15 de septiembre de 2003. ID de documento sstc-saml-metadata-2.0-draft-00. https://www.oasis-open.org/committees/download.php/4538/sstc-saml-metadata-2.0-draft-00.pdf
  5. ^ J. Moreh y col. (editores). Metadatos para perfiles de navegador web SAML 1.1. Borrador de trabajo 07, 23 de julio de 2003. ID de documento sstc-saml-meta-data-draft-07. https://www.oasis-open.org/committees/download.php/3002/draft-sstc-saml-meta-data-07.doc ( https://drive.google.com/file/d/0B7vociYknAbCRUJ6UzNuTnNiOW8/ ver? usp = compartir )
  6. ^ a b J. Moreh y col. (editores). Metadatos para perfiles de navegador web SAML 1.1. Borrador de trabajo 02, 23 de abril de 2003. Documento de identificación draft-sstc-saml-meta-data-02. https://www.oasis-open.org/committees/download.php/1735/draft-sstc-saml-meta-data-02.doc ( https://drive.google.com/file/d/0B7vociYknAbCYTFRYVdWcGx1Qlk/ ver? usp = compartir )
  7. ^ P. Mishra y col. (editores). Metadatos para perfiles de navegador web SAML 1.0. Borrador de trabajo 01, 1 de febrero de 2003. Documento de identificación draft-sstc-saml-meta-data-01. http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-meta-data-01.pdf ( https://drive.google.com/file/d/0B7vociYknAbCLTJWY0p3bXFYS1E/view? usp = compartir ) https://www.oasis-open.org/committees/security/docs/draft-sstc-schema-meta-data-01.xsd
  8. ^ P. Mishra (editor). Metadatos para perfiles de navegador web SAML 1.0. Borrador de trabajo 00, 12 de noviembre de 2002. Documento de identificación draft-sstc-saml-meta-data-00. http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-meta-data-00.pdf ( https://drive.google.com/file/d/0B7vociYknAbCNEZIaDVwaWhXLUU/view? usp = compartir )

Estándares SAML

Los estándares SAML V2.0 originales publicados en marzo de 2005 han quedado obsoletos en favor de las especificaciones revisadas con erratas que se enumeran más adelante.

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

A excepción de las referencias históricas al estándar de metadatos SAML V2.0 original, las siguientes notas al pie apuntan a especificaciones SAML V2.0 con erratas . Las últimas especificaciones incluyen todas las erratas aprobadas por el Comité Técnico de Servicios de Seguridad de OASIS (SAML) desde que se publicaron los estándares SAML V2.0 en marzo de 2005. Consulte el Wiki SAML de OASIS para obtener la versión más reciente de cualquier especificación SAML.

  1. ^ a b c S. Cantor y col. Metadatos para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID de documento saml-metadata-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
  2. ^ a b c d e J. Hughes y col. Perfiles para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS - Compuesto de erratas. Borrador de trabajo 07, 8 de septiembre de 2015. ID de documento sstc-saml-profiles-errata-2.0-wd-07 https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata -2.0-wd-07.pdf
  3. ^ a b c d e f S. Cantor et al. Metadatos para OASIS Security Assertion Markup Language (SAML) V2.0 - Compuesto de erratas. Borrador de trabajo 05, 8 de septiembre de 2015. ID de documento sstc-saml-metadata-errata-2.0-wd-05 https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata -2.0-wd-05.pdf
  4. ^ Esquema de metadatos para OASIS Security Assertion Markup Language (SAML) V2.0. Estándar OASIS, marzo de 2005. ID de documento saml-schema-metadata-2.0 http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd
  5. ^ a b S. Cantor y col. Enlaces para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS - Compuesto de erratas. Borrador de trabajo 06, 8 de septiembre de 2015. ID de documento sstc-saml-bindings-errata-2.0-wd-06 https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata -2.0-wd-06.pdf
  6. ^ a b c S. Cantor y col. Afirmaciones y protocolos para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS - Compuesto de erratas. Borrador de trabajo 07, 8 de septiembre de 2015. ID de documento sstc-saml-core-errata-2.0-wd-07 http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata -2.0-wd-07.pdf

Especificaciones del comité posteriores a 2005

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

  1. ^ a b c d Extensiones de metadatos SAML V2.0 para información de registro y publicación, versión 1.0. Especificación 01 del Comité Técnico de Servicios de Seguridad de OASIS (SAML), 03 de abril de 2012. https://wiki.oasis-open.org/security/SAML2MetadataDRI
  2. ^ a b Extensión de metadatos SAML V2.0 para atributos de entidad. Especificación 01 del Comité Técnico de Servicios de Seguridad de OASIS (SAML), 4 de agosto de 2009. https://wiki.oasis-open.org/security/SAML2MetadataAttr
  3. ^ a b c Extensiones de metadatos SAML V2.0 para la interfaz de usuario de inicio de sesión y descubrimiento Versión 1.0. Especificación 01 del Comité Técnico de Servicios de Seguridad de OASIS (SAML), 03 de abril de 2012. https://wiki.oasis-open.org/security/SAML2MetadataUI
  4. ^ a b c d Protocolo y perfil del servicio de descubrimiento del proveedor de identidad. Especificación 01 del Comité Técnico de Servicios de Seguridad de OASIS (SAML), 27 de marzo de 2008. https://wiki.oasis-open.org/security/IdpDiscoSvcProtonProfile
  5. ^ Protocolo de inicio de solicitud de proveedor de servicios y versión de perfil 1.0. Especificación 01 del Comité Técnico de Servicios de Seguridad de OASIS (SAML), 5 de noviembre de 2010. https://wiki.oasis-open.org/security/RequestInitProtProf
  6. ^ Perfil de metadatos SAML V2.0 para compatibilidad con algoritmos versión 1.0. Especificación 01 del Comité Técnico de Servicios de Seguridad de OASIS (SAML), 21 de febrero de 2011. https://wiki.oasis-open.org/security/SAML2MetadataAlgSupport
  7. ^ Perfil de interoperabilidad de metadatos SAML V2.0. Especificación 01 del Comité Técnico de Servicios de Seguridad de OASIS (SAML), 4 de agosto de 2009. https://wiki.oasis-open.org/security/SAML2MetadataIOP

Varios

  1. ^ Hanno Böck. El problema con el grapado OCSP y debe grapar y por qué la revocación del certificado aún no funciona. 19 de mayo de 2017. https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html
  2. ^ Certificados SAML en metadatos de federación. Federación InCommon. https://spaces.internet2.edu/x/boY0
  3. ^ Perfil de implementación de SAML V2.0 para la interoperabilidad de la federación. Iniciativa Kantara. https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html