Entwurf und Realisierung eines Rollenmanagementsystems

Transkript

1 Fachhochschule Aachen Fachbereich 9 - Medizintechnik und Technomathematik Entwurf und Realisierung eines Rollenmanagementsystems Seminararbeit im Studiengang Scientic Programming Autor: Philip Minkenberg Mat. Nr.: Erstprüfer: Prof. Dr. Volker Sander Zweitprüfer: Dipl.-Ing. Rainer Onkels Aachen, den 7. Januar 2013

2

3 Eidesstattliche Erklärung Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema Entwurf und Realisierung eines Rollenmanagementsystems selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder sinngemäÿ entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung war. Aachen, den 7. Januar 2013 Philip Minkenberg

4

5 Zusammenfassung Ziel dieser Seminararbeit ist es, ein einheitliches Rollensystem zu entwerfen, das in allen Anwendungen des Instituts für Eisenhüttenkunde benutzt werden kann und so später auch zur Grundlage eines Workow-Management-Systems werden soll. Im Speziellen wird auf den ANSI-Standard Role-Based Access Control eingegangen. Mit Hilfe dieses Standards und unter Berücksichtigung zweier Beispielprozesse soll ein eigenes Rollenmanagementsystem entwickelt werden, mit dem die Struktur des Instituts abgebildet werden kann. Bei diesen Beispielprozessen handelt es sich zum einen um den Prozess der Materialbeschaung in der IT-Abteilung und zum anderen um die Verwaltung von Studien- und Diplomarbeiten. Bei der Materialbeschaung geht es hauptsächlich um eine Bewilligungshierarchie, bei den Studien- und Diplomarbeiten um die Ausschreibung von Arbeiten.

6

7 Inhaltsverzeichnis 1 Einleitung Motivation Aufbau und Inhalt der Arbeit Ist-Zustand Problemstellung Ziel der Arbeit Rolle Was ist eine Rolle? Warum keine direkte Rechtevergabe? Unterschied: Rolle - Gruppe Role-Based Access Control Grundmodell Hierarchie Einschränkungen Static Seperation of Duty Dynamic Seperation of Duty Vereinigung beider Erweiterungen Hinzufügen von Attributen (RBAC-A) Analyse der Beispielprozesse Prozess IT-Beschaung: Prozess: Verwaltung von Studien-/Diplomarbeiten Anforderungen Datenbankstruktur Auswahl eines geeigneten Modells Realisierung

8 6 Programmstruktur Einbindung in bestehendes System Schnittstelle Das Programm Fazit und Ausblick 20 Literatur A

9 1 EINLEITUNG 1 Einleitung 1.1 Motivation Das Institut für Eisenhüttenkunde, im Folgenden IEHK genannt, ist ein Institut der RWTH 1 Aachen mit circa 200 Beschäftigten und einem Lehrstuhl. Um bei einer solchen Vielzahl von Mitarbeitern komplexe Arbeitsabläufe mit Bewilligungsmechanismen abbilden zu können, wird ein Workow-Management-System benötigt. Ein Teil dieses Managementsystems ist das Rollenmanagement, welches Thema dieser Seminararbeit ist. 1.2 Aufbau und Inhalt der Arbeit Die vorliegende Seminararbeit ist in fünf groÿe Abschnitte unterteilt: Die ersten beiden Teile sind theoretisch und behandeln die Denitionen von Rolle und rollenbasierter Zugriskontrolle (Role-Based Access Control). Im Anschluss werden zwei Beispielprozesse analysiert, um daraufhin in den letzten beiden Teilen ein Datenbankmodell mit zugehörigem Programm vorzustellen. 1.3 Ist-Zustand Zurzeit werden bei vielen selbst programmierten Anwendungen die jeweiligen Abläufe und damit verbundenen berechtigten Personen bzw. Gruppen direkt in den Quelltext oder in eine eigenständige Datenbank eingetragen. Aus diesem Grund kann es leicht zu Inkonsistenzen kommen. Auÿerdem kann es vorkommen, dass sich zum Beispiel die Position eines Gruppenleiters ändert und somit alle Programme manuell geändert werden müssen. Dies stellt sich zum Teil als schwierig heraus, da die jeweiligen Programmierer gröÿtenteils nicht mehr am Institut arbeiten und eine Dokumentation in vielen Fällen unvollständig oder unverständlich ist. 1 Rheinisch-Westfälische Technische Hochschule Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 1 von 20

