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 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 recibe un token del servidor SSO.
4. El SSO redirige a la aplicación original.
5. La aplicación original comprueba el token contra el servidor SSO.
6. Si el token está bien, se permitirá el acceso y la aplicación conocerá 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 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:

• diferentes aplicaciones deben confiar en la autenticación del servidor SSO y deben usar algo similar a la 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 las funciones de usuario, el correo electrónico, etc. de un almacén de información de usuario central.
• Solo se debe cerrar la sesión.
• La mayoría de los clientes están escritos en Java o PHP.

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

Adición

He aprendido que OAuth no fue diseñado para la autenticación incluso podría ser utilizado para implementar SSO, pero sólo junto con un servicio de 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 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).

Ninguna de las autorizaciones de manejo anteriores (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 permitirle twittear 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.

Por lo tanto, OAuth no se trata de Single Sign-On (ni sustituto del protocolo CAS). No se trata de controlando a lo que el usuario puede acceder. Se trata de dejar que el usuario controle cómo sus recursos pueden ser accedidos por terceros. Dos casos de uso muy diferentes.

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

[actualizada]

Dicho esto, se puede implementar SSO con OAuth, si se tiene en cuenta 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, ninguna forma estándar de forzar el cierre de sesión (CAS tiene esta característica).

Answer 2

OpenID es un protocolo de autenticación, OAuth y OAuth WRAP son protocolos de autorización. Se pueden combinar con el hybrid OpenID extension.

Preferiría ver a las personas construyendo sobre los estándares que tienen un gran impulso (más soporte disponible, más fácil involucrar a terceros), incluso si no son un ajuste exacto 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.

Answer 3

tiendo a pensar de esta manera:

Uso CAS si controlas/propietario del sistema de autenticación de usuario y la necesidad de apoyar un conjunto heterogéneo de servidores y aplicaciones que requieren autenticación centralizada.

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

Answer 4

Viejo poste, pero esto podría ser útil:

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

Answer 5

Para mí, la diferencia real entre SSO y OAuth es donación, no autenticación porque un servidor que implementa OAuth obviamente tiene autenticación (tienes que estar conectado a tu Google, OpenID o facebook para OAuth sucederá con la aplicación cliente)

En SSO, un usuario/sysadmin le otorga acceso previo al usuario final 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 w 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)