Wenn ein RBAC-Modell mit einem LDAP-Speicher implementiert wird (ich verwende Apache Directory 1.0.2 als Testumgebung), sind einige der Akteure offensichtlich auf bestimmte objectClasses abbildbar:
In der Vergangenheit habe ich Modelle gesehen, bei denen eine Ressource im Verzeichnis nicht in irgendeiner Weise behandelt wird und Berechtigungen und Rollen Active Directory-Gruppen zugeordnet wurden.
Gibt es eine bessere Möglichkeit, diese Akteure zu repräsentieren? Wie wäre es mit einem Dokument über gute Abbildungen und Absichten des Schemas?
RBAC ist nicht RBAC ist nicht RBAC und RBAC auf Papier ist schwierig, aber fast unmöglich in einem realen Leben zu implementieren.
Jeder hat seine eigene "Idee" von RBAC und die meisten benutzen unterschiedliche Begriffe für alles, was mit RBAC zusammenhängt. Im Allgemeinen haben Sie aus Sicht der LDAP-Implementierung selten alle "Teile", um eine korrekte Implementierung in LDAP durchzuführen.
Die "Teile Teile" in einfachen Worten sind:
S = Betreff = Eine Person oder ein automatisierter Agent oder Benutzer
P = Berechtigungen = Eine Genehmigung eines Zugriffsmodus auf eine Zielressource
T = Zielressourcen = Das Objekt, dem Sie Berechtigungen zuweisen möchten
Die Rolle muss mindestens eine Berechtigung und einen Benutzer zuordnen. Die Zielressource könnte vollständig außerhalb von LDAP liegen. Es könnte also eine Anwendung auf einem Tomcat-Server oder einfach das Recht sein, "andere" Einträge innerhalb des LDAP-Servers zu lesen.
Das Beste, was Sie in LDAP tun können, ist also, ein Objekt mit einer Liste von Benutzern einzurichten, und wenn einige Ressourcen innerhalb von LDAP vorhanden sind, müssen Sie die entsprechenden Verzeichnisberechtigungen für diese Zielressourcen festlegen.
Dann gibt es die kleine Problemumsetzung.
Wir brauchen jetzt eine Richtlinie für die Umsetzung unserer Rolle. Also unsere Rolle, wir nennen sie USER-READ-ONLY, ist ohne eine Richtlinie, wie sie verwendet werden soll, nicht sinnvoll.
In unserem Fall könnten wir einfach sagen, dass die Rolle USER-READ-ONLY alles in unserer Organisation lesen kann.
Wir haben jetzt eine Richtlinie. Wo wird diese Richtlinie gespeichert? Die digitale Darstellung einer Richtlinie wird im "Policy Information Point" oder PIP gespeichert.
Wie interpretieren wir die aus dem PIP bereitgestellten Richtlinien? Richtlinien werden vom Policy Decision Point (PDP) interpretiert.
Wer entscheidet, ob ein Subjekt (Benutzer) auf eine Ressource zugreifen kann? Die Richtliniendurchsetzungspunkte (PEP).
Wenn wir all diese Policy-Elemente zusammenfügen, endet die digitale Darstellung der Policy durch den Policy Information Point zum Policy Decision Point, der die Entscheidung an den Policy Enforcement Point weiterleitet, wo der Zugang erlaubt oder verweigert wird / p>
Also in unserer RBAC Geschichte, wo ist der PIP, der PDP und der PEP? Nun, wenn sich die Zielressource im LDAP-Verzeichnis befindet, dann ist es das LDAP-Verzeichnis, das PIP (das wir wahrscheinlich fest codierten und nicht abstrahierten, das PIP ebenso und das PEP auch, und das war einfach.
Aber wenn es unsere Tomcat-Anwendung ist, MUSS es eine Methode innerhalb der Tomcat-Anwendung sein, die Interrupt-Kennungen eine Methode verwenden müssen, um zu sagen: "Ich habe dieses Subjekt (Benutzer) und er möchte Zugriff auf diese Ziel-Ressource (Inventar) Führen Sie diese Berechtigung (READ-ONLY) aus. "
Sicher gibt es einige Standards für all diese Sachen. (Google XAML, RFC3198, ISO10181-3, NIST), aber sie sind Standards mit großen Lücken für praktische Implementierungen.
Denken Sie daran, REAL-Implementierungen von RBAC sind schwierig.
Sicher IMHO, sollten wir über RBAC wissen, die Papiere studieren und es zu einer strategischen Richtung machen, aber die reale Implementierung über eine breite Basis von Anbietern und Anwendungen, nun, wir sind einfach noch nicht da.
-jim
Sehen Sie sich Fortress an, eine echte Open-Source-Implementierung von ANSI RBAC (INCITS 359), die LDAP verwendet. Ссылка
und ja, es war ziemlich schwierig zu implementieren, aber wir arbeiten seit über 10 Jahren an diesem Problem. ; -)