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.

Eclipse kommt nach Europa…

The Next Total Eclipse… oder zumindest gibt es ein simultanes Release verschiedener Eclipse-Projekte, wie das schon zuvor mit Callisto durchgeführt wurde. Es geht dabei hauptsächlich um die Eclipse-IDE, bei der es ja mittlerweile eine vielzahl von Plugins gibt, welche jeweils verschiedene Release-Zyklen haben und daher auch nicht immer zusammen passen. Mit Callisto wurde einige dieser Projekte synchronisiert und es fand ein gleichzeitige Release statt. Mit Europa, dem neuen Code-Namen für das diesmalige simultane Release werden 21 Projekte gleichzeitig freigegeben. Nach dem Countdown auf der Homepage soll es in 5 Tagen soweit sein.Diesmal sind auch die AspectJ Developer Tools (AJDT) mit dabei, also der IDE-Support für aspektorientierte Programmiersprache AspectJ. Da gerade die AJDT sehr viel vom Eclipse-IDE-Core nutzen ist das wirklich ein Segen, da es hier in der Vergangenheit oft zu Versionskonflikten kam.

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.

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:

Spring Konfiguration mit Annotations

Mit Spring 2.1 wird die Unterstützung von Annotations nochmals erweitert werden. Bei Spring 2.0 wurde ja schon @Repository, @Required, @Transactional und die AspectJ-Annotation-Syntax eingeführt.

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.

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.