Solución:
Su aplicación debe actuar como SAML SP, ya sea directamente (desde su código) o indirectamente (por ejemplo, a través del soporte SAML SP en proxy inverso, servidor de aplicaciones, …).
Para opciones directas (que requieren más modificaciones en su aplicación) puede:
- codifique el SP de SAML usted mismo (lo más probable es que con OpenSAML, puede encontrar ejemplos en las fuentes de productos existentes)
- use un producto listo para usar para integrarlo en su aplicación, como Spring SAML o OpenAM Fedlet
Para opciones indirectas (que requieren menos modificaciones en su aplicación) puede:
- use los complementos Shibboleth SAML SP en su proxy inverso Apache (si usa uno)
- Implemente SAML SP como otra aplicación en su contenedor (por ejemplo, Spring SAML u OpenAM) y haga que se comunique con su aplicación, para que SAML SP realice la autenticación con ADFS y se lo comunique a su aplicación, por ejemplo, a través de una cookie compartida o un token personalizado.
Puede encontrar más detalles y consideraciones de comparación en este hilo.
ADFS 3 debería ser compatible con el servidor de autorización OAuth y bien podría ser una forma más fácil de integrar, consulte aquí y aquí. La implementación de la autenticación mediante OAuth es generalmente mucho más fácil que SAML, sin desventajas relevantes.
Los autenticadores de resina que proporciona Caucho no ayudarán con la federación. En su lugar, debe agregar un ServletFilter que busque usuarios no autenticados. Cuando encuentre uno, debe dirigirlo a una página de inicio de sesión. Al respecto, debe preguntarle al usuario si desea iniciar sesión directamente en su sitio o federarse en otra organización. (Esto se puede hacer mostrando un formulario de nombre de usuario / contraseña + logotipos de terceros confiables). En el caso anterior, el inicio de sesión directo, use el Autenticador de resina para verificar su repositorio de usuario local o como lo esté haciendo ahora. Para el caso federado, use SAML.
La federación comenzaría enviando una solicitud de autenticación al socio de confianza (el servidor ADFS). Este es un pequeño documento XML empaquetado en un formulario que necesitará que se cambien algunas cosas por solicitud (por ejemplo, el momento de la creación). Esto se puede hacer con String.format, nada complicado. Envíe esta solicitud de autenticación al servidor SAML (es decir, ADFS) en la organización que seleccionó el usuario. Ellos iniciarán sesión y enviarán la respuesta de autenticación a algún “Servicio al consumidor de afirmaciones” que debe crear.
Un ACS es solo un punto final que recibe la respuesta de autenticación SAML. Debe ser un extremo no autenticado que analizará y validará la respuesta de ADFS. Utilice OpenSAML para hacer esto. Hay algunas cosas que debe hacer para asegurarse de que sea válido. Por ejemplo, debe verificar la firma digital de la aserción. También debe verificar la hora de emisión, que no es en el futuro. Verifique que la afirmación sea para usted marcando el Destino en los datos de confirmación, la audiencia y el destinatario. Etcétera etcétera.
Si esto va más allá de lo que le gustaría codificar, consulte un servidor SAML comercial o de código abierto. Debe funcionar como un SP y debe ejecutarse en Resin para simplificar las cosas. Un candidato que es malo y delgado es Asimba. Puede implementar esto en Resin, y se ocupará tanto de la solicitud como de la respuesta.
Una nota sobre OAuth
Lo que está contemplando aquí es la federación (o inicio de sesión único web). OAuth no es adecuado para la federación. Es un protocolo diseñado para hacer autorización delegada. OpenID Foundation ha ampliado OAuth 2 para admitir la federación en el perfil OpenID Connect de OAuth. ADFS no admite este protocolo de federación y está limitado a WS-Federation y SAML. Por lo tanto, no debería buscar en OAuth si sus socios utilizarán ADFS.