Auf den ersten Blick sieht das ganze sehr ähnlich wie Benutzergruppen aus, und hat einfach nur einen neuen Namen bekommen. In vielen System wird es auch genau so gehandhabt, die eigentliche Idee hinter einer Rollenbasierten Zugriffssteuerung ist jedoch grundlegend anders als das Konzept der Benutzergruppen. Was ist also der Unterscheid zwischen einer Gruppe und einer Rolle?

Wenn Benutzergruppen verwendet werden, gehört ein Benutzer einer oder mehreren Gruppen an und diesen Gruppen werden wiederum Rechte zugeordnet. Der Benutzer selbst kann dabei auch Rechte zugeordnet bekommen. Bei der Rechteprüfung spielt es dann keine Rolle mehr ob das Recht dem Benutzer zugeordnet wurde oder ob es über die Gruppe kam. Wenn eine Gruppe die Datei wichtig.txt lesen und ändern darf, kann der Benutzer entweder dieser Gruppe angehören um das Recht zu bekommen, oder das Recht wird dem Benutzer direkt zugewiesen. Das Ergebnis ist identisch, sodass Gruppen lediglich ein Hilfsmittel bei der Systemadministration sind. In dem Diagramm wird nochmal der Zusammehang zwischen Benutzern, Gruppen und Rechten verdeutlicht:

Soviel zu den Gruppen, aber was sind jetzt Rollen? Der Begriff stammt aus einem Paper von David Ferraiolo und Richard Kuhn zu der Computer Security Conference 1992. Mittlerweile ist daraus sogar der NIST-Standard “Role-Based Access Control” (RBAC) geworden. Das Proposal dafür “The NIST Model for Role-Based Access Control” stammt von Ravi Sandhu, David Ferraiolo und Richard Kuhn. Einige Dinge werden dadurch schon klarer

1. Rollenbasierten Zugriff gibt es nicht erst seit gestern
2. Was es bedeutet ist sogar standardisiert

Der Begriff Rolle wird in der Informatik und in vielen Produkten jedoch sehr inflationär verwendet, sodass in vielen Projekte eine Rolle tatsächlich nur einer Gruppe entspricht. Man hat sich einfach angewöhnt zu Gruppen jetzt Rollen zu sagen, aber was besagt denn jetzt die aufgeführte Literatur?

Die Autoren sind der Meinung das eine Rolle einer tatsächlich Funktion entspricht, das heißt z.B. Kassierer, Revisor, Kunde. Die Rolle entspricht also im Idealfall der tatsächlichen Rolle des Benutzers (im echten Leben). Das ist hauptsächlich ideologisch zu betrachten, da eine Gruppe genauso dazu benutzt werden könnte und oft auch so benutzt wird.

Ein großer Unterschied zu Gruppen ist jedoch, dass jetzt nur noch der Rolle Rechte zugewiesen werden, und dem Benutzer nur noch Rollen. Eine Zuweisung von Rechten an der Rolle vorbei ist nicht möglich. Das Diagramm dazu würde so aussehen:

Zu der Rechtezuweisung werde ich in Teil 2 noch detaillierter kommen, aber vorher stellt sich noch die Frage ob dieses Modell tatsächlich ausreicht. In vielen Fällen ist es nicht der Fall, da es Rollen gibt, welche eine Person nicht gemeinsam haben darf. Beispielsweise darf ein Kassierer nicht gleichzeitig Revisor und Kunde sein. Dieses Problems nimmt sich RBAC ebenfalls an, indem es Möglichkeiten für die “Seperation of Duty” schafft. Die einfachste und strikteste Form davon ist, dass ein Benutzer nur eine Rolle haben darf, welches ein spezieller Fall der “Static Separation of Duty” (SSD) ist. Bei SSD können aber auch Beschränkungen definiert werden, welche Rollen nicht gemeinsam zugewiesen werden dürfen, und welche schon, was oft praxistauglicher ist. Wer an dem Konzept von einer Rolle pro Benutzer festhalten will kann aber auch für den Fall dass ein Benutzer tatsächlich zwei Rollen haben muss, z.B. Kassierer und Lagerarbeiter eine eigene Rolle dafür definieren, welche die anderen beiden enthält:

Im Gegensatz zum Static Separation of Duty, bei dem schon bei der Zuweisung entschieden wird welche Rollenkombination zulässig ist, gibt es das Dynamic Separation of Duty. Hier können beliebige (statische) Rollenzuweisungen vorgenommen werden, bei der Ausführung wird dann eine Sitzung erzeugt, welche nur eine Untermenge der zugeordneten Rollen enthält. Der Benutzer muss sich also für die derzeitig ausgeübte Rolle entscheiden. Er kann nicht Kassierer und Kunde gleichzeitig sein, sondern muss sich für eine von beiden entscheiden. Dadurch ist es möglich dass er unter Tags Kassierer ist und Abends als Kunde bei seinem Arbeitgeber einkauft. Es wurde also noch eine weitere Komponente eingefügt: Die Sitzung (Session).


Jetzt sollte deutlich geworden sein, dass ein RBAC deutlich mehr ist als nur reine Benutzergruppen. Trotzdem gibt es auch bei RBAC-System durchaus Benutzergruppen, und zwar dann wenn mehrere Benutzer immer die gleichen Rollen haben, aber dafür aus bestimmten Gründe keine eigene Rolle definiert werden soll/darf. Hier wäre dann die Vollausbaustufe:

Zu diesem Modell gibt es auch ein Software Design Pattern mit dem Namen “Role-Based Access Control” aus dem Buch Security Patterns von M. Schumacher, E. Fernandez-Buglioni, D. Hybertson, F. Buschmann, P. Sommerlad.
Was sind jetzt also die großen Unterschiede zwischen Rollen und Gruppen:

1. Gruppen sind ein admistratives Hilfsmitteln, Rollen orientieren sich dagegen an fachlichen Funktionen
2. Rollen befassen sich mit Interessenkonflikten (Separation of Duty). Entweder statisch oder dynamisch mit Hilfe einer Sitzung.
3. Benutzer bekommen nur Rechte über die Rolle und keine direkten Rechte mehr.

Role-Based Access Control ist jedoch nur ein Teil wenn von Rollen spricht, ein wichtiger weiterer Teil ist die Role Rights Definition, also um die Zuweisung der Rechte zur Rolle, um die es im zweiten Teil geht.