7 votos

¿Es una base de datos MySQL una alternativa viable a LDAP?

(Disculpas si me estoy preguntando el tipo equivocado de pregunta o en el lugar equivocado.)

Corremos por nuestra asociación (todos voluntarios). Tenemos un servidor con base de datos de miembros en OpenLDAP, servidor de correo, ftp y un montón de caseros aplicaciones web.

La mayor parte de esto está muy bien, excepto por el OpenLDAP base de datos de miembros. Las personas que configurar son cosa del pasado y el actual grupo no es realmente capaz de hacer cambios.

Así que, yo estaba pensando acerca de cómo mover el miembro de la base de datos de OpenLDAP para una base de datos MySQL. Esto parece posible, nuestro correo electrónico y el servidor FTP de soporte de SQL fuentes y podemos modificar nuestros webapps en consecuencia. Pero todavía no puedo decidir si hay una desventaja de hacer esto. De ahí mi pregunta:

  • ¿Cuáles son las ventajas de un servidor LDAP a través de una base de datos SQL? (Para el simple usuario de la base de datos)
  • ¿Hay razones para no utilizar MySQL como base de datos de usuarios?

No podía encontrar un comparables pregunta de por aquí. Y la información me parece externamente me lleva a páginas de más de 10 años de edad.

12voto

Sven Puntos 51980

Este es un tema amplio con ninguna respuesta sencilla, ya que depende de muchos factores.

Algunos de los beneficios de (Abierto)LDAP como base de datos de usuario:

  • LDAP tiene una inherente de la estructura de árbol que se puede hacer de la estructuración de las grandes organizaciones más fácil. También es más fácil tener un campo de datos para un registro que es realmente una lista de las cosas (como "el usuario es miembro de estos grupos"), a continuación, hacer esto en bases de datos SQL (nota: es absolutamente posible en SQL, poco más complicado).
  • Es más fácil de utilizar LDAP como una central de base de datos de usuario para múltiples sistemas. Esto no es tanto un problema para cosas como el Correo electrónico o FTP que también se podría usar Linux PAM como auth de origen o para el cultivo doméstico de los sistemas de control, pero especialmente si se le añade la tercera parte de las aplicaciones web, que a menudo terminan con cada sistema tiene su propia base de datos de usuario incompatible con esquemas que no puede compartir los datos. En ese caso, usted puede a menudo en menos de sincronización y/o autenticación contra LDAP.
  • LDAP clases de objetos para los registros facilita el uso de la misma base de datos para una gran cantidad de diferentes sistemas con diferentes requisitos - sólo tiene que añadir un objeto de la clase para el registro y obtener un montón de la clase específica de campos que no están presentes con otros registros, y tendría que haber un montón de campos vacíos para cada registro en SQL.
  • LDAP puede ser una caja negra sistema de autenticación. Esto significa que usted puede tener una aplicación que sólo envía un nombre de usuario y contraseña LDAP y pregunte "¿Es este combo válido?" y obtener una respuesta de Sí o No. Con SQL, la aplicación necesita leer la base de datos y hacer la verificación en sí.

Por desgracia, en realidad, la gestión de LDAP está mucho más involucrado en comparación con una simple base de datos SQL y si todos los sistemas pueden funcionar completamente con el mismo usuario de SQL de la base de datos, no hay ninguna razón real por la que usted necesita para tener LDAP en su lugar. Por otro lado, yo creo que muy largo y tendido acerca de si en realidad, no es más fácil sentarse y entender LDAP antes de la extracción y reemplazarlo con algo más. Estos cambios tienden a parecer fácil al principio, pero en el camino siempre hay temas que aparecen no ha considerado que hace las cosas mucho más difícil que la prevista.

4voto

Ángel Puntos 181

Se puede utilizar una base de datos MySQL como una fuente compartida de cuentas de usuario? Sí, definitivamente. He montado este sistema y funciona bastante bien con múltiples aplicaciones.

Así, cuales son los inconvenientes de utilizar una base de datos MySQL en lugar de LDAP?

a) la necesidad de adaptar todas las aplicaciones a utilizar su base de datos.

Generalmente, no es una gran cantidad de trabajo para adaptar una aplicación. A menudo, sólo se puede resolver mediante la realización de una vista que se adapte a los nombres de columna. A veces, puede ser necesario añadir un poco de código para atender una contraseña diferente hash formato, o para crear un complemento de autenticación.

Sin embargo, usted tendrá que hacer eso para cada aplicación. Y cuando se le pregunte el día de mañana para instalar una nueva aplicación de internet (por ejemplo, alguien decide agregar un blog de Wordpress), usted tendrá que hacer de nuevo el estudio de la aplicación y ver cómo adaptarlo.

'Todo el mundo' admite la autenticación contra LDAP. Es el de facto estándar, y usted va a encontrar plugins para hacer la autenticación LDAP en cualquier aplicación con un tamaño decente (y para los que no, hay un caso claro para su implementación). Hay algunos (muy pocos) alternativas, y que tiene poco apoyo para ser utilizado para la autenticación.

