java - funciona - SSO simple-usando autenticación personalizada-CAS o algún servidor Oauth o openid?

oauth2 java

Question

Me gustaría saber más sobre las diferentes formas de resolver el inicio de sesión único y sus ventajas y desventajas. ¿Ha trabajado con una solución en particular, dígame qué tiene de bueno y dígame cuáles son las limitaciones o las partes subóptimas?

Abajo están los detalles de lo que me gustaría saber, o no entender.

SSO es un tema enorme, como se indica en la wikipedia . Cuanto más aprendo, más preguntas tengo.

En primer lugar, no entiendo la necesidad de verificaciones de token de CAS , ¿para qué sirve?

¿Es más seguro? Supongo que es vulnerable al ataque del hombre en el medio como cualquier otro. ¿Los clientes también deben usar ssl?

Seamos realistas, esta es nuestra necesidad: reconocer automáticamente / iniciar sesión si ya iniciamos sesión en una de nuestras aplicaciones.

• my-php-app.com
• my-java-app.com
• my-ruby-app.com

(Tenemos muchas aplicaciones web, escritas en diferentes idiomas).

Queremos (mantener) nuestras propias reglas de autenticación y la tienda de usuarios, pero podríamos agregar algún proveedor Oauth2, como facebook-connect. Lo queremos simple para los usuarios y simple para los desarrolladores que lo usan.

¿Qué harías?

• CAS?
• Openid? ¿Puedo tener autenticación centralizada con él?
• ¿Otro? ¿O un servidor con OAuth?

En el lado del cliente, ¿usaría un iframe, como lightbox, para mostrar la página redirigida? ¿Por qué por qué no?

Otra pregunta relacionada con el SSO: Saml a menudo (¿de forma incorrecta?) Se mezcla con las discusiones del SSO;

una implementación saml no proporcionaría sso (inicio de sesión automático) al señalar el navegador a www.yetanother-myapp.com?

Algunas preguntas de SO relacionadas que he estudiado:

• SSO con CAS o OAuth? - Su descripción de necesidad no es lo que quiero, él describe CAS ...
• ¿OpenID como opción de inicio de sesión único? - Bueno, no estoy seguro de lo que aprendí de ello.

Gracias por educarme!

Answer 1

Esto se basa en mi experiencia: SSO (Inicio de sesión único) está relacionado con dos escenarios: - i) Te conozco muy bien (dos partes involucradas) ii) Hola amigo, te presento a mi amigo (tres partes involucradas)

Entonces, por supuesto, el segundo escenario necesita un mecanismo de redireccionamiento / reenvío porque, por lo general, un tercero es solo un servicio centralizado de autenticación / autorización.

Ahora, en cuanto a la implementación, SSO requiere dos áreas para ser evaluadas:

a) cómo diferentes partes / sistemas (ya sean internos / externos a la organización en cuestión) gestionan las credenciales de los usuarios. Esto se llama gestión de identidad.

b) ¿Cómo debería fluir la información de SSO entre las partes? De forma segura en la mayor parte del escenario.

Creo que la gestión de la identidad es más importante que determinar con seguridad cómo se pasa la información porque, en la última parte, hay muchas técnicas de cifrado / descifrado disponibles. La gestión de la indetidad es indistintamente diferente en un conjunto de sistemas habilitados para SSO.

Ahora la administración de la identidad se puede implementar mediante un simple ID de usuario (si está disponible en todos los sistemas participantes), o mediante contenido XML desarrollado internamente, carga útil SAML o token de un tercero. Creo que token es solo un término genérico que se refiere al contenedor que contiene las credenciales de los usuarios de manera segura y también a información sobre algunos procedimientos de seguridad realizados.

@Ole, habiendo dicho todo lo anterior sobre los conceptos básicos de SSO (desde mi punto de vista), creo que debería concentrarse más en cómo se identifican los usuarios y sus roles en múltiples sistemas, es decir, en su caso: - su tienda de usuarios, proveedor externo abierto2; Así que pon más pensamiento en la gestión de identidad.

