Category Archives: Security

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.

Das Jahr startet mit Security…

… und zwar mit den Web Sec Days die dieses Jahr zum ersten Mal in Frankfurt (besser gesagt in Mörfelden bei Frankfurt) statt finden werden.

Wie der Titel bereits vermuten lässt geht es hier gezielt um Web Application Security. Dabei werden verschiedenen Technologien, allgemeine Herausforderungen aber auch rechtliche Sachen beleuchtet. Alles in allem sieht es nach einem ganz guten Ãœberblick zu dem Thema aus.

Ich selbst werde eine Session zum Thema Security Patterns in Java halten, bei der es dann darum geht wie mit aktuellen Technologien die wichtigsten Security Patterns in Java relativ einfach umgesetzt werden können.

Kerberos Vortrag auf dem Linux Tag 2007

Hier nun die Folien zum Vortrag “Kerberos als Unternehmsweites Single-Sign-On” auf dem Linux Tag 2007. Bei diesem Vortrag geht es um die Einsatzgebiete in Unternehmen und Organisation und die Vor- und Nachteile. Das erwähnte Buch findet sich hier, und das Paper im PDF-Format hier.

Ein Vortrag über die technischen Details von Kerberos mit einigen How-Tos befindet sich darunter.

Kerberos im Detail:

Auf nach Berlin!

Letztes Jahr war bei mir, abgesehen von der Froscon, bei den Linux-Konferenzen erst mal Pause angesagt, deswegen freu ich mich umso mehr dieses Jahr wieder beim Linux Tag dabei zu sein. Wer es noch nicht mitbekommen hat: Der Linux Tag findet dieses Jahr in Berlin statt, was ich persönlich sehr angenehm find, da mir Berlin sehr gefällt und ich in Wiesbaden in den Rhein-Main-Hallen (wo er letztes Jahr war) sowieso schon bei der JAX immer bin. Naja, auf jeden Fall werde ich dort am Freitag eine Session über das Thema Kerberos als Unternehmsweites Single-Sign-On haben. Hier wird es also weniger um technischen Details gehen als viel mehr um die Bedeutung von Kerberos als SSO-System in einem Unternehmen.

Weitere Termine sind:

21.05.07: Java User Group München: Spring Security als universelle Sicherheitsplattform
05.07.07: Java Forum Stuttgart: Ease of Security
26.06.07-29.06.08: Core Spring Training in Frankfurt am Main

Ab jetzt bei Interface21

Seit 01.04. (nein, kein Aprilscherz) bin ich jetzt als Senior Consultant bei Interface21, der Frima hinter dem Spring Framework, tätig.

Die Zeit bei der SOFTCON war sehr schön und ich hatte dort auch ich nie etwas zu Beanstanden, doch jetzt freue ich mich schon auf die neuen Aufgaben bei Interface21. Auch hier werde ich neben Spring und Acegi Consulting/Training auch weiterhin als Berater für sämtliche IT-Security Themen zur Verfügung stehen, wie z.B. Kerberos und SSO.

Erste Termine für 2007

Die ersten Termine für 2007 stehen jetzt fest:

Der Auftakt findet diesemal bei den Entwicklertagen vom 26.02.07 bis 02.03.07 in Frankfurt-Mörfelden statt. Hier halte ich am 02.03.07 einen 1-tägigen Workshop mit dem Titel “Advanced Spring Security mit Acegi, AspectJ und CAS“. Dabei werde ich praxisnah die Grundlagen von Spring Security (auch bekannt als Acegi-Framework) erläutern, aber auch weiterführende Themen wie Single-Sign-On mit CAS und das Zusammspiel mit AspectJ behandeln. Natürlich wird es auch einen Ausblick auf die Version 1.1.0 geben.

Weiter geht es dann auf der JAX 2007 in Wiesbaden, die diesmal schon einen Monat früher stattfindet, nämlich vom 23.04.07 bis 27.04.07. Dort findet bereits zum dritten Mal der Spring Day am 23.04.07 statt, mit Themen wie Spring & OSGI, Domain-Driven Design, Spring und MDA und auch ein Vortrag von mir über Spring Security. Dabei werden die Grundlagen des Frameworks zu den Themen Web Security, Service Layer Security und Authentifizierung gezeigt.

Im Hauptprogramm der JAX gibt es dann noch einen Vortrag von mir mit dem Titel “Acegi without Spring: Die neue Sicherheitsplattform für Java“. Hier geht es darum das Acegi-Framework als allgemeine Sicherheitsplattform darzustellen. Der Einsatz beschränkt sich nämlich nicht nur auf Spring-Anwendungen sondern es kann vielmehr für nahezu jede Java-Anwendungen eingesetzt werden und bietet im Vergleich zu JAAS deutlich mehr Möglichkeiten und Komfort. Sozusagen Ease of Security. Hier werden also nicht die Grundlagen erzählt sondern anhand von kleinen Beispielen die verschiedenen Einsatzzwecke vorgeführt.

Weiter Termin stehen hier.

Umfrage zu Security APIs

In der linken Sidebar steht jetzt eine Umfrage welche Security API bzw. welches Security Framework in den Projekten genutzt wird. Leider kann das Plugin keine Mehrfachauswahl, daher bitte das Framework auswählen was den größten Anteil ausmacht.

Vielen Dank!

P.S.: Mit EJB/Web Container Managed sind EJB Security Constraints bzw. URI-Filter mit Hilfe eines Application Servers/Web Containers gemeint.

Nachtrag: Die Umfrage ist beendet, das Ergbenis ist hier zu finden.