2008-09-16 11 views
6

¿Cómo implementar un sistema con los siguientes objetivos:Gestión de bases de datos de usuarios grandes de inicio de sesión único

  • administrar la autenticación, autorización para cientos de miles de usuarios existentes Actualmente estrechamente integradas con una Aplicación del proveedor externo (Queremos convertir a estos usuarios en algo que administramos y hacer que nuestras aplicaciones trabajen en su contra, además nuestros proveedores de terceros trabajan en contra de esto).
  • Administrar información de perfil vinculada a esos usuarios
  • Se debe poder acceder desde cualquier número de aplicaciones web en casi cualquier plataforma (Windows, * nix, PHP, ASP/C#, Python/Django, etc.).

Aquí algunos ejemplos de implementaciones:

  • LDAP/AD Server para gestionar todo. Use un esquema personalizado para todos los datos de perfil. Todo puede autenticarse contra LDAP/AD y podemos almacenar todo tipo de ACL y datos de perfil en un esquema personalizado.
  • Utilice LDAP/AD solo para autenticación, vincule a los usuarios de LDAP a un servidor de autorización/perfil más robusto utilizando algún tipo de base de datos tradicional (MSSQL/PostgreSQL/MySQL) o DB basado en documentos (CouchDB, SimpleDB, etc.). Use LDAP para autorización, luego presione DB para obtener información más avanzada.
  • Use una base de datos tradicional (Relacional o Documento) para todo.

¿Alguno de estos tres es el mejor? ¿Existen otras soluciones que se ajusten a los objetivos anteriores y que sean más fáciles de implementar?

** Debo añadir que casi todas las aplicaciones que se autenticarán en la base de datos de usuarios estarán bajo nuestro control. Los únicos que quedan fuera serán las aplicaciones de las que estamos eliminando la base de datos de usuarios actual y quizás 1 o 2 más. Nada tan amplio como para necesitar un servidor openID.

También es importante saber que muchos de estos usuarios han tenido estas cuentas durante 5-8 años y conocen sus inicios de sesión y contraseñas, etcétera.

Respuesta

3

Existe una diferencia entre la autenticación y la autorización/creación de perfiles, por lo tanto, no fuerce ambos elementos necesariamente en una sola herramienta. Su segunda solución de uso de LDAP para autenticación y un DB para autorización parece más sólida ya que los datos LDAP son controlados por el usuario y el DB sería controlado por un administrador. Lo último probablemente se transformaría en estructura y complejidad a lo largo del tiempo, pero la autenticación es solo esa autenticación. La separación de estas funciones resultará más manejable.

-1

Siempre puede implementar su propio servidor OpenID. Ya existe un Python library for OpenID por lo que debería ser bastante fácil.

Por supuesto que no necesita aceptar inicios de sesión autorizados por otros servidores en sus aplicaciones. Acepte las credenciales autorizadas solo por su propio servidor.

Editar: He encontrado un implementation of OpenID server protocol in Django.

Edit2: Existe una ventaja obvia al implementar OpenID para sus usuarios. Podrán iniciar sesión en StackOverflow con sus inicios de sesión :-)

+0

Debo agregar que casi todas las aplicaciones que se autenticarán en la base de datos de usuarios estarán bajo nuestro control. Nada tan amplio como para necesitar un servidor openID. También es importante saber que muchos de estos usuarios han tenido estas cuentas durante 5-8 años y conocen sus inicios de sesión y contraseñas –

2

Si tiene una infraestructura ActiveDirectory existente, ese será el camino a seguir. Esto será particularmente ventajoso para las empresas que ya tienen servidores de Windows configurados para la autenticación. Si este es el caso, me inclino por su primer punto de viñeta en "implementaciones de muestra".

De lo contrario, será un lanzamiento entre AD y opciones LDAP de código abierto.

Puede que no sea viable ejecutar su propio esquema de autenticación para el inicio de sesión único (especialmente teniendo en cuenta la gran cantidad de documentación e integración que puede tener que hacer) y obviamente no agrupe su servidor de autenticación con ninguno de las aplicaciones que se ejecutan en su sistema (ya que desea que sean independientes de la carga de dichas aplicaciones).

Goodluck!

+0

La base de datos de usuarios actual + perfiles se almacenan en nuestra base de datos tradicional de proveedores externos (* SQL). Tenemos una capacidad muy limitada para integrar en esa base de datos y preferimos tener un control total sobre ella. Nos gustaría liberar a esos usuarios y luego hacer que el tercero trabaje con el nuevo db/ldap –

+0

Lo bueno de LDAP es que otros productos de terceros para la empresa deberían poder conectarse a él para la administración del usuario. –

+0

Creo que LDAP es probablemente una opción para la migración de autenticación de este proyecto, pero ¿qué pasa con el almacenamiento de información de perfil? ¿Rellenarlo en LDAP también? ¿Salir a una tienda diferente? –

0

Utilice LDAP/AD solo para autenticación, vincule usuarios LDAP a un servidor de autorización/perfil más robusto utilizando algún tipo de base de datos tradicional (MSSQL/PostgreSQL/MySQL) o DB basado en documentos (CouchDB, SimpleDB, etc.). Use LDAP para autorización, luego presione DB para obtener información más avanzada.

+0

Elijo esto como una respuesta "segura" ya que no estoy seguro de cuán flexibles los cambios en el esquema de LDAP están en producción una vez. Sin embargo, me siento muy cómodo al usarlo para una tienda de usuarios mientras modifico una base de datos a medida que se agregan características. –

0

Tenemos diferentes sitios con alrededor de 100k usuarios y todos funcionan con bases de datos normales. Si la mayoría de las aplicaciones pueden acceder al archivo db, puede usar esta solución.

Cuestiones relacionadas