10 1 EINLEITUNG 1.4 Problemstellung Es soll ein Rollensystem entwickelt werden, mit dem später aufzubauende Workow-Prozesse in unserem Institut abgebildet werden können. Hierzu sollen exemplarisch zwei unterschiedliche Prozesse analysiert werden und für diese Prozesse adäquate Rollensysteme entworfen werden. Besonders zu beachten ist, dass es sich bei dem System um ein einfaches, gut skalierendes System handeln soll, das auf oenen Standards basiert. Die Nutzung des Systems soll über eine Web-Schnittstelle möglich sein. Hierbei sollten als Datenbank MySQL und als Programmiersprache Java und PHP benutzt werden. Als Benutzerverzeichnisdienst soll die LDAP-Schnittstelle des Active Directory von Microsoft zum Einsatz kommen, wo alle Benutzer und Gruppen des Institutes bereits hinterlegt sind. 1.5 Ziel der Arbeit Ziel der Arbeit ist es, ein einheitliches Rollensystem zu entwerfen, das in allen Anwendungen benutzt werden kann und so später auch zur Grundlage des Workow-Management-Systems werden soll. Dadurch soll bei möglichen Rollen- oder Personaländerungen nur noch an einer zentralen Stelle eingegriffen werden müssen. Auÿerdem soll es auch für Nicht-Programmierer möglich sein, diese Änderungen vorzunehmen. 2 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

11 2 ROLLE 2 Rolle 2.1 Was ist eine Rolle? Eine Rolle deniert Rechte und Aufgaben eines Benutzers in einer Software. Rollen sind der Wirklichkeit nachempfunden (Abteilungsleiter, Angestellter, Student etc.) und so leicht verständlich. Die Einführung von Rollen ermöglicht die Trennung von Funktion und Person. Eine Rolle kann dabei einmal deniert werden, aber von verschiedenen Personen wahrgenommen werden. Die Rechte, die diese Personen dadurch erhalten sind somit nicht direkt mit der Person, sondern mit der Rolle verknüpft. Dadurch ist es möglich, mit nur einer Zuweisung einer Person die identischen Rechte zuzuweisen, die eine andere Person bereits besitzt. Der administrativen Aufwand wird somit reduziert, da nicht mehr einzelne Rechte einer Person zugeordnet werden müssen, sondern nur noch die Personen den Rollen. 2.2 Warum keine direkte Rechtevergabe? Wie in Tabelle 1 zu sehen ist, skaliert die Anzahl der Zuordnungen der Methode des rechtebasierten Zugris mit Anzahl der Rechte * Anzahl der Personen, wohingegen der rollenbasierte Zugri nur Anzahl der Rechte + Anzahl der Personen Zuordnungen benötigt. Sobald also mindestens für zwei Personen eine Rolle mit mindestens zwei Rechten eingetragen wird, werden weniger Zuordnungen benötigt. Des weiteren muss nur ein Datensatz bearbeitet werden, falls ein Recht zu einer Rolle hinzugefügt beziehungsweise entfernt werden soll. Auÿerdem bleiben die Rechte einer Rolle erhalten, auch wenn keine Person diese Rolle wahrnimmt. Ein weiterer Vorteil von Rollen ist, dass Rollen hierarchisch aufgebaut werden können (s. Kap. 3.2) und somit bestimmte Berechtigungen vererbt werden können. Somit kann eine Rolle mehrere Unterrollen besitzen, welche Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 3 von 20

