active directory - Inicio de sesión único para una aplicación web

azure ad login

Question

He estado tratando de entender 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.

Aquí está el escenario:

1) Tiene una aplicación web compleja que ofrece contenido seguro por suscripción.

2) Se requiere que los usuarios inicien sesión en su aplicación con nombre de usuario y contraseña.

3) Vendes 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 se presente tendrá que proporcionar un mecanismo para:

• agregando nuevos usuarios
• eliminando usuarios
• cambiando la información del usuario
• permitiendo a los usuarios iniciar sesión

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

Ahora, tengo la teoría de que la forma 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 a 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.

Encontré información sobre un producto de Microsoft llamado Servicio de federación de directorio activo (ADFS) que puede ser o no 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 estoy yendo totalmente en la dirección incorrecta. 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 sobre cualquier aplicación web que ofrezca este servicio en la actualidad (especialmente si está vinculado 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 enormemente cualquier luz que puedas arrojar ...

Jeremy

Answer 1

Shibboleth está diseñado para admitir 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 cuesta creer que muchas empresas le abran su sistema de autenticación corporativa, solo para proporcionar SSO.

Es posible 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 aisladamente. 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 diferentes editores, y mediante la implementación de OpenAthens / Shibboleth pueden aprovechar el estándar abierto de SAML (SAML es el protocolo que utiliza Shibboleth) que está viendo una mayor toma de 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 surgido 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 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, por ejemplo, una facturación o derechos sistema que registra los usuarios de los clientes que inician sesión

Este sector de administración de acceso definitivamente se está moviendo hacia estándares abiertos, por lo que construir su propio método privaría el acceso a su aplicación para una gran cantidad de usuarios.