aserción SAML con nombre de usuario / contraseña - ¿qué los mensajes parecen realmente?

Question

Es necesario crear un algunas afirmaciones SAML 2.0, y estoy teniendo problemas para encontrar lo que realmente el XML debe ser similar. La mayor parte de la documentación parece ser sobre el uso de herramientas particulares, no se trata de los mensajes. Tengo los esquemas, con una gran cantidad de posibilidades, pero no puedo encontrar un ejemplo de lo que los mensajes relevantes parecen realmente en la práctica.

La regla de negocio dice: con el fin de crear una identidad compartida, el usuario le ordena al sistema A su nombre de usuario y contraseña en el sistema B. Sistema A tiene que comunicar esta información (junto con algunos datos demográficos) para el sistema B. Sistema B valida la información y pasa de nuevo un identificador único que puede ser usado para referirse a este usuario.

Podría alguien darme un ejemplo de lo SAML 2.0 afirmaciones se vería como para llevar esta información?

Fwiw, estoy usando C #, y la necesidad de pasar el XML alrededor de manera que impiden que utilizan una herramienta de tercera parte.

Answer 1

No estoy seguro de su caso de uso es bastante lo que hace SAML 2.0.

Lo que usted describe como sus reglas de negocio que en realidad parece un caso de uso para el aprovisionamiento de identidad, no tener acceso a la gestión.

casos estándar SAML 2.0 uso centran en una parte que afirma la identidad (el proveedor de identidad) y la otra parte (o partes) apoyándose en esas afirmaciones (proveedor de servicios). Afirmaciones llevan lo que se llama un identificador de nombre, el uso de que se acuerda de antemano entre el proveedor de identidad y el proveedor de servicios.

Estos identificadores nombre puede ser casi cualquier cosa, pero en general se dividen en dos categorías: transitorios y persistentes. Un nombre identificador transitoria sólo es útil en el contexto de la sesión actual (y esencialmente sólo dice: "Yo sé quién es esta persona") y tiende a ser utilizado para proteger la identidad del principal al tiempo que permite un acceso privilegiado de algún tipo. Un identificador persistente o bien puede ser opaca (de una manera similar a cómo se utiliza OpenID para acceder SO), donde la parte que afirma puede comprobar en repetidas ocasiones la identidad de un principio sin revelar su identidad mientras se mantiene un identificador dinámico pero estable compartida entre el afirmar y partes dependientes o más sustanciales, tales como Active Directory UPN (que pueden ser pre-acordada de antemano).

Cuando se trata de contraseñas, como se menciona en su pregunta, el proveedor de servicios (parte que confía) nunca ve la contraseña de los usuarios. El proveedor de servicios de entrega al usuario hacia el proveedor de identidad con una solicitud de autenticación. El proveedor de identidad envía al usuario de vuelta al proveedor de servicios con una respuesta, que en el caso de una autenticación exitosa contiene una afirmación acerca de la identidad del usuario en el contexto de la relación entre el proveedor de identidad y el proveedor de servicios.

En el contexto de su pregunta, la gran cosa es que SAML 2.0 no proporciona una forma de crear ya sea la cuenta de usuario "aplicación" local o enlace de esa cuenta de usuario local para una identidad federada. Esto no es simplemente el problema de SAML 2.0 trata de resolver.

Ahora, de vuelta a sus reglas de negocio ...

A mi me parece como lo que estamos tratando de hacer es o bien la vinculación de cuentas o registro - me acercaría así:

• aplicación de las visitas de los usuarios, hace clic en un botón para usar la identidad del proveedor de identidad
• La aplicación produce una solicitud de autenticación y dirige al usuario el proveedor de identidad, llevando a que la solicitud de autenticación
• El proveedor de identidad, ya sea en los registros de usuario o reutiliza una sesión de identidad existente si el usuario tiene uno. El IdP produce un mensaje de respuesta que contiene una afirmación sobre el usuario. En su caso esta afirmación debe llevar como mínimo un identificador de nombre persistente. El proveedor de identidad dirige al usuario a la aplicación, llevando el mensaje de respuesta.
• La aplicación procesa el mensaje de respuesta. Si existe una entrada de asignación para el identificador persistente pasado el usuario es reconocido de que la cartografía y conectado como que usuario de la aplicación local. Si no existe una entrada de asignación al usuario se le puede pedir para iniciar la sesión localmente, y en un éxito local de la conexión de la entrada de asignación puede ser producido, o una cuenta de usuario se puede crear de forma automática y el usuario se le puede pedir que introduzca información adicional (nombres, direcciones de correo electrónico , etc.) el caso de uso "corporativo" sería que no cuenta automática que une o se permite la creación y que el mapeo debe existir antes de tiempo.

En cuanto al contenido de los mensajes ...

El href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security" rel="noreferrer"> Comité tiene un archivo zip descarga disponible con una amplia documentación de las partes del esquema XML, incluyendo ejemplos. También es bien vale la pena leer la documentación del protocolo y el perfil, ya que describen el flujo de mensajes entreLas partes implicadas en la conversación de identidad.

Hay un gran número de presentaciones que flotan alrededor que me pareció muy útil. Específicamente, Fundamentos de SAML v2.0 por Eve Maler me ayudaron a empezar a darse cuenta de lo SAML v2.0 problemas estaba tratando de resolver. Esta presentación incluye ejemplos de afirmaciones que parecen. Hay una presentación actualizada y enlaces a recursos adicionales sobre saml.xml.org .

No estoy seguro de si algo de esto va a ayudar, aunque, como su caso de uso no parece ser lo SAML 2.0 está tratando de hacer. Puede añadir atributos y extensiones según sea necesario para las solicitudes y respuestas, pero no pueden ver muchos proveedores de identidad hacer nada con esos atributos y respuestas.