12 2 ROLLE Rechtebasierter Zugri Rollenbasierter Zugri Recht 1 - Person 1 Recht 1 - Rolle 1 Recht 2 - Person 1 Recht 2 - Rolle 1 Recht 3 - Person 1 Recht 3 - Rolle 1 Recht 4 - Person 1 Recht 4 - Rolle 1 Recht 1 - Person 2 Recht 2 - Person 2 Rolle 1 - Person 1 Recht 3 - Person 2 Rolle 1 - Person 2 Recht 4 - Person 2 Rolle 1 - Person 3 Recht 1 - Person 3 Recht 2 - Person 3 Recht 3 - Person 3 Recht 4 - Person 3 Tabelle 1: Rechte- vs. Rollenbasierter Zugri Berechtigungen vererbt bekommen. Sobald alle Rollen deniert sind, ändern sich die Zuweisungen von Rollen zu Rechten relativ selten, sodass nur noch die Zuordnung Person<->Rolle eingetragen werden muss. 2.3 Unterschied: Rolle - Gruppe Auf den ersten Blick haben Rollen starke Ähnlichkeit zu Benutzergruppen, jedoch sind Rollen eine Weiterentwicklung von Gruppen. Gruppen fassen Personen zusammen, die einer festen, realen Gruppe von Personen entsprechen (z.b. (alle) Mitarbeiter oder Buchhaltung), d.h. die Benutzer werden ohne Betrachtung der zu erhaltenden Rechte gruppiert. Eine Rolle hingegen basiert auf Arbeitsprozessen und beinhaltet für den Prozess relevante Rechte. So kann für jedes Projekt eine beliebige Anzahl an Rollen deniert werden, die dann entsprechenden Personen oder Gruppen zugeordnet werden können. Ein weiterer Punkt, in dem sich Rollen von Gruppen unterscheiden, ist die Rechtevererbung (s. Kap. 3.2). Es ist möglich, eine Hierarchie innerhalb von Rollen aufzubauen. Auÿerdem können Bedingungen an Rollen geknüpft 4 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

13 2 ROLLE Abbildung 1: User - Group - Permission sein (s. Kap. 3.3) und schränken so die Rechte bestimmter Personen ein, falls dies gewollt ist. Rollen sind auÿerdem nur so lange aktiv, solange sie benötigt werden. So besitzt ein Benutzer nur die Rechte, die er benötigt (principle of least privilege). Einer Gruppe ist man fest zugehörig oder nicht zugehörig und man besitzt somit alle Rechte aller Gruppen, denen man angehört, sodass dieses Prinzip verletzt wird. Beispiel: Ein Benutzer besitzt die Rollen Benutzer und Administrator. Als normaler Benutzer erhält er die gleiche Ansicht auf Webseiten, wie jeder andere normale Benutzer auch. Sollte jedoch Bedarf an weiteren Rechten bestehen, kann aber er die Administratorrolle übernehmen. Sprich, der Benutzer hat eine eine Auswahl-Liste, mit der er die Rolle wechseln kann die er im jeweiligen Bereich anhand der Rechte einnehmen kann. Ist keine Rolle vorhanden, kann er auch nicht zugreifen. Auÿerdem kann eine Rollenzugehörigkeit zeitlich begrenzt werden. So kann ein Stellvertreter zum Beispiel nur die Berechtigungen erhalten, wenn die Person, die er vertritt, nicht anwesend ist. (s. Kap. 3.3) Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 5 von 20

14 3 ROLE-BASED ACCESS CONTROL 3 Role-Based Access Control Das Prinzip der Rolle wird besonders beim NIST 2 -Standard Role- Based Access Control (kurz RBAC) (ANSI-Norm ) verwendet [Ame03]. Diese Norm entwickelte sich aus aus einem Paper [FK92] von David Ferraiolo und Richard Kuhn zu der Computer Security Conference RBAC ist in 4 Versionen Abbildung 2: RBAC Versionen verfügbar. Es gibt das Grundmodell mit 3 Erweiterungen. Die erste (Hierarchie) und zweite (Einschränkungen) Erweiterung sind unabhängige Weiterentwicklungen des Grundmodells und nicht untereinander kompatibel. Die dritte Erweiterung führt die ersten beiden Erweiterungen zusammen und macht diese kompatibel. 3.1 Grundmodell Das Grundmodell (s. Abbildung 3) des RBAC enthält die Objekte Subject (Benutzer/Gruppe), Role, Permission und Session. Jedem Benutzer können eine oder mehrere Rollen zugewiesen werden, die entsprechende Rechte besitzen. Beim Login sind jedoch nicht alle zugeteilten Rollen aktiv, sodass eine Session erzeugt wird, in der alle aktiven Rollen festgehalten werden. Diese Session legt somit fest, welche Berechtigungen zum jeweiligen Zeitpunkt vorhanden sind. Ein Benutzer kann mehrere Sessions besitzen, jedoch kann jede Session nur einen Besitzer haben. 2 National Institute of Standards and Technology 6 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

