© aragami12345, 123RF

LDAP kann sich nicht nur Name und Passwort merken, sondern dank neuer Schemata auch alle Zusatzinformationen, die eine rollenbasierte Zugriffskontrolle braucht.

LDAP gibt es seit 1993 als RFC und auch in Zukunft wird es eine Rolle spielen: In der Cloud taucht es als Cloud Directory, Directory as a Service oder Identity Management as a Service auf. Auch im kommenden Internet of Things, wo es nicht um menschliche Identitäten geht, sondern um im Netz agierende Dinge wie Kühlschränke oder Verkehrsampeln, hat es seinen Platz.

Dabei stammen die Konzepte und das Datenmodell aus den 80er Jahren, als der Standard X.500 entwickelt wurde. LDAP, die Lightweight-Version von X.500, wurde in seiner jetzigen Version 3 bereits Ende der 90er Jahre von der IETF standardisiert.

Inzwischen hat sich LDAP insbesondere als Standard für die Accountverwaltung durchgesetzt, weil es eine Reihe ebenfalls standardisierter Authentifizierungsverfahren sowie standardisierte Schemata mitbringt, etwa für Personen, Accounts, Gruppen und Rollen. Auch Microsofts Verzeichnisdienst Active Directory nutzt LDAP. Immer wenn es um zentrale Authentifizierungs- und Autorisierungsdienste geht, also darum, Identitätsdaten zu verwalten (Identity Management), ist LDAP nach wie vor eine sehr beliebte Lösung.

Das objektorientierte LDAP-Datenmodell erlaubt es, neben den in RFCs standardisierten Schemata auch neue, eigene Schemata zu spezifizieren. Die Einsatzmöglichkeiten sind dadurch nahezu unbegrenzt. Dieser Artikel beschreibt eine neue Nutzungsmöglichkeit, nämlich die Speicherung von Zusatzinformationen, die aus einem LDAP-Server einen zentralen, externen Policy Decison Point (PDP) für die rollenbasierte Zugriffskontrolle zu beliebigen Ressourcen macht.

LDAP versus relationale Datenbanken

Zunächst ist es hilfreich, das LDAP-Modell kurz mit dem bekannteren relationalen Datenmodell zu vergleichen, um die Unterschiede und damit die LDAP-Eigenheiten deutlich zu machen (Tabelle 1). Als Fazit der Tabelle ist festzustellen, dass sich LDAP besonders durch eine größere Flexibilität gegenüber dem relationalen Modell auszeichnet.

Die bessere Anpassungsfähigkeit rührt daher, dass sich die Datenschemata für die Einträge durch Objektklassen definieren lassen, die beliebig zu kombinieren sind. Wer Attribute speichern möchte, die in den gegebenen Objektklassen fehlen, der nimmt einfach weitere Klassen hinzu, die die fraglichen Attribute ergänzen. Andere Teile der Datenstruktur ändern sich dadurch nicht, auch die Anwendungslogik wird nicht beeinträchtigt.

Zwei Kontrollverfahren: ABAC und RBAC

Generell wollen Eigentümer von Ressourcen in jeder IT-Umgebung bestimmen, wer darauf zugreifen darf und wer nicht. Dafür braucht es eine Authentifizierung, über die sich ein Benutzer ausweist. Die Zugriffsberechtigung leitet sich zumeist erst über weitere Merkmale ab. Grundsätzlich kann der Anwender zwischen RBAC (Role Based Access Control), also rollenbasierter Zugriffskontrolle, und ABAC (Attribute Based Access Control) unterscheiden.

Bei der letztgenannten bilden Regeln die Zugriffsentscheidungen, die Attribute sowohl des Benutzers als auch der in Frage stehenden Ressource beinhalten können. Eine solche Regel könnte lauten: “Alle Ressourcen, die unter der Sicherheitsstufe Stufe 1 eingruppiert sind, können Benutzer, die Berechtigung für Sicherheitsstufe 1 haben, lesend nutzen.” Mit XACML [1] steht ein zunehmend genutzter OASIS-Standard für die Formulierung solcher Regeln zur Verfügung. RBAC ist letztendlich eine Untermenge von ABAC, das die Regeln ausschließlich über Rollenmitgliedschaften des Benutzers bildet. Hierfür wurde der ANSI-Standard RBAC [2] spezifiziert.

Der RBAC-Standard

Wenn hier von einer Rolle die Rede ist, ist jene gemeint, die eine Person im Rahmen einer Organisation innehat, also etwa als Systemadministrator oder als Abteilungsleiter und so weiter. Implizit sind mit einer Rolle Berechtigungen verknüpft: Der Systemadministrator hat Rootrechte auf Servern, der Abteilungsleiter hat Zugriff auf Personalakten.

