security - onelogin - Cómo convertirse en un proveedor de servicios SAML

saml security token

Question

Buenos días a todos,

Mi empresa actualmente desarrolla una aplicación web Java. Algunos de nuestros clientes tienen servidores SAML internos (¿proveedores de identidad?) Y han solicitado que nos integremos con ellos. Recientemente lo he estado leyendo y jugando con OpenAM. Después de aproximadamente 3 días de esto, tengo una comprensión general de esto, pero todavía hay algunas lagunas en mi conocimiento. Mi esperanza es que alguien pueda aclararme esto.

Así que así es como me imagino el flujo de trabajo de un usuario que inicia sesión.

Definamos el servidor SAML de nuestros clientes como https://their.samlserver.com . Entonces, un usuario accede a nuestra aplicación web para obtener un recurso que está protegido. Digamos que la URL es http://my.app.com/something .

Entonces, si estoy en lo cierto, my.app.com es lo que SAML define como proveedor de servicios . Nuestra aplicación se da cuenta de que este usuario debe iniciar sesión. A continuación, presentamos una página como esta para el usuario ...

<script>JQuery Script to auto submit this form on ready</script>
<form method="post" action="https://their.samlserver.com/Post/Servlet">
    <input type="hidden" name="SAMLRequest" value="someBase64Data" />
    <input type="submit" value="Submit" />
</form>

Y que someBase64Data debería ser una versión codificada en base64 de esto ...

<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_1"
  Version="2.0"
  IssueInstant="2004-12-05T09:21:59Z"
  AssertionConsumerServiceIndex="0">
 <saml:Issuer>http://my.app.com</saml:Issuer>
 <samlp:NameIDPolicy
   AllowCreate="true"
   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>

Entonces mi primer par de preguntas.

¿Cuál es el valor ID que se supone que es?

¿Y por qué puedo declararme como un Emisor ?

¿El proveedor de identidad sabe de mí? Tal vez este es ese Círculo de confianza

He estado viendo en OpenAM . Y si sabe de mí, ¿cómo sabe de mí y qué necesita saber?

Entonces, después de que el usuario es reenviado a esa página, se los lleva a una página provista por el IDP https://their.samlserver.com . Se autentican en esa página y el IDP hace magia para validar la autenticación y buscar al usuario. Después de que la autenticación es exitosa, el IDP devuelve un <samlp:Response> definido here .

Algunas preguntas más

Primero, ¿cómo regresa <samlp:Response> a mi aplicación web para que pueda verificarlo?

¿Y qué debería estar buscando en esa respuesta para validar que fue exitoso? ¿Cómo se ve una falla?

Actualmente usamos la dirección de correo electrónico (LDAP) para identificar a los usuarios, por lo que probablemente tomemos esa respuesta de la respuesta y la usemos de la misma manera que lo hacemos ahora. ¿Algo más de lo que debería ser consciente en esa respuesta?

Ahora que hemos verificado la validez de esa respuesta, podemos otorgarle al usuario una sesión como la que tenemos actualmente. Pero cuando quieren desconectarse, ¿hay un flujo de trabajo para eso? ¿Tengo que notificar al IDP que el usuario se fue?

Y, por último, hay un par de temas que han surgido en mi lectura y no estoy seguro de cómo encajan en este flujo de trabajo. Son Círculo de confianza , Fichas y Artefactos .

Gracias por ayudar a todos. Encontré mucha información en los últimos días, y es posible que pueda reconstruirlos después de jugar un poco más. Pero aún no he encontrado un artículo de flujo de trabajo directo "Here''s the Post". Tal vez sea porque estoy equivocado sobre cómo funciona esto. Tal vez sea porque esto no es tan popular todavía. Pero realmente quería asegurarme de obtener el flujo de trabajo para no perder un paso crucial en algo tan importante como la autenticación de usuarios.

Answer 1

En respuesta a sus preguntas específicas:

1.) ¿Cuál es el valor de "ID" que se supone que es?

• Esto debería ser un identificador único para la solicitud de SAML. La especificación SAML 2.0 indica que realmente es específica de la implementación cómo se hace, pero hace las siguientes recomendaciones:

El mecanismo mediante el cual una entidad del sistema SAML asegura que el identificador sea único se deja a la implementación. En el caso de que se emplee una técnica aleatoria o pseudoaleatoria, la probabilidad de que dos identificadores elegidos al azar sean idénticos DEBE ser menor o igual a 2 ^ -128 y DEBERÍA ser menor o igual a 2 ^ -160 de longitud. Este requisito PUEDE cumplirse codificando un valor elegido aleatoriamente entre 128 y 160 bits de longitud.

2.) ¿Cómo sabe el IdP sobre usted?

• Su SP debe estar registrado con el IdP. Para lograr esto, la especificación SAML define un formato para "Metadatos SAML" que le indica al IdP dónde están sus receptores SAML, cuáles son sus certificados, los atributos que intercambia, etc. OpenAM probablemente dicta algunos requisitos mínimos para configurar un SP de confianza. Esto varía en cada producto.

3.) ¿A dónde va la respuesta y qué revisar?

• La respuesta irá a su URL de servicio al consumidor de aserción generalmente definida en los metadatos de SAML que intercambia desde su SP con el IdP para la configuración inicial. Cuando recibe una respuesta de SAML, necesita verificar muchas cosas, pero lo más importante es que el código de estado de SAML debe ser "exitoso", las ID de InResponseTo deben coincidir con las enviadas de la solicitud y debe validar la firma digital en la Afirmación. Para eso, tendrá que confiar en el certificado de verificación pública del IdP, y probablemente también quiera hacer una verificación de revocación.

4.) ¿Qué pasa con el cierre de sesión?

• SAML 2.0 también define un perfil para Single LogOut (SLO). Esto no solo lo desconectará del SP, sino también del IdP y, potencialmente, de cualquier otro SP con el que haya establecido una sesión. Tiene un flujo de solicitud / respuesta similar a Single Sign-On (SSO), y por lo tanto cosas similares a configurar y verificar (códigos de estado, firmas, etc.).

En resumen, esto puede ser bastante complejo de implementar desde cero. Lo mejor es usar bibliotecas y / o productos probados y verdaderos, como sugiere Ian. Empresas como la suya han invertido cientos de horas de tiempo de desarrollador para implementar de acuerdo con las especificaciones y probar la interoperabilidad con otros proveedores.

Answer 2

Si solo intenta configurar una sola aplicación Java como proveedor de servicios, debería considerar utilizar Fedlet desde Oracle (como un programa independiente) o desde ForgeRock (incluido con OpenAM). ForgeRock Fedlet tiene algunos problemas para interactuar con Shibboleth 2.2.1 como proveedor de identidad, pero me parece que es algo más simple de configurar y más informativo.

Cada uno tiene instrucciones explícitas contenidas en el archivo README para ayudarlo a implementar. Una vez que Fedlet se configura y se comunica con el IDP, la página de éxito le muestra todo el código que necesita para integrar el SSO federado en su aplicación. Hace el trabajo de fondo de enviar y recibir solicitudes y respuestas automáticas.

La respuesta de Scott responde bastante bien a las preguntas que tenía, pero creo que intentar escribir un código por su cuenta que genere el SAML es reinventar la rueda. El Fedlet fue diseñado teniendo en cuenta precisamente este caso de uso.