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

Question

He estado tratando de entender cómo se resuelve este problema por más de un mes. Es realmente necesario para llegar a un enfoque general que el trabajo. Tengo una teoría, pero no estoy seguro de que es el enfoque más fácil (o correcta) y no he podido encontrar ninguna información para apoyar mis ideas.

Este es el escenario:

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

Se requieren

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

3) Usted vende a las grandes corporaciones, que ya tienen una tecnología de autenticación empresarial (por ejemplo, Active Directory).

4) ¿Le gustaría integrarse con el mecanismo de autenticación corporativa para permitir a sus usuarios iniciar sesión en su aplicación web sin tener que introducir 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
• permite a los usuarios inician sesión en

Lo ideal es que todo esto sucedería "automágicamente" cuando el cliente corporativo hizo los cambios correspondientes a su propia autenticación.

Ahora, tengo una teoría que la manera de hacer esto (al menos para Active Directory) sería para mí escribir una aplicación de cliente que se integra con Active Directory del cliente para realizar un seguimiento de los cambios específicos, y luego se comunican los cambios en mi aplicación web. Creo que si esta comunicación se realiza a través de Servicios Web ofrecido por mi aplicación web, entonces sería mantener un nivel unhackable de seguridad, lo que, obviamente, sería un requisito para estos clientes corporativos.

he encontrado alguna información acerca de un producto de Microsoft Active Directory denominada Federación de servicio (AD FS) que puede o no puede ser el enfoque correcto para mí. Parece ser un poco voluminosos y tienen algunos requisitos que podría no funcionar para todos los clientes.

Para otros escenarios de identificación existentes (como Atenas y Shibboleth), no creo que una aplicación cliente es necesario. Es probablemente sólo una cuestión de atar en los servicios de identificación existentes.

Le agradecería cualquier consejo que cualquier persona tiene sobre todo lo que he mencionado aquí. En particular, si usted me puede decir si mi teoría es correcta acerca de proporcionar una aplicación de cliente que se comunica con el lado del servidor de servicios web, o si estoy totalmente de ir en la dirección equivocada. Además, si usted me podría apuntar a todos los sitios web o artículos que explican cómo hacer esto, yo realmente lo aprecio. Mi investigación no ha aparecido mucho hasta ahora.

Por último, si usted podría dejarme saber de las aplicaciones web que actualmente ofrecen este servicio (en particular, atado a un directorio activo corporativo), estaría muy agradecido. Me pregunto si otra aplicación web B2B como salesforce.com, o hoovers.com ofrecer un servicio similar para sus clientes corporativos.

No me gusta estar en la oscuridad y agradecería enormemente cualquier luz que puede arrojar ...

Jeremy

Answer 1

Shibboleth está diseñado para soportar exactamente este escenario. Sin embargo, se basará en las empresas de sus clientes que implementan los mecanismos de proveedores de identidad. Por el momento, eso es sólo muy común en las universidades. Además, si desea que la información del usuario (no más que sólo un identificador seudónimo), que había necesidad de la empresa de acuerdo en liberar esos atributos para ti.

Me resulta difícil creer que muchas empresas se abrirían su sistema de autenticación corporativa para usted, sólo para proporcionar SSO.

Puede que le resulte mejor confiar en OpenID o similares, y el uso de una cookie "recuérdame" para reducir la necesidad de que la gente entre en las contraseñas.

Answer 2

Uno de los problemas básicos con su enfoque es que usted está pensando en su aplicación web de forma aislada. Los empleados de la empresa de su cliente no sólo va a requerir SSO a su aplicación web, sino también algunos / algunas / muchas otras, y la ampliación de su enfoque requeriría una aplicación a medida para cada uno de los para permitir el acceso.

Por lo tanto, la adopción generalizada de OpenAthens y Shibboleth en la comunidad biblioteca académica para aprovechar el uso de credenciales emitidas localmente. Un medio típico / universidad grande puede suscribirse a varios productos / servicios de más de cincuenta editores diferentes, y mediante la implementación de OpenAthens / Shibboleth que puede aprovechar el estándar abierto de SAML (SAML es el protocolo que utiliza Shibboleth) que está viendo aumentó take no sólo en el ámbito académico, sino también en el sector comercial.

La respuesta de John anterior apunta a otro problema: hay una serie de estándares abiertos que recientemente han surgido, SAML y OpenID entre ellos. Así que los proveedores de contenidos tienen que decidir si quieren poner en práctica algunas o todas estas cosas de forma nativa, sino que utilizan la tecnología de pilas separadas y por lo que los costes de implementación y soporte pueden ser duplicadas.

Un buen número de grandes editoriales han implementado OpenAthens como esta apoyos Atenas, SAML / Shibboleth y OpenID en una sola plataforma, con opciones para enchufar en otras tecnologías también, o escribiendo un módulo personalizado para permitir una aplicación interna para conectar, por ejemplo, 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