Implementierung von RBAC-Modellen mit LDAP-Directories

Sowohl RBAC als auch LDAP haben sich auf getrennten Wegen im letzten Jahrzehnt auf unauffällige aber effiziente Weise durchgesetzt. Eine Kombination beider Technologien verspricht ausgezeichnete Kosten/Nutzen-Relationen für die Sicherheitsadministration.

Das Potential der Kombination von RBAC und LDAP wird man nur heben können, wenn man auf die Besonderheiten beider Technologien eingeht. Erst dann kann man erreichen, dass sich die Vorteile beider wirkungsvoll ergänzen. Leider sind die gängigen Implementierungsmethoden in beiden Gebieten dazu nicht gut geeignet, wie wir zeigen werden.

Wir wollen die Lücke ausfüllen, die zwischen der eher akademischen Diskussion von RBAC und den praktischen Erfordernissen von LDAP besteht. Die Details unserer Architektur werden wir ausführlich in einem künftigen White Paper darstellen. Hier auf der Website geben wir nur eine Zusammenfassung der wesentlichen Punkte.

Typisches Problem des RBAC-Implementierungswegs

RBAC-Modelle können LDAP-Directories zur Ablage der Zugriffsdaten verwenden, im selben Sinne wie sie auch z.B. eine relationale Datenbank nutzen können. Im Regelfall werden dazu eigene Schemata definiert, die nicht einem RFC oder einem Industriestandard entsprechen. Für den Zugriff auf die Daten muß in der Regel eigenständiger Code entwickelt werden, der als Konsequenz in der akademischen Diskussion leichthin in Kauf genommen wird. In der Praxis der Unternehmens-IT ist das aber ein sehr schwer wiegendes Problem: Proprietärer Code ist kostspielig in Support und Wartung und muss soweit als möglich vermieden werden.

Wir können zeigen, dass sich unser vorgeschlagenes Modell mit Standard-Modulen aus dem Lieferumfang des BEA WebLogic Servers [WebLogic] umsetzen lässt, der vielfach als der Marktführer der Java-Applikationsserver angesehen wird.

Typisches Problem des LDAP-Implementierungswegs

Um die Administration von großen LDAP-Directories zu bewältigen, werden normalerweise Identity Management Systeme verwendet. Wenn man in LDAP den üblichen Realisierungsweg wählt, werden Directories mit vielfach redundanten Datenmengen belastet, die in großen Installationen den Betrieb des Systems insgesamt in Frage stellen.

Wie wir darstellen werden, kann eine optimierte Implementierung von RBAC diese Probleme vermeiden und zu kompakten und leistungsfähigen Autorisierungsdiensten führen. Die Pflege der Autorisierungsdaten kann durch Standardsoftware durchgeführt werden. Wir haben eine Implementierung mit beta systems SAM durchgeführt, die eines der bekannteren Produkte zur Administration von RBAC-Modellen ist [SAM].

Role Based Access Control (RBAC)

Role Based Access Control (RBAC) ist eine Methodik zur Zugriffskontrolle, die generell folgendermaßen funktioniert:

• Personen werden Rollen zugeordnet (User Assignment)
• Rollen werden Berechtigungen zugeordnet (Permission Assignment)
• Berechtigungen beschreiben, welche Operationen auf Objekten möglich sind.

Der Vorteil von RBAC gegenüber der direkten Vergabe von Berechtigungen an Personen liegt in der einfacheren Implementierung von Geschäftsregeln und der besseren Skalierbarkeit in großen Organisationen. Mit RBAC lassen sich mit vertretbaren Aufwand viele tausend Benutzer administrieren, wobei jeder Benutzer wiederum einige hundert Berechtigungen auf Ressourcen haben kann. Wollte man die Berechtigungen individuell an jeden Benutzer vergeben, müssten insgesamt einige hunderttausend Zuweisungen administriert werden. Mit RBAC wären in diesem Szenario nur insgesamt einige tausend Zuweisungen von Rechten an Rollen und Rollen an Personen durchzuführen.