Der RBAC-Standard erlaubt es, solche Regeln explizit zu spezifizieren. Dabei kann ein Benutzer verschiedene Rollen haben und eine Ressource verschiedene Zugriffsrechte (etwa Lesen, Schreiben oder Ausführen) kennen. Diesen Zugriffsrechten lassen sich wiederum verschiedene Rollen zuweisen. Zum einen hat dies den Vorteil, dass man nicht jedem einzelnen Benutzer einzelne Rechte für einzelne Ressourcen zuweisen muss, zum anderen ermöglicht dies auch, die Regelwerke flexibel und dennoch konsistent zu ändern. Eine datenschutzrechtlich motivierte Änderung könnte etwa darin bestehen, den Abteilungsleitern den Zugriff auf die Personalakten wieder zu entziehen.

Zusätzlich zu den Begriffen Benutzer, Rolle, Ressource und Berechtigung kennt der RBAC-Standard den Begriff Session (Sitzung), als einen Mechanismus, der einem Benutzer, der ein zustandsloses Protokoll wie HTTP verwendet, dennoch Zustandsinformationen über eine Session-ID zuordnen kann.

In den meisten Fällen wird eine Session auf eine bestimmte Zeitspanne beschränkt, nach der die Session-ID ungültig wird und das System die gespeicherten Informationen löscht. Durch die Einführung des Sessionbegriffs ist es in RBAC möglich, dass eine Person, die mehrere Rollen besitzt, innerhalb einer Sitzung jeweils nur in einer der möglichen Rollen agiert (Abbildung 1).

Abbildung 1: Das RBAC-Grundmodell mit seinen Benutzern, Rollen und Sessions.

Kern und Erweiterungen

Der RBAC-Standard legt nicht nur diese Konzepte fest, sondern spezifiziert auch ein API, also die einzelnen für ein RBAC-System notwendigen Funktionen, etwa »assignUser« , oder »addRole« .

Der Standard unterteilt sich in die Bereiche “RBAC-Core” sowie die beidenErweiterungen “Hierarchical RBAC” und “Separation of Duty”.

• RBAC-Core enthält das bereits oben beschriebene Grundmodell.

*Hierarchical RBAC fügt nur die Eigenschaft hinzu, dass Rollen nicht nur einzeln nebeneinander existieren können, sondern Hierarchien formen, wobei zum Beispiel die Rolle Systemadministrator eine Unterrolle der Rolle Mitarbeiter ist (Abbildung 2). Dabei kann man unterscheiden zwischen “Limited Hierarchical RBAC”, wo die Hierarchien in einem gerichtetet Baum darstellbar sind, und “General Hierarchical RBAC”, wo die Relationen der Rollen beliebige Graphen bilden.

Abbildung 2: Hierarchical RBAC – hier existieren Rollen nicht nur nebeneinander, sondern in Hierarchien.

• Separation of Duty spezifiziert die gegenseitige Ausschließlichkeit von Rollen. So lässt sich etwa definieren, dass ein Benutzer nicht sowohl die Rolle “Antragsteller” als auch die Rolle “Genehmiger” innehaben darf. Gelten solche Regeln absolut, nennt sie der Standard “Static Separation of Duty” (SSD). Es ist aber auch möglich, die Ausschließlichkeit nur zeitlich begrenzt, etwa nur innerhalb einer Session festzulegen. Das heißt “Dynamic Separation of Duty” (DSD) (Abbildung 3).

Abbildung 3: Separation of Duty – hier wird festgelegt, wie Rollen sich gegenseitig ausschließen.

Ein RBAC-System gestattet, Rollen- und Rechte-Informationen zentral zu verwalten, sodass mehrere Anwendungen, die eine Zugriffsentscheidung letztlich durchsetzen müssen – also Policy Enforcement Point (PEP) sind –, solche Entscheidungen über ein zentral verwaltetes Entscheidungssystem beziehen, also über einen Policy Decision Point (PDP). Statt komplexe Regeln selbst zu implementieren, muss die Anwendung nur ein standardisiertes Abfrageprotokoll wie etwa das XACML SAML Profile [3] unterstützen.

Open RBAC

