¿Diferencia entre Shibboleth y CAS?
(4)
CAS es un proveedor de autenticación que se utiliza mejor para el inicio de sesión único en muchos servicios / aplicaciones con un inicio de sesión. Sin embargo, CAS tiene su limitación de liberar atributos adicionales al servicio. Ahí es donde Shib tiene su mayor ventaja, ya que brinda a los administradores la capacidad de configurar un conjunto único de atributos para diferentes servicios.
Mr.BMW, ¿cómo integró CAS y Shib? Parece que hay varias maneras de hacerlo. CAS es nuestro principal proveedor de autenticación y tenemos grandes inversiones allí. Recientemente instalamos Shib y nos preguntamos cuál es la mejor manera de integrar ambos. Cualquier idea sería apreciada.
Por favor, explica cuáles son las diferencias entre Shibboleth y CAS?
El primero (Shibboleth) es un servidor y el segundo (CAS) un protocolo. Tiene más sentido comparar el Servicio de autenticación central (CAS) con el lenguaje de marcado de aserción de seguridad (SAML) , que es el protocolo utilizado por Shibboleth. Ambos se pueden utilizar para implementar un inicio de sesión único centralizado (SSO).
Mucha gente usa CAS y Shibboleth juntos. Observe a CAS como un motor de autenticación (del usuario normalmente almacenado en LDAP) y de autorización (del servicio web solicitante). Shibboleth, que en realidad es dos componentes, el SP (proveedor de servicios) que solicita atributos y el IDP (proveedor de identidades) que difunde atributos, es un motor de federación que hace que los atributos (posiblemente también almacenados en el mismo LDAP) estén disponibles una vez que el usuario tenga Ha sido autenticado y el servicio autorizado.
Si bien ambos pueden usarse para proporcionar SSO, CAS es mejor para administrar el estado de la sesión (y la posible persistencia), mientras que Shibboleth es mejor para analizar y presentar los atributos solicitados por los proveedores de servicios. He implementado CAS y Shibboleth y encontré que la documentación de los wikis de Shibboleth y Jasig(CAS) es de gran utilidad.
Shibboleth utiliza el lenguaje de marcado de aserción de seguridad (SAML) para intercambiar aserciones entre un proveedor de identidad (IdP) y un proveedor de servicios (SP, generalmente la aplicación web que está protegida).
CAS, por otro lado, utiliza un protocolo propietario para emitir "tickets" (en lugar de "aserciones") a un usuario cuando intenta acceder a un recurso seguro. Fundamentalmente, es un proceso extremadamente similar al mecanismo de autenticación Shibboleth / SAML, simplemente utiliza el protocolo CAS en lugar de SAML.
Si usa una versión reciente de CAS (5+, creo) o una versión reciente de Shibboleth IdP (3.2+, creo) podrá usar cualquiera de las dos para proporcionar integraciones de proveedores de servicios con el protocolo CAS o SAML, aunque hay ciertas limitaciones (por ejemplo, Shib IdP admite el protocolo CAS v2 pero no v3).
En la práctica, en estos días, es probable que se salga con la implementación de uno u otro como el IdP. Como proveedor de servicios (lo que CAS denomina "cliente"), debe admitirlos por separado, es decir, Shib SP o phpCAS.