15 3 ROLE-BASED ACCESS CONTROL Abbildung 3: RBAC Grundmodell 3.2 Hierarchie Abbildung 4: RBAC - Hierarchie Als erste Erweiterung zum Grundmodell wird eine Hierarchie eingefügt. Dadurch wird es möglich, die Rechte einer übergeordneten Rolle teilweise einer untergeordneten Rolle zu vererben. Die Unterrolle hat dadurch eine Teilmenge der Rechte der Oberrolle. Eine Mehrfachvererbung ist auch möglich, sodass eine Rolle mit zwei Unterrollen eine Kombination der Rechte der Unterrollen inklusive eventuell eigene Rechte besitzt. Beispiel: Ein Mitarbeiter der IT-Abteilung und ein Mitarbeiter der Buchhaltung haben beide die Berechtigung eines normalen Mitarbeiter s. Ebenso beinhaltet die Rolle eines IT-Mitarbeiters aber auch die Rolle eines Computeradministrators. 3.3 Einschränkungen Eine zur ersten Erweiterung unabhängige Version beinhaltet die Trennung von sich ausschlieÿenden Rollen. Konikte zwischen Rollen können entstehen, wenn eine Person zwei verschiedene Rollen besitzt, die im Gegensatz zuein- Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 7 von 20

16 3 ROLE-BASED ACCESS CONTROL Abbildung 5: RBAC - Einschränkungen ander stehen. Bei diesen Konikten unterscheidet man zwischen statischen Einschränkungen (Static Seperation of Duty, kurz SSD) und dynamischen Einschränkungen (Dynamic Seperation of Duty, kurz DSD) Static Seperation of Duty Statische Einschränkungen liegen vor, wenn generell der Besitz zweier Rollen ausgeschlossen ist. Es ist zum Beispiel nicht möglich, Mutter und Vater gleichzeitig zu sein. Diese Rollen schlieÿen sich vom Grundsatz her aus. In unserem Fall soll es zum Beispiel nicht möglich sein, dass eine Person die Leitung zweier Arbeitsgruppen besitzt Dynamic Seperation of Duty Dynamische Einschränkungen wirken nur auf eine Session. Eine Person hat die Möglichkeit, zwei koniktbehaftete Rollen zu besitzen, doch hat sie nicht die Möglichkeit, dass beide Rollen gleichzeitig in einer Session aktiv sind. Ein Beispiel für eine dynamische Einschränkung ist das Vier-Augen-Prinzip. Dieses Prinzip besagt, dass eine Entscheidung nicht durch eine einzelne Person getroen werden kann. Die Einschränkung in diesem Fall wäre dann, dass eine Person nicht die Rolle beider Entscheidungsträger wahrnehmen kann. Ein weiteres Beispiel ist die Unterscheidung zwischen Anwender- und Programmiereransicht einer Website. Die Programmiereransicht unterscheidet 8 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

17 3 ROLE-BASED ACCESS CONTROL Abbildung 6: RBAC - Vereinigung Abbildung 7: RBAC-A sich grundlegend von der Anwenderansicht, sodass man entweder Anwender oder Programmierer ist. 3.4 Vereinigung beider Erweiterungen Die dritte und letzte Erweiterung vereint die beiden vorhergehenden Versionen zur nalen Version von RBAC. Erweiterung 1 und 2 sind nicht untereinander kompatibel, da durch eine Vererbung Einschränkungen aufgehoben werden können. Damit dies nicht eintritt, muss in dieser Version die Prüfung, ob eine Einschränkung vorliegt, nicht zwischen den eigentlichen Rollen Rollen, sondern auch zwischen allen Unterrollen stattnden. Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 9 von 20

