SSO con CAS u OAuth?

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

Escenario de ejemplo:

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 cierra la sesión de todas las aplicaciones conectadas al mismo tiempo (cierre de sesión único).

Hasta donde 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 pregunto acerca de usar CAS u OAuth en el sitio del cliente (consumidor). ¿Es OAuth un reemplazo para esa parte de CAS? ¿Debería preferirse OAuth como un 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 deberían basarse en la autenticación del servidor SSO y deberían usar algo parecido a una sesión.
• Las aplicaciones pueden ser aplicaciones web GUI o servicios (REST).
• El servidor SSO debe proporcionar una identificación de usuario, que es necesaria para obtener más información sobre el usuario, como roles, correo electrónico, etc., desde un almacén central de información del usuario.
• 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

Aprendí que OAuth no fue diseñado para la autenticación, incluso podría usarse para implementar SSO, sino 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 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 es compatible con OpenID, pero creo que CAS es prescindible con OpenID.

OpenID no es un 'sucesor' o 'sustituto' de CAS, son diferentes, en intención e implementación.

CAS centraliza la autenticación. Úselo si desea que todas sus aplicaciones (probablemente internas) soliciten a los usuarios que inicien sesión en un único servidor (todas las aplicaciones están configuradas para apuntar a un único 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 permitir que tuitee automáticamente cuando actualice sus datos o publique contenido nuevo. 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 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 un sustituto del protocolo CAS). No se trata de que el control de lo que el usuario puede tener acceso. 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 básicamente hace 'Registrarse con GitHub' y los Me gusta. Probablemente no sea la intención original del protocolo, pero se puede hacer. Si controla el servidor OAuth y restringe 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).

Tiendo a pensar de esta manera:

Use 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.

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

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 .

Prefiero ver a las personas que se basan en estándares que tienen mucho impulso (más soporte disponible, más fácil involucrar a terceros), incluso si no se ajustan exactamente a 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 al usar un token de portador y empujar el cifrado a la capa de protocolo), pero aún 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 necesite integrarse con el sistema. También tiene muchos más ojos mirando los protocolos, asegurándose de que realmente sean tan seguros como se supone que deberían ser.

Para mí, la verdadera diferencia entre SSO y OAuth es otorgar, no autenticación, porque un servidor que implementa OAuth obviamente tiene autenticación (debe iniciar sesión en su google, openId o facebook para que OAuth suceda con la aplicación cliente)

En SSO, un usuario avanzado / administrador del sistema otorga al usuario final acceso de antemano a una aplicación 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 puede usar como parte de un servidor SSO. Simplemente saque la pantalla de concesión del flujo y deje que el servidor de OAuth busque la concesión desde el db de respaldo.

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