sso - spring security oauth2 jose

SSO con CAS o OAuth?

Question

Me pregunto si debería usar el protocolo CAS o OAuth + algún proveedor de autenticación para el inicio de sesión único.

Ejemplo de escenario:

1. Un usuario intenta acceder a un recurso protegido, pero no está autenticado.
2. La aplicación redirige al usuario al servidor SSO.
3. Si se autentica, el usuario obtiene un token del servidor SSO.
4. El SSO redirige a la aplicación original.
5. La aplicación original verifica el token contra el servidor SSO.
6. Si el token está bien, se permitirá el acceso y la aplicación conoce la identificación del usuario.
7. El usuario realiza un cierre de sesión y se desconecta de todas las aplicaciones conectadas al mismo tiempo (cierre de sesión único).

Por lo que yo entiendo, eso es exactamente para lo que se inventó CAS. Los clientes de CAS deben implementar el protocolo CAS para usar el servicio de autenticación. Ahora estoy pensando en usar CAS o OAuth en el sitio del cliente (consumidor). ¿Es OAuth un reemplazo para esa parte de CAS? ¿Se debe preferir OAuth como nuevo estándar de facto? ¿Existe un reemplazo fácil de usar (no Sun OpenSSO!) Para la parte de autenticación de CAS que admite diferentes métodos como nombre de usuario / contraseña, OpenID, certificados TLS ...?

Contexto:

• Las diferentes aplicaciones deben confiar en la autenticación del servidor SSO y deben usar algo parecido a una sesión.
• Las aplicaciones pueden ser aplicaciones web GUI o servicios (REST).
• El servidor de SSO debe proporcionar una identificación de usuario, que es necesaria para obtener más información sobre el usuario, como las funciones, el correo electrónico, etc., desde un almacén de información del usuario central.
• El cierre de sesión único debería ser posible.
• La mayoría de los clientes están escritos en Java o PHP.

Acabo de descubrir WRAP , que podría convertirse en el sucesor de OAuth. Es un nuevo protocolo especificado por Microsoft, Google y Yahoo.

Apéndice

Me enteré de que OAuth no fue diseñado para autenticación, incluso podría utilizarse para implementar SSO, pero solo junto con un servicio SSO como OpenID.

OpenID me parece ser el "nuevo CAS". CAS tiene algunas características de errores de OpenID (como el cierre de sesión único), pero no debería ser difícil agregar las partes faltantes en un escenario particular. Creo que OpenID tiene una amplia aceptación y es mejor integrar OpenID en aplicaciones o servidores de aplicaciones. Sé que CAS también admite OpenID, pero creo que CAS es prescindible de OpenID.

Answer 1

OpenID no es un "sucesor" o un "sustituto" de CAS, son diferentes, en la intención y en la implementación.

CAS centraliza la autenticación. Úselo si quiere que todas sus aplicaciones (probablemente internas) pidan a los usuarios que inicien sesión en un solo servidor (todas las aplicaciones están configuradas para apuntar a un solo servidor CAS).

OpenID descentraliza la autenticación. Úselo si desea que su aplicación acepte que los usuarios inicien sesión en el servicio de autenticación que deseen (el usuario proporciona la dirección del servidor OpenID; de hecho, el ''nombre de usuario'' es la URL del servidor).

Ninguno de los anteriores maneja la autorización (sin extensiones y / o personalización).

OAuth maneja la autorización, pero no es un sustituto de la tradicional ''tabla USER_ROLES'' (acceso de usuario). Maneja la autorización para terceros.

Por ejemplo, desea que su aplicación se integre con Twitter: un usuario podría permitir que tuitee automáticamente cuando actualice sus datos o publique contenido nuevo. Desea acceder a un servicio o recurso de un tercero en nombre de un usuario, sin obtener su contraseña (que obviamente no es segura para el usuario). La aplicación solicita acceso a Twitter, el usuario lo autoriza (a través de Twitter) y luego la aplicación puede tener acceso.

Entonces, OAuth no se trata de Single Sign-On (ni sustituto del protocolo CAS). No se trata de que usted controle a qué puede acceder el usuario. Se trata de dejar que el usuario controle cómo terceros pueden acceder a sus recursos. Dos casos de uso muy diferentes.

Para el contexto que describió, CAS es probablemente la opción correcta.

[actualizado]

Dicho esto, puede implementar SSO con OAuth, si considera la identidad del usuario como un recurso seguro. Esto es lo que ''Registrarse con GitHub'' y los "me gusta", básicamente. Probablemente no sea la intención original del protocolo, pero se puede hacer. Si controlas el servidor OAuth y restringes las aplicaciones para que solo se autentiquen con él, eso es SSO.

Sin embargo, no hay una forma estándar de forzar el cierre de sesión (CAS tiene esta característica).

Answer 2

Para mí, la diferencia real entre SSO y OAuth es la concesión, no la autenticación porque un servidor que implementa OAuth obviamente tiene autenticación (debe haber iniciado sesión en su google, openId o Facebook para que OAuth se realice con la aplicación cliente)

En SSO, un usuario avanzado / sysadmin le otorga al usuario final acceso a una aplicación de antemano en la "aplicación SSO". En OAuth, el usuario final otorga acceso a la aplicación a sus "datos" en la "aplicación OAuth".

No veo por qué el protocolo OAuth no se pudo usar como parte de un servidor SSO. Solo elimine la pantalla de concesión del flujo y permita que el servidor OAuth busque la concesión del respaldo db.

(mis 2 centavos)

Answer 3

Publicación anterior, pero esto podría ser útil:

CAS 3.5 admitirá oAuth como cliente y servidor. Ver: https://wiki.jasig.org/display/CASUM/OAuth

Answer 4

Tiendo a pensarlo de esta manera:

Utilice CAS si controla / posee el sistema de autenticación de usuario y necesita admitir un conjunto heterogéneo de servidores y aplicaciones que necesitan autenticación centralizada.

Utilice OAuth si desea admitir la autenticación de usuarios de sistemas que no posee / admite (es decir, Google, Facebook, etc.).

Answer 5

OpenID es un protocolo de autenticación, OAuth y OAuth WRAP son protocolos de autorización. Se pueden combinar con la extensión híbrida OpenID .

Preferiría que las personas construyan sobre estándares que tengan un gran impulso (más soporte disponible, más fácil involucrar a terceros), incluso si no son exactamente los adecuados para la aplicación en cuestión. En este caso, OAuth tiene el impulso, no CAS. Debería poder hacer todo o al menos casi todo lo que necesita hacer con OAuth. En algún momento posterior en el futuro, OAuth WRAP debería simplificar aún más las cosas (hace algunas compensaciones valiosas mediante el uso de un token de portador y bajando el cifrado a la capa de protocolo), pero aún está en pañales, y mientras tanto, OAuth probablemente hará bien el trabajo.

En última instancia, si elige usar OpenID y OAuth, hay más bibliotecas para más idiomas disponibles para usted y para cualquier otra persona que necesite integrarse con el sistema. También tienes muchos más ojos mirando los protocolos, asegurándote de que realmente sean tan seguros como deberían.