Gestion des bases de données utilisateur volumineuses pour le code d'accès unique

Question

Comment implémenteriez-vous un système ayant les objectifs suivants:

• gérer l'authentification, autorisation de des centaines de milliers d'utilisateurs existants actuellement étroitement intégrés à une application d'un fournisseur tiers (nous souhaitons décomposer ces utilisateurs en une solution que nous gérons et en optimisant le fonctionnement de nos applications, plus nos fournisseurs tiers s’y opposent).
• Gérer les informations de profil liées à ces utilisateurs
• Doit pouvoir être accessible depuis n'importe quel nombre d'applications Web sur toutes les plateformes (Windows, * Nix, PHP, ASP / C #, Python / Django, etc.).

Voici quelques exemples d'implémentations:

• LDAP / AD Server pour tout gérer. Utilisez un schéma personnalisé pour toutes les données de profil. Tout peut s'authentifier auprès de LDAP / AD et nous pouvons stocker toutes sortes d'ACL et de données de profil dans un schéma personnalisé.
• Utilisez LDAP / AD pour l’authentification uniquement, associez les utilisateurs LDAP à un serveur de profils / autorisations le plus robuste utilisant une sorte de base de données traditionnelle (MSSQL / PostgreSQL / MySQL) ou une base de données basée sur des documents (CouchDB, SimpleDB, etc.). Utilisez LDAP pour les autorisations, puis appuyez sur la base de données pour obtenir des informations plus avancées.
• Utilisez une base de données traditionnelle (relationnelle ou document) pour tout.

Certains de ces trois sont-ils les meilleurs? Existe-t-il d'autres solutions qui répondent aux objectifs ci-dessus et sont plus faciles à mettre en œuvre?

** J'ajouterais que presque toutes les applications qui s'authentifieront auprès de la base de données d'utilisateurs seront sous notre contrôle. Les rares personnes extérieures seront les applications pour lesquelles nous supprimons la base de données d'utilisateurs actuelle et peut-être 1 ou 2 autres. Rien de plus large pour nécessiter un serveur openID.

Il est également important de savoir que bon nombre de ces utilisateurs possèdent ces comptes depuis 5 à 8 ans et connaissent leurs identifiants de connexion, leurs mots de passe, etc. "

Answer 1

Il existe une différence entre authentification et autorisation / profilage, ne forcez donc pas nécessairement les deux dans un seul outil. Votre deuxième solution consistant à utiliser LDAP pour l'authentification et une base de données pour l'autorisation semble plus robuste car les données LDAP sont contrôlées par l'utilisateur et la base de données serait contrôlée par un administrateur. Ce dernier risque de se transformer en structure et en complexité au fil du temps, mais l'authentification n'est que cette authentification. La séparation de ces fonctions s’avérera plus facile à gérer.

Answer 2

Si vous avez une infrastructure ActiveDirectory existante, ce sera la voie à suivre. Cela sera particulièrement avantageux pour les entreprises pour lesquelles des serveurs Windows ont déjà été configurés pour l'authentification. Si tel est le cas, je me penche vers votre premier point dans "des exemples d'implémentations".

Sinon, il s'agira d'un basculement entre les options LDAP open source et AD.

Il pourrait ne pas être viable de lancer votre propre schéma d’authentification pour la connexion unique (en particulier compte tenu de la quantité de travail de documentation et d’intégration que vous pourriez avoir à faire), et bien sûr, ne regroupez pas votre serveur d’authentification avec l’un des composants suivants: applications fonctionnant sur votre système (car vous souhaitez que celui-ci puisse être indépendant de la charge de ces applications).

Goodluck!

Answer 3

Utilisez LDAP / AD pour l’authentification uniquement, associez les utilisateurs LDAP à un serveur de profils / autorisations le plus robuste utilisant une sorte de base de données traditionnelle (MSSQL / PostgreSQL / MySQL) ou une base de données basée sur des documents (CouchDB, SimpleDB, etc.). Utilisez LDAP pour les autorisations, puis appuyez sur la base de données pour obtenir des informations plus avancées.

Answer 4

Nous avons différents sites avec environ 100 000 utilisateurs et ils fonctionnent tous avec des bases de données normales. Si la plupart des applications peuvent accéder à la base de données, vous pouvez utiliser cette solution.

Answer 5

Vous pouvez toujours implémenter votre propre serveur OpenID . Il existe déjà une bibliothèque Python pour OpenID , ce qui devrait être relativement simple.

Bien sûr, vous n'avez pas besoin d'accepter les connexions autorisées par d'autres serveurs dans vos applications. Acceptez les identifiants autorisés uniquement par votre propre serveur.

Modifier: j'ai trouvé une implémentation du protocole de serveur OpenID dans Django .

Modifier2: La mise en œuvre d'OpenID pour vos utilisateurs présente un avantage évident. Ils pourront se connecter à StackOverflow avec leurs identifiants de connexion: -)