Una solución podría ser (dependiendo de su presupuesto y tiempo), su empresa puede esforzarse en crear una interfaz de autenticación centralizada interna en forma de tecnologías de integración estándar para, por ejemplo, servicios web y detrás de esas API, puede tener cualquier implementación: su propio proveedor o Tercero oAuth o mixto de ambos. Puede implementar una capa de motor entre su API y la capa de proveedor, que toma las decisiones. Por ejemplo, el motor puede tener un dominio de aplicación y la correspondiente asignación del proveedor de autenticación. De esta manera tendrá una interfaz de autenticación uniforme para todos sus clientes.

Cliente -> API centralizada interna -> Motor -> Proveedores de autenticación Permítame darle un ejemplo: - i) puede tener un servicio web expuesto, cuyo nombre puede ser singleSigonService. La carga útil XML puede ser como:

<SingleSignOnReqType> <sourceID>XYZ</sourceID> <source-domain>my-java-app.com</source-domain> <user-credentials>...</<user-credentials>
<security-credentials>...</<security-credentials> </SingleSignOnReqType>

ii) Un cliente del servicio web haría una llamada SSO a la capa del motor centralizado (implementado en cualquier tecnología), que puede realizar validaciones y tareas de contabilidad y puede basarse en el dominio de origen (por ejemplo, my-java-app.com) en XML entrante delegaría la solicitud a un proveedor de Oauth2 como facebook-connect. Por lo tanto, su motor, el que toma las decisiones, administrará las reglas de autenticación como mencionó en sus requisitos.

Básicamente, todas las aplicaciones para el consumidor tendrán una interfaz basada en un servicio web unificado para su solución SSO. Esto es lo que me refiero a la API centralizada interna.

Answer 2

Oauth está diseñado para autenticar la aplicación para que actúen en nombre de un usuario. Por ejemplo, un cliente de Twitter puede publicar tweets con la cuenta de un usuario. Se puede usar para el inicio de sesión único como muestra Facebook, pero esto requiere un poco de trabajo adicional.

Comparando CAS y OpenID

CAS es un sistema centralizado con una autoridad de cuenta. OpenID es un sistema distribuido donde básicamente cualquier persona puede configurar un proveedor de identidad. Por supuesto, puede limitar a su consumidor para que solo acepte su propio proveedor de identidad.

OpenID tiene dos estándares (incompatibles) para proporcionar atributos adicionales sobre la cuenta, que son compatibles más o menos por las bibliotecas comunes. En la configuración estándar, CAS solo proporciona el nombre de usuario. Mientras que CAS admite el intercambio de atributos en teoría, en este momento solo el cliente PHP lo admite .

Tanto OpenID como CAS pueden hacer inicio de sesión automático . Si el usuario ya ha iniciado sesión, el navegador será redirigido a su aplicación inmediatamente. Sin embargo, en una configuración sencilla, el proveedor de identidad mostrará una página de inicio de sesión, si el usuario no ha iniciado sesión. Por lo tanto, si desea permitir el acceso anónimo a su lado, esto requerirá que las personas hagan clic en un enlace de inicio de sesión dedicado.

Por suerte, tanto OpenID como CAS permiten un intento de inicio de sesión transparente . En este modo, el formulario de inicio de sesión no se muestra. El navegador se redirige inmediatamente con o sin información de autenticación. En otras palabras: puede redirigir a todos los usuarios nuevos (sin una sesión) al proveedor de identidad tan pronto como visiten su sitio. Hay un bonito diagrama que explica esto en detalle. CAS lo llama "modo de puerta de enlace" y se logra agregando gateway = true a la URL de inicio de sesión. En OpenID se llama "modo inmediato" y el parámetro de URL es openid.mode = checkid_immediate

CAS admite el inicio de sesión único . OpenID no lo hace.

