1 votes

Installer et déployer LDAP pour ses propres applications

Nous disposons d'un ensemble de diverses applications web dédiées à nos distributeurs et partenaires. Certaines sont des packages standards comme Alfresco, d'autres sont des sites web sur mesure.

Tous sont protégés par un login. Nous aimerions que nos utilisateurs aient un seul login pour toutes ces applications. Par conséquent, nous envisageons de configurer un serveur OpenLDAP pour répondre aux demandes d'authentification de toutes ces applications.

Où devons-nous stocker les droits d'utilisateur spécifiques à une application ? Par exemple, qui peut utiliser l'application 1, qui peut utiliser l'application 2 et avec quel rôle ? Doit-on les stocker dans LDAP ou dans la BD de l'application ?

En d'autres termes, devons-nous garder LDAP simplement pour la recherche d'identité/authentification de base et garder la trace de qui peut utiliser quelle application dans la base de données de chaque application ? Ou pouvons-nous stocker toutes ces informations dans LDAP (ce qui serait logique) ?

Merci de m'éclairer.

1voto

CraigJPerry Points 226

Pour des autorisations plus granulaires comme "a le droit de modifier la page d'accueil", je conserverais ces droits au niveau de l'application, mais pour les autorisations simples de type "a le droit de lire et d'écrire", je les implémenterais dans ldap pour des raisons de simplicité.

Il faut savoir que le nombre maximum de groupes auxquels un utilisateur peut être associé sur certaines plates-formes est limité. C'est pourquoi j'utiliserais un nom personnalisé pour l'attribut d'appartenance aux groupes d'applications afin que vous n'ayez même pas à y penser.

1voto

John Gardeniers Points 27097

Utilisez LDAP pour authentifier l'utilisateur et la BD d'application pour déterminer si cet utilisateur a des droits ou non. Vous pouvez consulter le site podría Il n'est pas possible de le faire uniquement dans LDAP, mais la séparation présente des avantages et facilite réellement la gestion. Ce n'est pas différent de la gestion des comptes utilisateurs dans un domaine et des autorisations de fichiers/dossiers dans un autre.

0voto

user207421 Points 970

Mettez tout dans LDAP, c'est à ça que ça sert.

0voto

Red Tux Points 2074

Il convient de souligner que, même s'il peut être tentant d'utiliser Active Directory en raison de ses capacités LDAP, ce n'est pas forcément le meilleur choix. AD, comme beaucoup de produits Microsoft, a tendance à bien fonctionner lorsque vous vous en tenez aux produits Microsoft, c'est lorsque vous devez commencer à mélanger les environnements que les choses deviennent bizarres. Cependant, Microsoft a le mérite de s'être grandement amélioré dans ce domaine au cours des dernières années. Le plus gros problème que vous risquez de rencontrer est de devoir modifier le schéma d'AD pour prendre en charge vos applications. Les modifications de schéma ne sont pas nécessairement prises en charge par Microsoft et risquent de compliquer toute mise à niveau future d'AD. Bien qu'en toute équité, cela soit vrai pour tout serveur LDAP, je dirais qu'il est plus fréquent que des modifications de schéma soient apportées aux serveurs LDAP. Si vous disposez d'un serveur AD existant, vous pouvez implémenter une opération de synchronisation entre votre serveur LDAP (tel que Red Hat Directory Server) et votre serveur AD. Cela peut vous permettre de synchroniser les noms d'utilisateurs, mais de conserver les informations spécifiques au système dans chaque domaine du serveur. Oui, cela ajoute une certaine complexité à l'administration mais, globalement, c'est l'une des approches les plus flexibles.

En fin de compte, l'authentification centralisée est régie par cela :

"Where do you want your pain?"

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X