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.

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.

Wieder mit dabei ist natürlich auch wieder die Web Tools Platform (WTP), welche die Eclipse-IDE zur Webentwicklung tauglich macht, indem beispielsweise der Tomcat im Eclipse gestartet werden kann.

Und auch Eclipse Mylyn, welches vorher unter dem Namen Mylar bekannt war ist dabei. Dieses Plugin macht aus einer Eclipse-IDE eine Task orientierte Entwicklungsumgebung. Das heißt es können Tasks aus System wie JIRA, Trac oder Bugzilla dargestellt werden. Das besondere dabei ist jedoch, das man dann die Arbeit an einem Task starten kann und Mylyn fokusiert aufgrund der durchgeführte Schritte die Oberfläche auf die benutzten Dateien. Wird der Task später gewechselt werden wieder die Dateien für den anderen Task angezeigt.

Nicht bestandteil von Europa aber dennoch im gleichen Zeitraum wird das Release 2.0 von Spring IDE fertig werden. Dies ist ebenfalls ein Eclipse-Plugin zum entwickeln von Spring Anwendungen. Eines der neuen Feature ist dabei die Darstellung der Spring AOP Advices, ähnlich wie das AJDT macht.

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

| View | Upload your own

Kerberos im Detail:

| View | Upload your own

Bei Spring 2.1 geht es jetzt soweit, das die komplette SpringKonfiguration über Annotations gemacht werden kann. Die bisherige Konfiguration mit XML bleibt natürlich trotzdem vorhanden und wird auch nicht deprecated, vielmehr wird dadurch eine Alternative angeboten die in einigen Bereichen vielleicht ganz interessant sein dürfte.

Wenn bei Spring 2.1 ein Service z.B. einen DAO benötigt kann dies dann durch folgenden Code geschehen:

@Autowired
private void setMeinTollerDao(MeinTollerDao dao)

Der Service kann dann entweder mit folgender Konfiguration angelegt werden:

<bean class="service.MeinTollerService"/>

..oder aber von Spring “gesucht” werden:

<context:component-scan base-package="service"/>

Dazu muss dann bei der Klasse noch die Annotation @Component hinzugefügt werden.

Der DAO kann dann z.B. wiederum in einer Spring-XML-Datei konfiguriert sein oder ebenfalls über @Component erstellt werden. Es ist also auch beliebiges mischen möglich, und mit @Resource kann auch ein explizites Mapping auf eine Spring Bean anstatt autowire gemacht werden.

Weiterhin werden auch die JSR-250 Annotations @PostConstruct und @PreDestroy unterstützt.

Eine Step-by-Step Anleitung von meinem Kollegen Mark Fisher gibt es hier: http://blog.interface21.com/main/2007/05/14/annotation-driven-dependency-injection-in-spring-21/

Natürlich sind das Features über die diskutiert werden kann, weshalb es dazu auch einen Thread in der Spring User Group Germany gibt. Hier ist jeder eingeladen mit zu diskutieren.

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

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.