18 3 ROLE-BASED ACCESS CONTROL 3.5 Hinzufügen von Attributen (RBAC-A) In einem Artikel im IEEE Computer vom Juni 2010 ([KCW10]) wird noch eine Erweiterung zum eigentlichen RBAC beschrieben: Um nicht für jeden Sonderfall eine eigene Rolle denieren zu müssen, wird die Rolle um einige Bedingungen erweitert. Sollte zum Beispiel Mitarbeiter A nur montags von 8:00 Uhr - 16:00 Uhr eine spezielle Berechtigung durch eine Rolle erhalten, Mitarbeiter B jedoch jeden Wochentag diese Berechtigung haben, sind normalerweise zwei verschiedene Rollen notwendig. Diese Rollen können dynamisch unter Zuhilfenahme externer Quellen erzeugt werden und müssen nicht als eigenständige Rollen deniert werden. Mögliche Bedingungen für diese Regeln können, auÿer zeitlicher Begrenzung (von... bis...), auch Anwesenheit (da/nicht da?) oder Einwilligung sein. Durch diesen Schritt lassen sich statische Rollen (z.b. Institutsleiter), die immer gelten, mit dynamischen Rollen (z.b. eine Urlaubsvertretung) kombinieren. Beispiel: In einem System mit 10 Berechtigungen (4 statisch, 6 dynamisch) müssen, um alle Fälle abbilden zu können, in der herkömmlichen Form 1024 Rollen (2^10) erstellt werden. In der erweiterten Version lediglich 16 Rollen (2^4 statische Berechtigungen) und 64 Regeln (2^6 dynamische Berechtigungen) angelegt werden. 10 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

