Inicio de sesión único para una aplicación web

Question

He estado tratando de comprender cómo se resuelve este problema desde hace más de un mes. Realmente necesito llegar a un enfoque general que funcione. Tengo una teoría, pero no estoy seguro de que sea el enfoque más fácil (o correcto) y no he podido encontrar ninguna información que respalde mis ideas.

Este es el escenario:

1) Tiene una aplicación compleja red que ofrece contenido seguro sobre una base de suscripción.

2) Los usuarios deben iniciar sesión en su aplicación con nombre de usuario y contraseña.

3) Vende a grandes corporaciones, que ya tienen una tecnología de autenticación corporativa (por ejemplo, Active Directory).

4) Desea integrarse con el mecanismo de autenticación corporativo para permitir a sus usuarios iniciar sesión en su aplicación web sin tener que ingresar su nombre de usuario y contraseña.

Ahora, cualquier solución que llegar a tendrá que proporcionar un mecanismo para:

• añadir nuevos usuarios
• eliminar usuarios
• cambiar la información del usuario
• permitiendo a los usuarios inician sesión en

Idealmente, todo esto sucedería "automágicamente" cuando el cliente corporativo hiciera los cambios correspondientes en su propia autenticación.

Ahora, tengo la teoría de que la manera de hacerlo (al menos para Active Directory) sería escribir una aplicación del lado del cliente que se integre con el Active Directory del cliente para rastrear los cambios específicos y luego comunicar esos cambios en mi aplicación web. Creo que si esta comunicación se realizara a través de los servicios web ofrecidos por mi aplicación web, entonces mantendría un nivel de seguridad inquebrantable, lo que obviamente sería un requisito para estos clientes corporativos.

He encontrado información sobre un producto de Microsoft llamado Servicio de federación de Active Directory (ADFS) que puede o no ser el enfoque correcto para mí. Parece ser un poco voluminoso y tiene algunos requisitos que pueden no funcionar para todos los clientes.

Para otros escenarios de ID existentes (como Atenas y Shibboleth), no creo que sea necesaria una aplicación de cliente. Probablemente solo sea cuestión de vincularse a los servicios de identificación existentes.

Agradecería cualquier consejo que alguien tenga sobre algo que he mencionado aquí. En particular, si puede decirme si mi teoría es correcta acerca de proporcionar una aplicación del lado del cliente que se comunique con los servicios web del lado del servidor, o si voy en la dirección equivocada. Además, si pudiera señalarme en cualquier sitio web o artículo que explique cómo hacerlo, realmente lo agradecería. Mi investigación no ha aparecido mucho hasta ahora.

Finalmente, si pudiera informarme de cualquier aplicación web que ofrezca actualmente este servicio (particularmente como vinculada a un Active Directory corporativo), le estaría muy agradecido. Me pregunto si otras aplicaciones web B2B como salesforce.com o hoovers.com ofrecen un servicio similar para sus clientes corporativos.

Odio estar en la oscuridad y agradecería mucho cualquier luz que pueda arrojar ...

Jeremy

Answer 1

Shibboleth está diseñado para soportar exactamente este escenario. Sin embargo, dependerá de las compañías de sus clientes que implementen los mecanismos del proveedor de identidad. Por el momento, eso solo es realmente común en las universidades. Además, si desea información del usuario (más que solo un identificador con seudónimo), necesitará que la compañía acepte liberarle esos atributos.

Me resulta difícil creer que muchas empresas le abran su sistema de autenticación corporativa, solo para proporcionar SSO.

Puede que sea mejor confiar en OpenID o similar, y usar una cookie "recordarme" para reducir la necesidad de que las personas ingresen contraseñas.

Answer 2

Un problema básico con su enfoque es que está considerando su aplicación web de forma aislada. Los empleados de la empresa de su cliente no solo requerirán SSO para su aplicación web, sino también algunos/pocos/muchos otros, y ampliar su enfoque requeriría una implementación personalizada para cada uno de ellos para permitir el acceso.

De ahí la adopción generalizada de OpenAthens y Shibboleth en la comunidad de la biblioteca académica para aprovechar el uso de las credenciales emitidas localmente. Una universidad típica de mediano y gran tamaño puede suscribirse a varios productos/servicios de más de cincuenta editoriales diferentes, y al desplegar OpenAthens/Shibboleth pueden aprovechar el estándar abierto de SAML (SAML es el protocolo que utiliza Shibboleth) que está viendo una mayor toma de decisiones. no solo en el sector académico, sino también en el sector comercial.

La respuesta de John arriba apunta a otro problema: hay una serie de estándares abiertos que han emergido recientemente, SAML y OpenID entre ellos. Por lo tanto, los proveedores de contenido tienen que decidir si desean implementar algunos o todos de forma nativa, pero usan pilas de tecnología separadas para que los costos de implementación y soporte puedan duplicarse.

Bastantes editores importantes han implementado OpenAthens ya que esto admite Athens, SAML/Shibboleth y OpenID en una sola plataforma, con opciones para conectar otras tecnologías también, o escribir un módulo personalizado para permitir que una aplicación interna se conecte, p. una facturación o el sistema de derechos de grabación que los usuarios de los clientes se están conectando en.

Este sector de la gestión de acceso es, sin duda moviendo hacia estándares abiertos, por lo que la construcción de su propio método estaría privando acceso a la aplicación de un gran número de usuarios