SSO con CAS o OAuth?

Question

SSO con CAS o OAuth?

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

Escenario de ejemplo:

Un Usuario intenta acceder a un recurso protegido, pero no se autentica.
La aplicación redirige al usuario al servidor SSO.
Si está autenticado, el usuario obtiene un token del servidor SSO.
El SSO redirige a la aplicación original.
La solicitud original comprueba la token contra el servidor SSO.
Si el token está bien, se permitirá el acceso y la aplicación conoce el id de usuario.
El usuario realiza un cierre de sesión y se cierra la sesión 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 CAS tienen que implementar el protocolo CAS para usar el servicio de autenticación. Ahora me estoy preguntando acerca de usar CAS o OAuth en el sitio del cliente (consumidor). Ser OAuth un reemplazo para esa parte de CAS? ¿Debería preferirse OAuth como nuevo estándar de facto? ¿Hay un fácil de usar (no Sun OpenSSO!) reemplazo 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 similar a una sesión.
Las aplicaciones pueden ser aplicaciones web GUI o (REST) serivces.
El servidor SSO debe proporcionar un id de usuario, que es necesario para obtener más información sobre el usuario, como roles, correo electrónico, etc., desde un almacén central de información de usuario.
Debería ser posible el cierre de sesión único.
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.

Adición

He aprendí que OAuth no estaba diseñado para la autenticación, incluso podría usarse para implementar SSO, pero solo junto con un servicio SSO como OpenID.

OpenID me parece ser el "nuevo CAS". CAS tiene algunas características que OpenID pierde (como el cierre de sesión único), pero no debería ser difícil agregar las partes que faltan en un escenario en 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 es compatible con OpenID, pero piensa que CAS es prescindible con OpenID.

168

security oauth single-sign-on cas

Author: deamon, 2010-01-09

Source

5 answers

Tiendo a pensar de esta manera:

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

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

44

Author: Lance Weber,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-01-13 18:07:37

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

Preferiría ver a la gente construyendo sobre estándares que tienen mucho 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. Usted debe ser capaz de hacer todo o al menos casi todo lo que necesitas hacer con OAuth. En algún momento posterior en el futuro, OAuth WRAP debería simplificar aún más las cosas (hace algunas concesiones valiosas al usar un token portador y empujar el cifrado a la capa de protocolo), pero todavía está en su infancia, y mientras tanto, OAuth probablemente hará el trabajo bien.

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 lo necesite integración con el sistema. También tienes muchos más ojos mirando los protocolos, asegurándote de que realmente son tan seguros como se supone que deben ser.

13

Author: Bob Aman,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-03-03 16:18:11

Antiguo post, pero esto podría ser útil:

CAS 3.5 soportará OAuth como Cliente y Servidor. Véase: https://wiki.jasig.org/display/CASUM/OAuth

6

Author: Bertl,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-04-19 11:08:26

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

En SSO, un usuario avanzado / administrador de sistemas 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é OAuth el protocolo no se pudo usar como parte de un servidor SSO. Simplemente saque la pantalla grant del flujo y deje que el servidor OAuth busque la grant de la base de datos de respaldo.

4

Author: redben,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-10-02 08:51:27

score 220 · Accepted Answer

OpenID no es un 'sucesor' o 'sustituto' para las CA, son diferentes, en la intención y en la implementación.

CAS centraliza la autenticación. Úselo si desea 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 el inicio de sesión de los usuarios 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 handle 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). Gestiona la autorización de terceros.

Por ejemplo, desea que su aplicación se integre con Twitter: un usuario podría permitirle twittear automáticamente cuando actualice su datos o publicar nuevo contenido. Desea acceder a algún servicio o recurso de terceros en nombre de un usuario, sin obtener su contraseña (que obviamente no es segura para el usuario). La aplicación pide 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 Inicio de sesión único (ni un sustituto del protocolo CAS). No se trata de que controle a qué puede acceder el usuario. Se trata de dejar que el usuario para controlar cómo sus recursos pueden ser accedidos por terceros. Dos casos de uso muy diferentes.

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

[actualizado]

Dicho esto, puede implementar SSO con OAuth, si considera la identidad del usuario como un recurso seguro. Esto es lo que' Regístrate con GitHub ' y otros hacen, básicamente. Probablemente no sea la intención original del protocolo, pero se puede hacer. Si usted controla el OAuth server, y restringir 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).