Mi experiencia personal es que CAS es muy fácil de configurar y muy confiable con bibliotecas de alta calidad para todos los lenguajes de programación comunes. OpenID tiene muchas pequeñas incompatibilidades, ya que es un sistema mucho más complejo. OpenID, sin embargo, permite el uso de cuentas de Google.

Respuestas

En primer lugar, no entiendo la necesidad de verificaciones de token de CAS, ¿para qué sirve?

Tanto OpenID como CAS requieren que permita que el proveedor de identificación verifique el token proporcionado. De lo contrario, un atacante puede crear su propio token o usar un token creado por un usuario antes de cerrar la sesión.

¿Los clientes también deben usar ssl?

Sí.

En el lado del cliente, ¿usaría un iframe, como lightbox, para mostrar la página redirigida? ¿Por qué por qué no?

Una redirección a pantalla completa es lo más simple que se puede hacer. Yo empezaría con eso para que funcione. Muchas aplicaciones requieren una recarga de la página actual después de iniciar sesión de todos modos para mostrar las partes que solo son visibles para los usuarios registrados.

Un Iframe tiene el problema de que necesita deshacerse de él una vez que se completó el inicio de sesión. Para CAS hay un tutorial sobre cómo incrustar directamente el formulario de inicio de sesión de CAS en el código HTML de la aplicación. Otra alternativa es mostrar una ventana emergente como lo hace Facebook Connect.

Answer 3

Puedo responder algunas de las preguntas sobre CAS como las he usado antes. No tengo experiencia con OAuth y por lo tanto no comentaré sobre ello.

En primer lugar, no entiendo la necesidad de verificaciones de token de CAS, ¿para qué sirve?

CAS se utiliza para fines de SSO. Se usa cuando tiene varias aplicaciones (aplicaciones de escritorio / aplicaciones web en diferentes TLD) que desean realizar la autenticación desde una única fuente.

¿Es más seguro? Observo que está basado en redireccionamiento y, por lo tanto, está sujeto al ataque de intermediario, al igual que lo haría un servidor de autenticación "personalizado" sin el paso adicional de verificación de token. ¿Es algo a la seguridad en CAS que me estoy perdiendo?

Los servidores de autenticación usan SSL para prevenir los ataques MitM. Pero no veo cómo este es un problema específico con SSO / CAS, ya que tendría el mismo problema incluso si la aplicación está realizando su propia autenticación. Tal vez nos pueda decir qué tipo de ataques MitM le preocupan con la configuración de CAS

¿Es el propósito de los tokens proporcionar un cierre de sesión único y / o un tiempo de espera? (No lo queremos, nuestros usuarios nos odiarían). He estado investigando CAS, ya que hay algunas implementaciones impresionantes de Ruby, pero no estoy seguro de que sea lo que necesitamos.

Los tokens son solo una forma para que la aplicación lo autentique sin tener su contraseña. Son un token de vida útil corta / único que está asociado a sus credenciales de usuario. La aplicación proporciona el token al servidor CAS y la respuesta del servidor CAS con una credencial, si hay alguna asociada con ella. El inicio de sesión único y el tiempo de espera se pueden implementar, pero no están directamente vinculados a tener los tokens.

Espero que esto quede claro. Traté de hacer una explicación de alto nivel. No dude en preguntar por detalles si hay alguna parte que no esté clara o si desea más detalles.

EDITAR: Encontré una mejor explicación simple de cómo funciona CAS en http://www.jasig.org/cas/proxy-authentication (el resto de la página habla sobre la autenticación por proxy. Lo que es más complejo, pero el primer párrafo es El caso simple del que estamos hablando aquí.

Voy a mi instancia del Portal. Me redirige a CAS para iniciar sesión. CAS detecta mi cookie segura y realiza el inicio de sesión único, por lo que no tengo que volver a dar mi nombre de usuario y contraseña. CAS me redirige de nuevo al portal. El portal valida el ticket, me registra en el Portal. Veo mi diseño predeterminado lleno de algunos canales geniales que me dicen que hace mucho frío afuera y qué hay en las noticias.

Tenga en cuenta que el portal no recibió mi contraseña.