Im Rahmen einer von der Firma DAASI International betreuten Informatik-Diplomarbeit [4] entstand die stabile RBAC-PHP-Implementierung Open RBAC [5], die alle wichtigen im Standard spezifizierten Funktionen unterstützt. Alle anfallenden Daten zu Rollen, Benutzern, Sessions, Ressourcen und Rechten landen dabei in einem LDAP-Server. LDAP bot sich an dieser Stelle an, weil es als Speicher für Benutzer- und Rollenverwaltungen bereits etabliert ist. Als LDAP-Server kam die Open-Source-Software Open LDAP zum Einsatz.

Open RBAC erlaubt es, sowohl die im Standard spezifizierten Managementfunktionen als auch Zugriffsentscheidungen über verschiedene Protokolle abzufragen. Es implementiert sowohl den Basis-Standard (RBAC Core) als auch die Standarderweiterungen Limited Hierarchical RBAC sowie Static und Dynamic Separation of Duty. Da sich die Rollen-Hierarchie in der LDAP-Baumhierachie abbildet, wurde General Hierarchical RBAC nicht implementiert.

Abbildung 4 zeigt, wie ein Programmierer die Managementfunktionen sowohl über die Webservice-Protokolle SOAP und REST als auch direkt über PHP-Klassen ansprechen kann. Die Zugriffsentscheidungen lassen sich zusätzlich über das bereits oben erwähnte XACML-SAML-Protokoll sowie direkt über das sehr performante LDAP-Protokoll mittels eines LDAP-Filters abfragen. Open LDAP kann ohne große Schwierigkeiten Zigtausend solcher Abfragen pro Sekunde beantworten.

Abbildung 4: Architektur von Open RBAC.

Grundlage der Implementierung war die Spezifizierung eines LDAP-Schemas, das Objektklassen und deren Attribute für die folgenden Entitäten definiert:

*RBAC-Rolle,

*RBAC-Session,

*RBAC-Ressource, sowie für

*Separation of Duty RBAC-DSD und RBAC-SSD.

Die LDAP-Standard-Objektklasse »inetOrgPerson« bildet die Benutzer ab. Da Open RBAC die Informationen auf mehrere Teilbäume verteilt und für jeden Teilbaum auch einen eigenen LDAP-Server unterstützt, ist es möglich, die Benutzer weiterhin in einem bereits vorhandenen LDAP-Server zu verwalten.

Der erste Produktiveinsatz von Open RBAC erfolgte in einem vom Bundesministerium für Bildung und Forschung (BMBF) geförderten Projekt namens Textgrid (Abbildung 5, [6]). Das Projekt baute eine virtuelle Forschungsumgebung für Geisteswissenschaftler auf. In diesem Zusammenhang erwies sich der Webservice-Ansatz als eine sehr flexible Lösung. Funktionalitäten, die der RBAC-Standard dabei nicht abdeckte – etwa eine Massenabfrage von Rechten, wodurch sich Ergebnisse von Textgrid-Suchabfragen nach Benutzerrechten filtern lassen –, wurden über eigene Webservices implementiert, die ihrerseits wiederum die RBAC-Funktionen aufriefen.

Abbildung 5: Das Projekt “Textdatenbank und Wörterbuch des klassischen Maya” ist eines der Nutzerprojekte innerhalb von Textgrid.

Weitere RBAC-LDAP-Implementierungen

Später stellte sich heraus, dass Open RBAC nicht die einzige RBAC-Implementierung war, die LDAP als Datenspeicher verwendet. Das RBAC-Produkt Fortress [7], ursprünglich entwickelt von Joshuatree Software, setzte ebenfalls LDAP und Open LDAP ein. Die beiden Entwickler setzten sich zusammen und arbeiteten an einem gemeinsamen Standardschema. Parallel dazu übernahm Symas Joshuatree Software, sodass die Kooperation nun zwischen Symas und DAASI International stattfindet.

Mittlerweile wurde bei Symas das Open-LDAP-Overlay RBAC Accelerator entwickelt [8], das die für RBAC Zugriffsentscheidungen notwendigen Operationen (»create session« , »check access« , »add active role« und so weiter) als LDAPv3 Extended Operations im LDAP-Server selbst implementiert. Hierdurch bleibt die hohe Performance der Zugriffsanfragen erhalten.

Ein Vorteil gegenüber der Open-RBAC-Lösung ist, dass die Anwendung nicht mehr mit Kenntnis des LDAP-Schemas für RBAC einen eigenen LDAP-Filter konstruieren, sondern nur die entsprechenden LDAP Extended Operations implementieren muss. Hierdurch wurde die Standardisierung des Schemas nicht mehr zwingend notwendig, weshalb auch die Arbeiten daran vorerst nur mit etwas geringerer Priorität weitergehen.