19 4 ANALYSE DER BEISPIELPROZESSE 4 Analyse der Beispielprozesse 4.1 Prozess IT-Beschaung: Bei einer IT-Materialbeschaung wird zunächst eine Materialanforderung von einem Mitglied der Rechnergruppe erstellt (Rolle: IT- Mitarbeiter). Anschlieÿend muss diese durch den Leiter der IT-Abteilung (als Rolle: Beschaung-IT-Chef ) beziehungsweise dessen Stellvertreter und danach durch eine unterschriftberechtigte Person (in unserem Fall vom akademischen Direktor, oder falls dieser nicht verfügbar ist vom Betriebsingenieur (Rolle: Abbildung 8: Workow: ITwerden. Beschaung-Bewilliger ) bewilligt Nach erfolgreicher Bewilligung Beschaung wird die Bestellung vom Beschaer bestellt (Rolle: IT-Besteller), An- schlieÿend muss die Beschaung durch den Betriebsingenieur inventarisiert werden (Rolle: Beschaung-Inventeur ). Wie dabei zu sehen ist (s. Abbildung 9), ist die eigentliche Beschaffungsrolle in Unterrollen aufgeteilt. Diese Unterrollen sind zum Teil delegiert (z.b. Beschaung-Inventeur ) oder in Stellvertretung abgegeben (z.b. Beschaung-Bewilliger-Stv.). Bei der Delegation werden sämtliche Rechte, bis auf das Recht, die Delegation zurück zu nehmen, an den Delegierten abgegeben. Der Delegierte hat dadurch sämtliche Berechtigungen in seinem Aufgabenbereich. Der Beschaung-Chef hat das Recht der IT-Beschaung an den Beschaung- Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 11 von 20

20 4 ANALYSE DER BEISPIELPROZESSE Abbildung 9: Rollenbaum: IT-Beschaung IT-Chef und das Recht der Inventur an den Beschaung-Inventeur abgegeben. Er besitzt somit nicht mehr die Berechtigung zu Inventur, Bewilligung 1, Materialanforderung schreiben und Bestellung, sondern lediglich das Recht zu Bewilligung 2. Eine Teil-Vererbung entspricht der Hierarchie, wie sie in RBAC 1 deniert wird. Der Beschaung-IT-Chef ist gleichzeitig IT-Mitarbeiter und besitzt somit auch alle Rechte dieser Unterrolle. Gleichzeitig ist er auch IT- Besteller. Der IT-Leiter-Stv besitzt als Stellvertreter, wenn alle Bedingungen für die Stellvertretung erfüllt sind (in diesem Fall durch Abwesenheit des IT- Leiters), auÿerdem das Recht der Bewilligung 1, jedoch nicht die Rolle des Ausbilders, da hierfür eine entsprechende Qualikation fehlt. Bei der Rechteveräuÿerung ist darauf zu achten, dass manche Rechte nicht weitergegeben werden können. Ein Abteilungsleiter kann seine Funktion einer Stellvertretung weitergeben oder spezielle Rechte delegieren. Wenn es jedoch darum geht, eine Materialanforderung zu schreiben, ist dieses Recht vom IT-Leiter an seine Arbeitsgruppe gegeben worden. Diese können dieses Recht jedoch keiner anderen Arbeitsgruppe übereignen. 12 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

21 4 ANALYSE DER BEISPIELPROZESSE 4.2 Prozess: Verwaltung von Studien-/Diplomarbeiten Bei der Ausschreibung einer Studien- /Diplomarbeit wird zunächst ein Datensatz erstellt, der einem Betreuer zugeordnet wird. Sobald dieser die Ausschreibung frei gibt, muss diese vom Professor des entsprechenden Lehrstuhls bewilligt werden. Anschlieÿend wird die Arbeit im Internet publiziert und kann vergeben werden. Aus diesem Prozess ergeben sich drei Rollen: Ersteller Abbildung 10: Workow: Ausschreibungen Ein Ersteller hat die Möglichkeit einen Entwurf für eine Arbeit anzufertigen, die später dann einem Betreuer zugeordnet werden kann. Die Ersteller-Rolle kann von einer wissenschaftlichen Hilfskraft wahrgenommen werden, die im Auftrag eines Betreuers arbeitet. Betreuer Der Betreuer betreut die Arbeit und muss mindestens den akademischen Abschluss besitzen, der angestrebt wird. Er kann die Ausschreibung fertigstellen und diese seinem Professor vorlegen, damit sie ins Internet gestellt wird. Auÿerdem kann er die Arbeit vergeben oder abbrechen und somit aus der Ausschreibung entfernen. Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 13 von 20

22 4 ANALYSE DER BEISPIELPROZESSE Professor Der Professor ist verantwortlich für alle Arbeiten, die im Internet publiziert werden. Er hat die Möglichkeit, Arbeiten zu bewilligen, abzulehnen oder zu löschen. Alle Berechtigungen sind hierarchisch aufgebaut, sodass ein Professor alle Berechtigungen eines Betreuers oder Erstellers und ein Betreuer die eines Erstellers besitzt. Dabei zu beachten ist, dass der Betreuer nur seine eigenen Arbeiten seinem Professor vorlegen kann und der Professor nur Arbeiten seines Lehrstuhls bewilligen darf. 4.3 Anforderungen Aus den beiden Beispielprozessen ergeben sich dadurch folgende Anforderungen: ˆ Ein hierarchisches Datenbankmodell. ˆ Es müssen sowohl Gruppen, als auch einzelne Personen einer Rolle zugeordnet werden können. ˆ Benutzern/Gruppen können mehreren Rollen zugeordnet werden. (Benutzer <-> Rolle ist eine m:n Beziehung) ˆ Die Baumstruktur muss an einem Punkt unterbrochen (bzw. die Weitergabe verboten) werden können. ˆ Es müssen Bedingungen an Rollen/Rechte geknüpft werden können. 14 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

23 5 DATENBANKSTRUKTUR 5 Datenbankstruktur 5.1 Auswahl eines geeigneten Modells Nach Analyse der beiden Beispielprozesse und unter Berücksichtigung des Standards Role-Based Access Control, ergibt sich für das Datenbankmodell folgende Struktur: Um das Modell so einfach, wie nötig zu halten, wird lediglich die erste Erweiterung des RBAC genutzt mit der Erweiterung um Attribute. Diese Attribute müssen Zeit, Anwesenheit und Einwilligung abbilden können. Ein Session-Management wird ebenfalls benötigt, um bei einem möglichen Plattformwechsel, alle aktiven Rollen speichern und diese Bedarf auch wieder zurück gegeben zu können. Eine Gewaltentrennung, wie sie in der zweiten Erweiterung vorkommt (statische und dynamische Einschränkungen), wird softwareseitig nicht benötigt. Hier muss bei Zuweisung der Rollen darauf geachtet werden, dass nur Rollen ausgewählt werden, die sinnvoll sind. 5.2 Realisierung BenutzerZuRolle In der Tabelle BenutzerZuRolle wird die Beziehung zwischen Rollen und Benutzern festgelegt. Diese Beziehung ist eine n:m-beziehung. Der entsprechende Benutzername kommt aus dem Active Directory. GruppeZuRolle Analog zu BenutzerZuRolle, nur dass hier entsprechende Rollen mit AD- Gruppen verknüpft werden. Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 15 von 20

24 5 DATENBANKSTRUKTUR Abbildung 11: Datenbankmodell Session In der Session wird festgehalten, wann eine entsprechende Rolle von einem Benutzer aktiviert wurde. Dies beinhaltet auch die Rollen, die durch eine Gruppenzugehörigkeit angenommen werden kann. Es wird auÿerdem ein Zeitstempel gespeichert, wann diese Zuordnung erfolgt ist. So ist es der jeweiligen Anwendung selbst überlassen, dieser Zuweisung zu vertrauen, oder falls die Zuordnung zu lange zurück liegt, eine neue Autorisierung für die Rolle anzufordern. Rolle Deniert die eigentliche Rolle. Der Name der Rolle muss einzigartig sein. Das Attribut keineweitergabe legt fest, ob diese Rolle das Recht besitzt, ihre Rechte an andere zu delegieren oder in Stellvertretung abzugeben. 16 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

25 5 DATENBANKSTRUKTUR Hierarchie Hier wird die eigentliche Hierarchie zwischen den Rollen festgelegt. Der Typ der Relation beschreibt, ob es sich um einen Teil dieser Rolle handelt oder ob diese Unterrolle delegiert wurde und somit nicht mehr verfügbar ist. Relationstyp Legt den Relationstyp fest, der die Hierarchie festlegt. Mögliche Typen sind Teil und Delegation. RolleZuRecht Verknüpft Rollen mit Rechten. Diese Verknüpfung ist jedoch an Bedingungen geknüpft. Bedingung Legt die Bedingung fest, die erfüllt sein muss, damit eine Rolle ein entsprechendes Recht wahrnehmen kann. Eine entsprechende Bedingung könnte FROM 07:30:00 TO 16:20:00 oder IF ROLE IT-Leiter IS ABSENT oder IF USER IS OWNER lauten. Eine Auswertung ndet über das Programm statt, sodass sich neue Bedingungen einfach hinzufügen lassen. Recht Deniert das eigentliche Recht. Der Name eines Rechtes muss ebenso wie der Name der Rolle einzigartig sein. Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 17 von 20

26 6 PROGRAMMSTRUKTUR 6 Programmstruktur 6.1 Einbindung in bestehendes System Eine Anforderung an das System ist, sich in das momentan bestehende System zu integrieren. Als Benutzerverzeichnisdienst kommt das Active Directory von Microsoft zum Einsatz. Um mit diesem System zu kommunizieren wird das Lightweight Directory Access Protocol (LDAP) verwendet, um entsprechende Benutzer und Gruppen auösen zu können. Die Authentizierung wird über Kerberos 3 vorgenommen und das Rollenmanagementsystem muss sich nur noch um die entsprechende Autorisierung kümmern. 6.2 Schnittstelle Abbildung 12: Kommunikation Webservice Um eine entsprechende Schnittstelle nach auÿen anzubieten, werden Web-Services eingesetzt. Web- Services können über die standardisierte SOAP 4 -Schnittstelle [Hub12] angesprochen werden. Als Antwort wird daraufhin eine XML 5 -formatierte Nachricht zurück gegeben. Serverseitig wird Axis2 6 [Apa12] eingesetzt. Axis2 ist eine SOAP- Engine, mit der sich Web-Services in Java entwickeln lassen. Diese in Axis2 entwickelten Webservices laufen in einer Apache Tomcat-Umgebung, die auf allen gängigen Webservern läuft. 3 verteilter Authentizierungsdienst - Single Sign-On-fähig 4 ursprünglich: Simple Object Access Protocol, mittlerweile nur noch Akronym 5 Extensible Markup Language 6 Apache extensible Interaction System 18 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

27 6 PROGRAMMSTRUKTUR Der Vorteil dieser Kombination ist, dass es durch oene Standards ermöglicht wird, eine Schnittstelle zu erschaen, die von fast allen Programmiersprachen angesprochen werden kann. In unserem Fall lässt sich ein Webinterface in PHP programmieren, welches seine Daten vom Webservice erhält. 6.3 Das Programm Die Hauptaufgabe, des Programm ist es, Benutzern Rollen zuzuteilen und aktive Rollen in entsprechenden Sessions zu speichern. Es muss möglich sein, unter Berücksichtigung aller Bedingungen, alle Personen mit einer entsprechenden Rolle beziehungsweise alle Rollen einer Person zurückzugeben oder eine spezielle Berechtigung zu überprüfen. Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen 19 von 20

28 7 FAZIT UND AUSBLICK 7 Fazit und Ausblick Role-Based Access Control bietet ein mächtiges Werkzeug, wenn es um die Rechteverwaltung geht. Jedoch wird für unser Institut nur ein Teil dieser Funktionalität benötigt, sodass kein reines RBAC verwendet wird. Einige Sonderfälle lassen sich zwar so nicht im Programm abbilden, jedoch wird so das Managementsystem ohne groÿe Nachteile vereinfacht. Eine Kommunikation unter beteiligten Personen sollte trotz dieses Systems vorhanden bleiben, sodass diese Sonderfälle durch persönliche Kontakte auch gelöst werden können. Im Anschluss an diese Seminararbeit wird ein entsprechendes Workow- Management-System erstellt, welches auf das in dieser Arbeit erstellte Rollenmanagementsystem aufbaut. Vordenierte Schnittstellen ermöglichen eine unabhängige Entwicklung beider Komponenten. So kann das Rollenmanagementsystem schon gepegt werden und für andere Anwendungen genutzt werden, während das Worlow-Management-System noch entwickelt wird. 20 von 20 Philip Minkenberg, Institut für Eisenhüttenkunde RWTH Aachen

29 Literatur [Ame03] American National Standard for Information Technology: Role Based Access Control. Draft. rbac/rbac-std-ncits.pdf. Version: BSR INCITS 359 [Apa12] [FK92] Ferraiolo, David F. ; Kuhn, D. R.: Role-Based Access Controls National Institute of Standard and Technology, 1992, th National Computer Security Conference, Baltimore MD [Gra06] Graversen, Kasper B.: The nature of roles, IT University of Copenhagen, Diss., September kbilsted/graversen06thesis.pdf [Hub12] Huber, Mathias: Schnittstellen-Magie - Einführung: Webservices mit SOAP und REST. In: Linux Magazin (2012), Nr , S. 20f [KCW10] Kuhn, D. R. ; Coyne, Edward J. ; Weil, Timothy R.: Adding Attributes to Role-Based Access Control. In: IEEE Computer 43 (2010), documents/kuhn-coyne-weil-10.pdf [SCFY96] Sandhu, Ravi S. ; Coyne, Edward J. ; Feinstein, Hal L. ; Youman, Charles E.: Role-Based Access Control Models. In: IEEE Computer 29 (1996), February, Nr. 2, gov/rbac/sandhu96.pdf