Der Begriff RBAC wurde 1992 in dem Paper "Role-Based Access Control" von David Ferraiolo und Richard Kuhn formalisiert. Mittlerweile gibt es einen RBAC-ANSI-Standard in der Draft-Version, in dem die wesentlichen Details einer RBAC-Implementation beschrieben sind.

Das amerikanische National Institute of Standards and Technology hat eine Sammlung von weiteren Informationen zu RBAC auf der Website http://csrc.nist.gov/rbac/ veröffentlicht.

LDAP-Directories

LDAP-Directories werden seit einigen Jahren in Organisationen eingesetzt und können als erprobte Technik gelten. Das Zugriffsprotokoll LDAP wurde in mehreren RFCs definiert, ebenso wie nützliche Objektklassen und Attribute. Aktuell ist die Version 3 (LDAPv3), die auch von nahezu allen Produkten unterstützt wird. Der große Fortschritt von LDAP liegt in der Interoperabilität zwischen unterschiedlichsten Herstellern. Man kann heute davon ausgehen, dass LDAP-Clients und LDAP-Server weitgehend kompatibel sind.

Viele Directories basieren auf der ursprünglichen Implementierung der University of Michigan, die in OpenLDAP als Open Source weitergeführt wird. Kommerzielle Implementierungen kommen von Novell, Sun (vormals Netscape), Siemens, Microsoft und weiteren. Die Auswahl ist groß und weil die Funktionalitäten der Produkte im Kern gleich sind, kann man sich bei der Entscheidung für ein Produkt vor allem von nicht-funktionalen Kriterien leiten lassen.

Directory Designs

Die Ursprünge der LDAP-Directories liegen in X.500-Verzeichnissen und deswegen orientieren sich die üblichen Designs an der Ablösung der papiergebundenen Telefonbücher durch ein Directory Server-System. Der Fokus dieser Designs liegt auf der direkten Verwendung durch Benutzer, die für ihre Büroarbeit Informationen zu Personen benötigen:

• Name: Vorname, Nachname, Titel
• Anschrift: Büro, Strasse, Postleitzahl, Stadt, Land
• Telefonnummer, Faxnummer, Email-Adresse

Die allermeisten Anleitungen zum Directory Design gestalten das Directory ausgehend von diesem Verständnis, so auch das Standardwerk für LDAP-Directories [Understanding]. Authentisierung ist in diesem Kontext ein Randthema und Autorisierung wird typischerweise nur in Bezug auf Directory-Daten behandelt.

Access Management mit Gruppen

Mit ihrer guten Performance bei Lesevorgängen bieten sich Directory Server als Plattform für Authentisierung und Autorisierung an. Sobald eine Software die Authentisierung und Autorisierung eines Benutzers benötigen würde, würde sie sich mit einem zentralen Directory-Server verbinden und die Daten von dort schnell abfragen können. Damit die Zugriffssteuerung über ein LDAP-Directory abgewickelt werden kann, müssen zusätzlich folgende Daten im Directory gespeichert werden:

• Passwort zur Authentisierung (sicher gespeichert)
• Gruppen zur Autorisierung (Typ groupOfUniqueNames oder groupOfUrls)

Gruppen werden in LDAP-Directories häufig als Objekte des Typs groupOfUniqueNames dargestellt, in dessen Attribut uniqueMember eine Liste mit den Namen aller Mitglieder abgespeichert ist. Jede Gruppe entspricht einer Berechtigung und jedes Mitglied dieser Gruppe hat diese Berechtigung.

Als weitere Möglichkeit kann man Berechtigungen auch mit dem Typ groupOfUrls darstellen, bei dem die Zugehörigkeit zur Gruppe in einem Attribut des Gruppenmitglieds verzeichnet wird. Die groupOfUrls ist skalierbar in der Mitgliederanzahl, benötigt aber für Auflistung der Mitglieder einen LDAP-Suche. Die groupOfUrls ist durch den Netscape Directory Server zum Industriestandard geworden, aber bislang nicht in einem RFC festgelegt worden.

Darstellung von Berechtigungen in einem LDAP-Directory

Objekt	LDAP-Objekttypen
User	inetOrgPerson
Berechtigung	groupOfUniqueNames bzw. groupOfUrls

 

RBAC und Directories

Das beschriebene Modell ist zwar einfach, stellt aber kein RBAC-Modell dar und wird aus den schon dargestellten Gründen in der Praxis schwer zu administrieren sein.

RBAC Modelle lassen sich in LDAP abbilden, indem für jeden User alle Berechtigungen gesammelt werden, die er aufgrund seiner Rollen bekommen hat. Die Rollen selber bleiben abstrakte Konstrukte in der Administrationssoftware. Sie werden nicht direkt im Directory abgebildet, obwohl sie natürlich implizit in den Daten vorhanden sind. Diese Strategie wird von den meisten Programmen zur Sicherheitsadministrationen in Konzernen angewendet.

Darstellung von RBAC mit impliziten Rollen in einem LDAP-Directory

RBAC-Objekt	LDAP-Objekttypen (implizite Rollen)
User	inetOrgPerson
Rolle
Berechtigung	groupOfUniqueNames bzw. groupOfUrls

Probleme mit impliziten Rollen

Die RBAC-Werkzeuge machen die Administration der Datenmengen möglich, aber die Gesamtzahl der Berechtigungsdaten wird durch die Einführung von RBAC nicht reduziert. Ganz im Gegenteil, indem die Administration durch RBAC effizienter wird, werden immer größere Datenmengen von den RBAC-Werkzeugen in die Endsysteme geschrieben. Von diesem Effekt, den wir "RBAC bloat" nennen, sind nicht nur LDAP-Directories betroffen. Auch bereits seit langem etablierte Autorisierungssysteme (wie z.B. RACF) können von RBAC-Werkzeugen an die Grenzen ihrer Leistungsfähigkeit getrieben werden.

Die Auswirkungen kann man sehen, wenn wir ein einfaches Rechenbeispiel für ein Directory mit 100.000 Usern wählen. In diesem Directory soll es etwa 1.000 Rollen geben und jeder Person wird genau eine Rolle zugewiesen. Jede Rolle soll etwa 1.000 Berechtigungen beinhalten. Weil Rollen im Directory nicht repräsentiert sind, müssen die Zuordnungen von Rolle zu Benutzer übersetzt werden. Jedem Benutzer wird eine Rolle zugewiesen und die darin enthaltenen 1.000 Berechtigungen zugewiesen, in Summe sind das 100.000 x 1.000 Berechtigungen.

Um die Rechnung weiter zu konkretisieren und zu vereinfachen, gehen wir davon aus, dass jedes Objekt im Directory 1 KByte benötigt und jede Mitgliedschaft 100 Byte. Wenn wir die resultierende Datenmenge im Directory berechnen kommen wir mit den angegebenen Zahlen auf ein Volumen von 10 GByte Berechtigungsdaten in einer Konzern-Installation.

Objekt	Modell	Datenmenge pro Objekt	Konzern-Installation
			Anzahl	Datenmenge gesamt
User	100.000	1.000 Byte	100.000	100 MByte
Rollenzuordnungen	1 pro User			0 MByte
Rollen	1.000			0 MByte
Berechtigungszuordnungen	1000 pro Rolle			0 MByte
Berechtigungen	100.000	1.000 Byte	100.000	100 MByte
Berechtigungszuordnungen		100 Byte	100.000.000	10.000 MByte
Gesamt				10.100 MByte

Die Datenmenge ist zu speichern und performant zur Abfrage vorrätig zu halten. Um die Konsistenz mit der Datenbasis des RBAC-Werkzeugs zu gewährleisten, muss täglich der gesamte Datenbestand des Directories gelesen und überprüft werden. Alle Änderungen bringen große Last in das System ein, weil eine Änderung der Rollenzuordnung eines Users in Folge 1000 Änderungen im Directory mit sich bringen würde, multipliziert mit der Anzahl der versorgten Replikas. Diesen Datenmengen und Transaktionslasten sind die heutigen RBAC-Werkzeuge und Directories nicht gewachsen. Noch katastophaler würde das Bild aussehen, wenn man RBAC auf große Extranet-Installationen mit Millionen von Benutzern anwenden möchte.