También tenga en cuenta, si una aplicación pasa a utilizar otro motor de base de datos (supongamos que hay un nuevo desarrollo que requiere el uso de PostgreSQL), puede ser más difícil, además, hacer de soporte de ti de una tabla de usuario de un motor diferente (mysql).

Por supuesto, la adaptación en sí, solo se puede hacer si es su propio desarrollo o de fuente abierta. Olvidarse de llegar de Microsoft Windows para apoyar tal esquema personalizado!

b) Seguridad de la centralización

Usando un centro servidor de autenticación tiene múltiples beneficios:

Para uno, si usted tiene un servidor central, y alguien trata de fuerza bruta la contraseña para el usuario john, una instalación común es que se bloquee al usuario por algún tiempo (o hasta que manualmente no bloqueada). Si usted tiene una docena de servicios, incluso si todos ellos había algunos de limitación de medidas (sugerencia: probablemente no), cada uno de ellos serían separados, y atacando a los múltiples servicios que un atacante podría en realidad tener N intenta veces el número de servicios. Usted tendría que coordinar que los metadatos en la base de datos compartida, y todos los servicios para comprobar y aplicar de la misma manera (más de código para agregar a las aplicaciones, correo y ftp, servidores...).

Segundo, la central de registro. De realizar la autenticación en un único servicio permite disponer de una única autenticación de registro, en lugar de tener que dividir en múltiples lugares.

En tercer lugar, es un punto único para las actualizaciones. Desea alejarse de hashes MD5 para uso pdkdf2 o Argon2? Usted sólo tendrá que actualizar el servidor de autenticación de apoyo. Otra cosa que usted necesita para obtener de cada uno y de todos los servicios de apoyo que el nuevo formato.

Cuarto, un mayor aislamiento. Si todos los autenticación pasa a través del servidor central, debe ser configurado de modo que él es el único capaz de leer los datos sensibles, y usted puede concentrarse en sus esfuerzos para asegurarse de que es seguro. Sin embargo, si todas las necesidades de servicio para comprobar las contraseñas de usuario, usted tiene una superficie mucho mayor: una vulnerabilidad de inyección SQL en cualquier de ellos permitiría volcar la lista de usuarios y hash (y ya estoy asumiendo que fue de sólo lectura, de lo contrario, puede incluso ser capaz de modificar o insertar usuarios falsos).


Por favor, tenga en cuenta que usted podría solucionar (b) por tener un servidor central que no utilice LDAP en todo. Pero dado que (a) tiene sentido para seguir usando el protocolo LDAP para la autenticación.

No hay ninguna razón un servidor LDAP utiliza principalmente para la autenticación no se puede usar una base de datos MySQL para el almacenamiento. De hecho, LDAP es mucho más potente que el uso típico que se presenta (que es por qué parece tan desalentador). Sin embargo, yo no soy consciente de que cualquier aplicación que hace eso.

Mi recomendación es mantener su actual servidor LDAP y crear si es necesario una interfaz para realizar las acciones más comunes en ella (hay LDAP múltiples interfases, tal vez uno de ellos sería cubrir sus necesidades del grupo?).

Si quería cambiar de aplicaciones web personalizadas proceso de inicio de sesión, me gustaría hacerlos para apoyar una Única solución de inicio De sesión como SAML, pero me gustaría, no obstante, todavía tiene que usar ese backend LDAP, que sería compartida con su FTP, correo y otros servicios.

3voto

Suman Puntos 172

Sólo quería añadir algo que no es (todavía) señaló que en las otras respuestas: comparación de LDAP y SQL es como comparar manzanas y naranjas, ya que ellos se sientan en diferentes capas en la pila.

  • LDAP = admite directorio de servicios sobre IP
  • SQL = genéricos de gestión de base de datos, que podría, por supuesto, incluyen gestión de usuarios

Puede implementar LDAP utilizando bases de datos de SQL, pero recuerde que el apoyo de diferentes características. (De hecho, la mayoría de LDAP soluciones probable que el uso de algunos de SQL o base de datos detrás de las escenas.)

LDAP es un estándar de la industria para los servicios de directorio. Es posible que muchos de tus aguas abajo de servicios se basan en el servicio LDAP para la autenticación, autorización, etc, en cuyo caso usted tendrá que construir un LDAP compatible capa en la parte superior de su nueva base de datos SQL.

Al mismo tiempo, es posible que otras aplicaciones no necesitan este LDAP de compatibilidad, y puede ser más fácil para migrar a su propio SQL gestión de usuarios. Pero incluso en este caso, sospecho que usted puede ser que necesite su propio usuario de la lógica de la administración en las aplicaciones (a menos que el apoyo de OAuth o algo similar).

Yo recomendaría mirar tus otras aplicaciones para ver cómo atado son para el servicio LDAP para inicio de sesión y la autorización de servicios y, a continuación, decidir cómo de fácil o difícil que sería para migrar a una base de datos SQL personalizada solución.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: