Rollen sind keine Gruppen

Wenn man sich heutzutage mit Security beschäftigt, im speziellen mit Rechteprüfung, Identity Management (IDM), etc. wird man sehr schnell auf den Begriff Rollen stoßen. Sei es dass man bei Spring Security (Acegi) eine Methode nur mit einer bestimmten Rollen ausführen darf oder auch dass man Benutzern im IDM Rollen zuweisen kann.

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:

gruppen.png
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:

rollen_1.png

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:

rollen_2.png
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).

rollen_3.png
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:

rollen_4.png

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.

15 thoughts on “Rollen sind keine Gruppen

  1. Pingback: Security Anforderungen 2.0: Gruppen, Rollen, Flexibilität | pgt / adminSight

  2. Papick G. Taboada

    Schöne Ausarbeitung. Was ist aber wenn ich meine Rollen zur Laufzeit ändern muss (wie in Jira, jedes Projekt hat verschiedene Benutzer in den verschiedenen Rollen)?

    Spring Security ist da Flexibler als JAAS, ich darf die API und AOP benutzen um es selber zu implementieren. Gibt es fertige Beispiele für solche Anwendungsfälle?

    Reply
  3. Erich Eichinger

    Tut gut, es wieder einmal schwarz auf weiss zu lesen. Im Alltagssprachgebrauch besteht ja leider die starke Tendenz, die beiden Begriffe zu vermischen.
    Für mich stehen Rollen und Akteure in Use-Cases in einem engen Zusammenhang. Im Prinzip stellt jeder (abstrakte) Akteur eines UC die Rolle dar, die ein konkreter Benutzer (oder eine andere Applikation – der Benutzer muss ja nicht menschlich sein) bei der Durchführung dieses UC einnimmt. Das ein Benutzer im Laufe der Zeit unterschiedliche Rollen einnehmen können muss, ist also abhängig von den identifizierten UC. Das Konzept sieht nach meinem Verständnis lediglich vor, dass ein Benutzer nicht 2 Rollen *gleichzeitig* einnehmen kann.

    Reply
  4. Norbert Hölsken

    Sehr guter Artikel. Vielen Dank! Gibt es den erwähnten zweiten Teil schon bei dem es um die Rechtezuweisung gehen soll?

    Reply
    1. Mike

      Nach längerer “Blog-Pause” werde ich jetzt wieder anfangen öfter etwas zu schreiben, unter anderem auch den erwähnten zweiten Teil.

      Reply
  5. Pingback: Berechtigungssystem für Webseite ? Wie aufbauen ? - php.de

  6. Pingback: Security Anforderungen 2.0: Gruppen, Rollen, Flexibilität | pgt

  7. nikosch

    Toller Artikel! Mehr davon!
    Mich stören allerdings die diversen Zeichensatzfehler. Kann man da was machen?

    Reply
  8. Pingback: Hierarchisches Rechtesystem - php.de

  9. Pingback: Rechtesystem mit Rollen oder Gruppen « www.CodeVortex.de

  10. FlamingMoe

    Sehr gut und nachvollziehbar.

    Wie verhält es sich, wenn neben Rollen (reale Funktion) auch noch reale Gruppen (bspw. Abteilungen) ins Spiel kommen? Wie ist bspw. abgedeckt, dass der Abteilungsleiter (Rolle), in seiner Abteilung Lese/Schreibrechte hat, in anderen Abteilungen jedoch nur Leserechte. Der einfache Mitarbeiter (Rolle) hingegen in seiner Abteilung Leserechte und in anderen Abteilungen keine Rechte haben soll?

    Kommt da die “Gruppe” als Abteilung wieder ins Spiel oder ist das ein gänzlich anderes, zusätzliches Konstrukt?

    Vielen Dank

    Reply
  11. Pingback: Rechtesystem: Rollen vs Gruppen - php.de

Leave a Reply to Papick G. Taboada Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>