Indem man die Zuordnungen von User zu Rollen und Rollen zu Berechtigungen im Directory auflöst, erzeugt man höchst redundante Daten im Directory. Durchschnittlich werden 100 User jeweils die identischen 1.000 Berechtigungen haben, d.h. in 1.000 Objekten vom Typ groupOfUniqueNames befinden sich jeweils die gleichen 100 User. Dieses hohe Maß an Redundanz ist unnötig und bringt die eben erwähnten negativen Konsequenzen mit sich.

RBAC mit sichtbaren Rollen im Directory

Die Redundanz kann vermieden werden, indem die Rollen selber im Directory als Gruppen repräsentiert werden. LDAP erlaubt die Verschachtelung von Gruppen, so dass die Rollen-Gruppen selber Mitglieder in den Berechtigungsgruppen werden können.

Darstellung von RBAC mit sichtbaren Rollen in einem LDAP-Directory

RBAC-Objekt	LDAP-Objekttypen (sichtbare Rollen)
User	inetOrgPerson
Rolle	groupOfUrls bzw. groupOfUniqueNames
Berechtigung	groupOfUniqueNames

In diesem Fall reduziert sich die Datenmenge ganz erheblich auf einige hundert MByte, die ohne Probleme zu verwalten wären.

Objekt	Modell	Datenmenge pro Objekt	Konzern-Installation
			Anzahl	Datenmenge gesamt
User	100.000	1.000 Byte	100.000	100 MByte
Rollenzuordnungen	1 pro User	100 Byte	100.000	10 MByte
Rollen	1.000	1.000 Byte	1.000	1 MByte
Berechtigungszuordnungen	1000 pro Rolle	100 Byte	1.000.000	100 MByte
Berechtigungen	100.000	1.000 Byte	10.000	10 MByte
Gesamtanzahlen				221 MByte

Der Preis für die effiziente Datenhaltung wird durch einen weiteren Zugriff auf das Directory bezahlt. Dieser kostet Zeit und wird derzeit nicht von allen Client-Applikationen implementiert. Der LDAP-Authentisierungsrealm des BEA WebLogic kann so konfiguriert werden, dass er die Rollen auswerten kann. Alternativ bleibt immer noch der Weg zu einer eigenen Implementierung, mit dem Nachteil des Supports und der Wartung.

Rekursionstiefe der geschachtelten Struktur

LDAP erlaubt die beliebige Schachtelung von Gruppen in Gruppen. Zur Implementierung von RBAC genügt eine einfache Schachtelung, d.h. eine Rekursionstiefe von 2. Man könnte damit auch hierarchische Strukturen von beliebiger Tiefe abbilden, so auch hierarchische RBAC-Modelle (HRBAC), die sich häufig am Organisationsdiagramm eines Konzerns orientieren.

Eine größere Verschachtelungstiefe als 2 ist aber aus folgendem Grund unerwünscht:Wenn eine rekursive Suche nach Gruppen durchgeführt werden soll, muss für jedes gefundene Gruppenobjekt festgestellt werden, ob es selber wiederum Mitglied in einer Gruppe ist. In unserem Rechenbeispiel würde das bedeuten, dass mit 2 Aufrufen schon 1000 Gruppen gefunden würden, in denen ein User Mitglied ist. Um wirklich sicher zu sein, alle Mitgliedschaften erfasst zu haben, müssten alle 1000 Gruppen einzeln überprüft werden, ob sie Mitglieder in einer weiteren Gruppe sind. In Summe müssten insgesamt 1002 Abfragen durchgeführt werden, während bei künstlicher Begrenzung der Rekursionstiefe nur genau 2 Abfragen benötigt werden.

