vérifier les droits d'accès ldap avec python

Question

Je suis en train d'écrire une interface Web (django) pour un serveur LDAP. Il existe différents types de personnes avec différents types de privilèges, donc je configure LDAP ACL pour contrôler qui peut voir ou modifier un attribut spécifique. Maintenant, il est facile de déterminer si un utilisateur spécifique a un accès en lecture - essayez de lire, et vous verrez ce que vous obtenez. Mais je ne vois pas une manière élégante de faire la distinction entre l'accès en lecture et en écriture avant J'essaie actuellement d'écrire des changements. C'est-à-dire, je voudrais le préciser dans l'interface, si l'utilisateur connecté a un accès en écriture, ou ne peut que lire. Pour que les utilisateurs n'essaient pas de modifier un attribut qu'ils ne peuvent pas. La seule chose qui m'est venue à l'esprit était d'essayer d'écrire temporairement une sorte de mannequin dans un attribut, et de voir si cela a réussi. Si c'est le cas, la valeur d'origine serait restaurée, et je sais que cet utilisateur a un accès en écriture. Je peux alors afficher cet attribut comme éditable. Le problème avec ceci est que si le serveur tombe en panne après que le mannequin a été écrit et avant que la valeur originale ait été restaurée, il me reste des valeurs factices dans mon serveur LDAP. Ce dont j'aurais besoin, c'est d'un moyen d'interroger les listes de contrôle d'accès, d'une manière similaire à celle que je peux utiliser pour interroger les définitions de schéma. Mais peut-être que c'est "interdit" par LDAP?

Des idées?

Isaac

Answer 1

ACL, sur OpenLDAP sont organisées par chèque OU et/ou DN avec regexp

ex:

access to attrs=userPassword 
    by anonymous auth 
    by self write 
    by dn.base="ou=users_with_userPassword_write_access,dc=myproduct,dc=org" write 
    by dn.exact="cn=manager,dc=myproduct,dc=org" write 
    by * none 

access to * 
    by dn.exact="cn=manager,dc=myproduct,dc=org" write 
    by dn.base="ou=users_with_powerfull_write_access,dc=myproduct,dc=org" write 
    by * none 

Ainsi, en ce qui concerne, le dn de l'utilisateur connecté (whoami_s avec python-ldap), vous pouvez déterminer si l'utilisateur a des droits. Vous n'avez pas besoin de tester si vous pouvez écrire les données, implémentez une fonction dans votre application django qui vérifie le DN. Peut-être que vous dites que les ACL sont générés de façon dinamique?

---

En ce qui concerne votre commentaire, si votre ACL sont statiques, à savoir ACLs, la façon plus simple est de mettre en place une installation de python qui est de mettre en œuvre ces ACLs. Avec mon précédent exemple:

W_ACCESS_OU = "ou=users_with_powerfull_write_access,dc=myproduct,dc=org" 
def check_write_access(user_dn): 
    return is_dn_base(W_ACCESS_OU, user_dn) 

Pour l'instant, python-ldap ne peut pas récupérer les ACLs du slapd.conf ... Et ce n'est pas sûr d'analyser le slapd.conf (parce que slapd.conf peut être « partout "sur la déclaration du système et des ACL peut être difficile à analyser), il prend aussi beaucoup de temps pour essayer d'écrire des données sur le backend LDAP. Je sais que ce n'est pas très satisfaisant. Une autre solution consiste à utiliser un "utilisateur de service". Seul cet utilisateur a un accès en écriture sur le backend LDAP.

Il simplifie l'écriture de ACL:

access to * 
    by dn.exact="cn=manager,dc=myproduct,dc=org" write 
    by * none 

Ensuite, les utilisateurs réguliers, vous définissez le drapeau de l'autorisation. Votre application vérifie l'indicateur lorsque votre utilisateur connecté veut faire quelque chose. Et si ce drapeau est OK, l'utilisateur du service écrit des données sur le Backend.

C'est la stratégie que nous déployons sur l'une de nos applications.Dans les deux cas, la vérification de l'ACL est effectuée par notre application, et non par le backend LDAP.

Answer 2

Je pense que je vais essayer l'approche "test", si c'est trop lent peut-être avec un peu de mise en cache. La raison pour laquelle je veux conserver la définition ACL uniquement sur le serveur ldap est qu'il y a d'autres façons d'interagir avec le serveur (il y aura des outils cli, et aussi les outils ldap standard), donc je voudrais garder tous ceux interfaces dans la synchronisation ACL sage, avec un seul endroit pour définir ACL

Answer 3

Dans OpenLDAP les définitions ACL est en dehors de DIT. Si vous souhaitez accéder à ACL avec requête ldap vous pouvez FedoraDS utilisateur (389 serveur d'annuaire): http://directory.fedoraproject.org/wiki/Howto:AccessControl

Vous pouvez voir aussi OpenDS (https://www.opends.org)