Une base de données MySQL est-elle une alternative viable à LDAP?
(Toutes mes excuses si je pose le mauvais type de question ou au mauvais endroit.)
Nous gérons l'informatique pour notre association (tous bénévoles). Nous avons un serveur avec une base de données de membres dans OpenLDAP, un serveur de messagerie, ftp et un tas d'applications Web maison.
La plupart de cela est très bien, à l'exception de la base de données des membres OpenLDAP. Les personnes qui l'ont installé sont parties depuis longtemps et le groupe informatique actuel n'est pas vraiment capable d'apporter des changements.
Donc, je pensais à déplacer la base de données des membres d'OpenLDAP vers une base de données MySQL. Cela semble possible, notre serveur de messagerie et FTP prend en charge les sources SQL et nous pouvons modifier nos applications Web en conséquence. Mais je ne peux toujours pas décider s'il y a un inconvénient à le faire. D'où mes questions:
- Quels sont les avantages d'un LDAP par rapport à une base de données SQL? (Pour une base de données utilisateur simple)
- Y a-t-il des raisons de ne pas utiliser MySQL comme base de données d'utilisateurs?
Je n'ai pas pu trouver une question comparable ici. Et les informations que je trouve à l'extérieur me conduisent à des pages de plus de 10 ans.
Il s'agit d'un vaste sujet sans réponse simple, car il dépend de nombreux facteurs.
Quelques avantages de (Open) LDAP en tant que base de données utilisateur:
- LDAP possède une arborescence inhérente qui peut faciliter la structuration de grandes organisations. Il est également plus facile d'avoir un champ de données pour un enregistrement qui est vraiment une liste de choses (comme "l'utilisateur est membre de ces groupes") puis de le faire dans les bases de données SQL (remarque: les deux sont absolument possibles en SQL, juste plus compliqués) .
- Il est plus facile d'utiliser LDAP comme base de données utilisateur centrale pour plusieurs systèmes. Ce n'est pas tellement un problème pour des choses comme Mail ou FTP qui pourraient également utiliser Linux PAM comme source d'authentification ou pour les systèmes que vous contrôlez, mais surtout si vous ajoutez des applications Web tierces, vous vous retrouvez souvent avec chaque système ayant son propre base de données utilisateur avec des schémas incompatibles qui ne peuvent partager aucune donnée. Dans ce cas, vous pouvez souvent au moins synchroniser avec et/ou authentifier contre LDAP.
- Les classes d'objets LDAP pour les enregistrements facilitent l'utilisation de la même base de données pour de nombreux systèmes différents avec des exigences différentes - il suffit d'ajouter une classe d'objet à l'enregistrement et d'obtenir un tas de champs spécifiques à la classe qui ne sont pas présents avec d'autres enregistrements et besoin d'être un tas de champs vides pour chaque enregistrement dans SQL.
- LDAP peut être un système d'authentification de boîte noire. Cela signifie que vous pouvez avoir une application qui envoie uniquement un nom d'utilisateur et un mot de passe à LDAP et demander "Est-ce que ce combo est valide?" et obtenez une réponse Oui/Non. Avec SQL, l'application doit réellement lire la base de données et effectuer la vérification elle-même.
Malheureusement, la gestion de LDAP est beaucoup plus complexe que celle d'une simple base de données SQL et si tous vos systèmes peuvent fonctionner pleinement avec la même base de données utilisateur SQL, il n'y a aucune raison réelle pour laquelle vous avez besoin pour avoir LDAP à la place. D'un autre côté, je pense très long et difficile s'il n'est pas vraiment plus facile de s'asseoir et de comprendre LDAP avant de le déchirer et de le remplacer par autre chose. Ces types de changements ont tendance à sembler faciles au début, mais en cours de route, il y a toujours des problèmes que vous n'avez pas pris en compte, ce qui rend les choses beaucoup plus difficiles que prévu.
Pouvez-vous utiliser une base de données MySQL comme source partagée de comptes d'utilisateurs? Oui définitivement. J'ai monté un tel système et cela fonctionne assez bien avec plusieurs applications.
Alors, quels sont les inconvénients de l'utilisation d'une base de données MySQL au lieu de LDAP?
a) Vous devez adapter toutes les applications pour utiliser votre base de données.
L'adaptation d'une application ne demande généralement pas beaucoup de travail. Souvent, vous pouvez simplement le résoudre en créant une vue qui adapte les noms de colonne. Parfois, vous devrez peut-être ajouter un peu de code pour répondre à un format de hachage de mot de passe différent, ou pour créer un plug-in d'authentification.
Cependant, vous devrez le faire pour chaque application . Et quand on vous demandera demain d'installer une nouvelle application Web (par exemple, quelqu'un décide d'ajouter un Wordpress), vous devrez recommencer l'étude de l'application et voir comment l'adapter.
'Tout le monde' prend en charge l'authentification contre LDAP. C'est la norme de facto , et vous trouverez des plugins pour faire l'authentification LDAP sur toute application avec une taille décente (et pour celles qui ne le font pas, il y a un argument clair pour l'implémenter). Il existe quelques (très peu) alternatives, et elles ont peu de support pour être utilisées pour l'authentification.
Notez également que si une application utilise un moteur de base de données différent (supposons qu'un nouveau développement nécessite l'utilisation de PostgreSQL), il peut être plus difficile de lui faire prendre en charge une table utilisateur à partir d'un moteur différent (mysql).
Bien sûr, l'adaptation elle-même, vous ne pouvez le faire que si c'est votre propre développement ou open source. Oubliez que Microsoft Windows prenne en charge un tel schéma personnalisé!
b) Centralisation de la sécurité
L'utilisation d'un serveur d'authentification central présente de multiples avantages:
D'une part, si vous avez un serveur central et que quelqu'un essaie de forcer le mot de passe de l'utilisateur john, une configuration courante consiste à le faire bloquer l'utilisateur pendant un certain temps (ou jusqu'à ce qu'il soit débloqué manuellement). Si vous avez une douzaine de services, même si tous avaient des mesures de limitation (indice: probablement pas), chacun d'eux serait séparé, et en attaquant plusieurs services, un attaquant aurait en fait N essais multiplié par le nombre de services . Vous auriez besoin de coordonner ces métadonnées dans la base de données partagée, et tous les services pour les vérifier et les implémenter de la même manière (plus de code à ajouter aux applications, mail et serveurs ftp ...).
Deuxièmement, la journalisation centrale. L'authentification sur un seul service vous permet d'avoir un seul journal d'authentification, plutôt que de le répartir sur plusieurs emplacements.
Troisièmement, il s'agit d'un point unique pour les mises à jour. Vous souhaitez vous éloigner des hachages MD5 pour utiliser pdkdf2 ou Argon2? Il vous suffit de mettre à jour le serveur d'authentification pour le prendre en charge. Sinon, vous devrez obtenir chaque service pour prendre en charge ce nouveau format.
Quatrièmement, un plus grand isolement. Si toute l'authentification passe par le serveur central, elle doit être configurée de sorte qu'il soit le seul à pouvoir lire les données sensibles, et vous pouvez concentrer vos efforts pour vous assurer qu'elles sont sécurisées. Cependant, si chaque service a besoin de vérifier les mots de passe des utilisateurs, votre surface est bien plus importante: une vulnérabilité d'injection SQL sur n'importe lequel permettrait de vider la liste d'utilisateurs et de hachages (et je suppose déjà qu'il a été mis en lecture seule, sinon ils peuvent même être en mesure de les modifier ou d'insérer de faux utilisateurs).
Veuillez noter que vous pourriez résoudre (b) en ayant un serveur central qui n'utilisait pas du tout LDAP. Mais étant donné (a), il est logique de continuer à utiliser le protocole LDAP pour l'authentification.
Il n'y a aucune raison qu'un serveur LDAP principalement utilisé pour l'authentification ne puisse pas utiliser une base de données MySQL pour le stockage. En fait, LDAP est beaucoup plus puissant que l'utilisation typique qu'il obtient (c'est pourquoi il semble si intimidant). Cependant, je ne suis au courant d'aucune mise en œuvre faisant cela.
Ma recommandation est de conserver votre serveur LDAP actuel et de créer si nécessaire une interface pour effectuer les actions les plus courantes (il existe plusieurs frontaux LDAP, peut-être que l'un d'entre eux couvrirait les besoins de votre groupe informatique?).
Si vous souhaitez modifier le processus de connexion de vos applications Web personnalisées, je les ferais prendre en charge une solution d'authentification unique telle que SAML, mais je continuerais néanmoins à utiliser ce backend LDAP, qui serait partagé avec votre FTP, votre messagerie et autres services.
Je voulais juste ajouter quelque chose qui n'était pas (encore) souligné dans les autres réponses: comparer LDAP et SQL, c'est comparer des pommes et des oranges car elles se trouvent sur différentes couches de la pile.
- LDAP = prend en charge les services d'annuaire sur IP
- SQL = gestion de base de données générique, qui pourrait bien sûr inclure la gestion des utilisateurs
Vous pouvez implémenter LDAP à l'aide de bases de données SQL, mais n'oubliez pas qu'elles prennent en charge différentes fonctionnalités. (En fait, la plupart des solutions LDAP utilisent probablement une base de données SQL ou autre en arrière-plan.)
LDAP est une norme de l'industrie pour les services d'annuaire. Il est possible que bon nombre de vos services en aval s'appuient sur le service LDAP pour l'authentification, l'autorisation, etc., auquel cas vous devrez toujours créer une couche compatible LDAP au-dessus de votre nouvelle base de données SQL.
Dans le même temps, il est possible que vos autres applications n'aient pas besoin de cette compatibilité LDAP, et il pourrait être plus facile de migrer vers votre propre gestion des utilisateurs SQL. Mais même dans ce cas, je soupçonne que vous pourriez avoir besoin de votre propre logique de gestion des utilisateurs dans les applications (sauf si elles prennent en charge OAuth ou quelque chose de similaire.)
Je recommanderais d'examiner d'abord vos autres applications informatiques pour voir à quel point elles sont liées au service LDAP pour les services de connexion et d'autorisation, puis décider à quel point il serait facile ou pénible de migrer vers une solution de base de données SQL personnalisée.