Um nicht in dieses Dilemma zu kommen, würde ich empfehlen, ein hierarchisches RBAC-Modell nicht mit hierarchisch verschachtelten LDAP-Gruppen darzustellen. Stattdessen würde ich die Hierarchie durch das RBAC-Administrationssystem auflösen lassen und die resultierenden Berechtigungen den Rollen zuweisen. Mit dieser Strategie würde zwar ein gewisses Maß an Redundanz im Directory entstehen, die sich aber in diesem Fall auf die Anzahl der Rollen bezieht. Weil die Anzahl der Rollen typischerweise deutlich kleiner ist als die Anzahl der User, in unserem Szenario um den Faktor 100 kleiner, würden die Datenmengen im Directory nur unwesentlich anwachsen und würden auch keine negativen Auswirkungen mit sich bringen.

Fazit

Wenn ein RBAC-Modell in einem LDAP-Directory abgebildet wird, sollten die Rollen stets im Directory repräsentiert werden, um das unkontrollierte Anwachsen der Directory Datenbank zu vermeiden. Indem verschachtelte LDAP-Gruppen verwendet werden, kann die Zuordnung der Berechtigungen zu Rollen abgebildet werden, wobei die Verschachtelungstiefe genau 2 betragen sollte. Die Implementierungsrisiken dieses Vorgehens bleiben straff kontrollierbar, weil Standardsoftware eingesetzt werden kann: Gängige RBAC-Werkzeuge können das Design unterstützen, ebenso wie moderne Authentisierungsframeworks es nutzen können.

Quellen

	Role-Based Access Control von David F. Ferraiolo, Ramaswamy Chandramouli, D. Richard Kuhn (in englischer Sprache) Zusammenfassung zahlreicher Themen zu RBAC von den Autoren des ursprünglichen Artikels zu RBAC. Jetzt bestellen
	Understanding and Deploying LDAP Directory Services von Timothy A. Howes , Mark C. Smith und Gordon S. Good Eine gute Beschreibung des Standarddesigns von Directories als Telefonbuchersatz ist mittlerweile in der zweiten Auflage erschienen. Für Access Management weniger geeignet. Die erste Auflage hatte noch ein anderes Cover und war bei einem anderen Verlag erschienen. Jetzt bestellen
[hyperDRIVE]	"hyperDRIVE: Leveraging LDAP to implement RBAC on the Web", Larry S. Bartz, Proceedings of the second ACM workshop on Role-based access control, pp. 69 - 74 Download
	Ein Implementierungsbeispiel aus der Sicht von RBAC, wobei als Datenbasis LDAP verwendet wird. Zentrales Thema ist die Objekt-Modellierung der RBAC-Funktionalität und die Implementierung mit einem Java-Applet. Zwar entsprechen die wesentlichen Attribute des Datenmodells unserem favorisierten Vorschlag, unterscheiden sich aber durch die Abhängigkeit von proprietären Programmierung.
[RBACWeb]	"Role-Based Access Control on the Web" , Joon Park, Ravi Sandhu and Gail-Joon Ahn, ACM Transactions on Information and Systems Security (TISSEC), Volume 4, Number 1, February 2001; http://www.list.gmu.edu/journals/tissec/p37-park.pdf "Role-based access control on the web using LDAP" von Joon S. Park, Gail-Joon Ahn, Ravi Sandhu in Proceedings of the fifteenth annual working conference on Database and application security, Niagara, Ontario, Canada, pp. 19 - 30; http://www.list.gmu.edu/confrnc/ifip/i01-kluwer01-jpark.pdf
	Es werden Implementierungsalternativen User-Pull und Server-Pull vorgestellt und deren jeweilige Vor- und Nachteile untersucht. Es gibt nahezu keinen Bezug zu der hier vorgestellten Arbeit mit Ausnahme des gleichzeitigen Vorkommens der Worte RBAC und LDAP.
[SAM]	Enterprise Role Administration: An administration concept for the enterprise role-based access control model Axel Kern, Andreas Schaad, Jonathan Moffett, June 2003, Proceedings of the eighth ACM symposium on Access control models and technologies
[WebLogic]	http://www.bea.com