2010-11-19 7 views
2

Ich schreibe ein Web-Frontend (Django) für einen LDAP-Server. Es gibt verschiedene Arten von Personen mit verschiedenen Arten von Berechtigungen. Daher richte ich LDAP-ACL ein, um zu steuern, wer ein bestimmtes Attribut sehen oder bearbeiten darf. Jetzt ist es einfach festzustellen, ob ein bestimmter Benutzer Lesezugriff hat - versuchen Sie zu lesen, und Sie werden sehen, was Sie bekommen. Aber ich sehe keine elegante Möglichkeit, zwischen Lese- und Schreibzugriff zu unterscheiden vor Ich versuche tatsächlich, einige Änderungen zu schreiben. Das heißt, ich möchte an der Schnittstelle deutlich machen, ob der angemeldete Benutzer Schreibzugriff hat oder nur lesen kann. Damit Benutzer nicht versuchen, ein Attribut zu bearbeiten, das nicht möglich ist.check ldap Zugriffsrechte mit Python

Das einzige, was mir in den Sinn kam, war zu versuchen, vorübergehend eine Art Dummy in ein Attribut zu schreiben und zu sehen, ob das erfolgreich war. Wenn dies der Fall ist, wird der ursprüngliche Wert wiederhergestellt, und ich weiß, dass dieser Benutzer Schreibzugriff hat. Ich kann dieses Attribut dann als bearbeitbar anzeigen. Das Problem dabei ist, dass, wenn der Server abstürzt, nachdem der Dummy geschrieben wurde und bevor der ursprüngliche Wert wiederhergestellt wurde, bleiben Dummy-Werte in meinem LDAP-Server.

Was ich brauche, ist eine Möglichkeit, die ACLs abzufragen, ähnlich wie ich Schemadefinitionen abfragen kann. Aber vielleicht ist das durch LDAP "verboten"?

Irgendwelche Ideen?

Isaac

+0

Welche LDAP-Server Sie tun benutzen? Welche Schnittstelle/Bindungen verwenden Sie, um darauf zuzugreifen? – ThomasH

+0

Ich benutze Openldap 2.3.32 und Python 2.6 ldap Bindings (Import ldap) – Isaac

+0

Es kommt mir vor, dass ich keinen Dummy schreiben muss, um zu sehen, ob ich Schreibzugriff habe. Ich könnte einfach versuchen, den ursprünglichen Wert zu schreiben, was zu einem Fehler führen würde, wenn ich keinen Schreibzugriff hätte und nichts ändern würde, wenn ich Lesezugriff hätte. Trotzdem, scheint nicht so elegant. – Isaac

Antwort

0

ACL, auf OpenLDAP werden durch OU organisiert und/oder DN-Check mit 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 

Also, in Bezug auf die dn des angemeldeten Benutzers (whoami_s mit python-ldap), können Sie feststellen, ob der Benutzer einige Rechte hat. Sie müssen nicht testen, ob Sie die Daten schreiben können, implementieren Sie eine Funktion in Ihrer Django-Anwendung, die den DN überprüft.

Vielleicht sagen Sie, dass ACL dynamisch generiert werden?


In Bezug auf Ihren Kommentar, wenn Ihre ACL statisch sind, ACLs zu wissen, ist der einfachere Weg, um eine Python-Anlage zu implementieren, die diese ACLs implementieren ist. Mit meinem früheren 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) 

Vorerst python-ldap können die slapd.conf die ACLs nicht abrufen ... Und es ist nicht sicher, die slapd.conf zu analysieren (weil slapd.conf „überall sein kann "Auf der System- und ACLs-Deklaration kann es schwierig sein, sie zu analysieren." Außerdem benötigt es viel Zeit, um Daten auf dem LDAP-Backend zu schreiben.

Ich weiß, das ist nicht sehr zufriedenstellend. Eine andere Lösung besteht darin, einen "Dienstbenutzer" zu verwenden. Nur dieser Benutzer hat Schreibzugriff auf das LDAP-Backend.

Es vereinfacht ACL Schreiben:

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

Dann auf regelmäßige Nutzer, Sie richten eine Flagge der Genehmigung. Ihre Anwendung überprüft das Flag, wenn Ihr angemeldeter Benutzer etwas unternehmen möchte. Und wenn dieses Flag in Ordnung ist, schreibt der Dienstbenutzer Daten in das Backend.

Dies ist die Strategie, die wir in einer unserer Anwendungen implementieren.

In beiden Fällen wird die ACL-Prüfung von unserer Anwendung durchgeführt, nicht vom LDAP-Backend.

+0

Tut mir leid, ich könnte langsam verstehen, aber: wenn ich meine DN weiß, woher weiß ich über die ACL? Die ACL ist in slapd.conf definiert, was meiner Django-App - zumindest konzeptionell - unbekannt ist. Schlägst du vor, slapd.conf von django zu analysieren? – Isaac

+0

Um Ihre Frage zu beantworten: Meine ACL sind statisch. Trotzdem kann ich einige Einstellungen gelegentlich ändern, also hätte ich gerne einen einzigen Platz, um sie zu definieren. – Isaac

+0

@Isaac, habe ich meine Antwort mit weiteren Informationen vervollständigt – ohe

0

Ich denke, ich werde versuchen, die "Test" Approch, wenn es zu langsam vielleicht mit etwas Caching. Der Grund, warum ich die ACL-Definition nur auf dem LDAP-Server behalten möchte, ist, dass es andere Möglichkeiten gibt, mit dem Server zu interagieren (es gibt CLI-Tools und auch die Standard-LDAP-Tools), also möchte ich diese behalten Schnittstellen ACL-synchron, mit nur einem Platz zum Definieren von ACLs