Benutzerautorisierung mit Anbindung an die Benutzungsoberfläche

Benutzerautorisierung mit Anbindung
an die Benutzungsoberäche von
Rich-Clients auf Basis der Eclipse RCP
Diplomarbeit
Arbeitsbereich Softwaretechnik
Department Informatik
Universität Hamburg
Verfasser
Kai Meyer und Torsten Witte
1. Betreuer: Prof. Dr. Heinz Züllighoven
2. Betreuer: Prof. Dr. Norbert Ritter
Hamburg, 25. September 2007
Zusammenfassung
Diese Arbeit schat eine Grundlage, die Lücke in der Literatur zwischen
Kai Meyer und
Benutzerautorisierung und gebrauchstauglichen Benutzungsoberächen, zu
Torsten Witte
schlieÿen.
Dies geschieht am Beispiel von Rich-Client-Anwendungen auf
Basis der Eclipse RCP. Bewährte Autorisierungmechanismen werden vorgestellt, Kriterien für gebrauchstaugliche Software aufgestellt und aktuelle
Diskussionen über Autorisierung im Umfeld der Eclipse RCP zusammengefasst. Mit den so gewonnenen Erkenntnissen werden lauähige Prototypen
entwickelt, die als Grundlage für reale Projekte dienen, in denen Benutzerautorisierung eine Rolle spielt.
ii
Inhaltsverzeichnis
Motivation
1
Ausgangspunkte der Arbeit
Ziel der Arbeit
. . . . . . . . . . . . . . . . . . . . . .
2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Vorgehensweise der Autoren . . . . . . . . . . . . . . . . . . . . . .
3
Aufbau der Arbeit
. . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Abgrenzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . .
4
Konventionen
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I Grundlagen
7
1 Begrie und Denitionen
9
1.1
Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Benutzungsoberächen und Benutzungsfreundlichkeit
. . . . .
10
1.3
Identizierung . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.4
Single Sign-On (SSO) . . . . . . . . . . . . . . . . . . . . . . .
13
1.5
Authentizierung
. . . . . . . . . . . . . . . . . . . . . . . . .
13
1.6
Autorisierung
. . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.7
Rechtevergabe und -entzug . . . . . . . . . . . . . . . . . . . .
15
1.8
Filterregeln bei Autorisierung
. . . . . . . . . . . . . . . . . .
18
1.9
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . .
18
2 Die Eclipse Rich-Client-Platform
9
19
2.1
Was ist ein Rich-Client?
. . . . . . . . . . . . . . . . . . . . .
19
2.2
Was ist die Eclipse Rich-Client-Platform? . . . . . . . . . . . .
22
2.3
2.2.1
Zur Entstehungsgeschichte der Eclipse RCP
. . . . . .
23
2.2.2
Open Service Gateway Initiative (OSGi)
. . . . . . . .
23
2.2.3
Erfolg der Eclipse RCP . . . . . . . . . . . . . . . . . .
23
. . . . . . . . . . . . . . . . .
24
2.3.1
Die Eclipse Plug-In-Architektur
Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3.2
Lebenszyklus von Bundles/Plug-Ins . . . . . . . . . . .
26
iii
Inhaltsverzeichnis
iv
2.4
2.3.3
Extension-Points, Extensions und Extension-Registry .
28
2.3.4
Plug-In-Abhängigkeiten
. . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . .
31
Eclipse-Architektur in der Praxis
2.4.1
Aufbau von Plug-Ins
. . . . . . . . . . . . . . . . . . .
32
2.4.2
OSGi-Manifest, Plug-In-Manifest und Bundle-Activator
32
2.4.3
Anwendungsklassen . . . . . . . . . . . . . . . . . . . .
34
2.4.4
Wichtige Erweiterungspunkte von Eclipse . . . . . . . .
36
2.4.5
Eine Beispiel-Erweiterung
. . . . . . . . . . . . . . . .
37
2.4.6
Fragmente . . . . . . . . . . . . . . . . . . . . . . . . .
39
2.4.7
Features . . . . . . . . . . . . . . . . . . . . . . . . . .
40
2.5
Update-Sites und Updates . . . . . . . . . . . . . . . . . . . .
41
2.6
Abschlieÿende Bemerkungen . . . . . . . . . . . . . . . . . . .
43
II Theoretischer Teil
45
3 Diskussionen
47
3.1
. . . . . . .
47
3.1.1
Interaktionsobjekte bei der Benutzerautorisierung
Meldungsfenster . . . . . . . . . . . . . . . . . . . . . .
48
3.1.2
Log-in-Dialog
. . . . . . . . . . . . . . . . . . . . . . .
49
3.1.3
Optische Kennzeichnung . . . . . . . . . . . . . . . . .
49
3.1.4
Sperren von Interaktionsobjekten
50
3.1.5
Verstecken von Interaktionsobjekten
. . . . . . . . . .
51
3.1.6
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
. . . . . . . . . . . .
3.2
Allgemeine Diskussion
. . . . . . . . . . . . . . . . . . . . . .
3.3
Aktueller Diskussionsstand über Autorisierung in der Eclipse
RCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Bestehende Konzepte und Lösungen
4.1
4.2
54
60
Role Based Access Control (RBAC) . . . . . . . . . . . . . . .
60
4.1.1
Core RBAC . . . . . . . . . . . . . . . . . . . . . . . .
61
4.1.2
Hierarchical RBAC . . . . . . . . . . . . . . . . . . . .
62
4.1.3
Static Seperation of Duty (SSD) . . . . . . . . . . . . .
63
4.1.4
Dynamic Seperation of Duty (DSD) . . . . . . . . . . .
64
4.1.5
Einordnung
64
. . . . . . . . . . . . . . . . . . . . . . . .
Lightweight Directory Access Protocol (LDAP)
. . . . . . . .
65
. . . . . . . . . . . . . . . . . . . . . . . .
66
Java Authentication and Authorization Service (JAAS) . . . .
66
4.3.1
Authentizierung mit JAAS . . . . . . . . . . . . . . .
66
4.3.2
Autorisierung mit JAAS
. . . . . . . . . . . . . . . . .
67
4.3.3
Einordnung
. . . . . . . . . . . . . . . . . . . . . . . .
72
4.2.1
4.3
53
Einordnung
Inhaltsverzeichnis
4.4
v
eXtensible Access Control Markup Language (XACML) . . . .
73
4.4.1
Policies
. . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.4.2
Datenuss . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.4.3
Umsetzungen und Erweiterungen
. . . . . . . . . . . .
76
4.4.4
Einordnung
. . . . . . . . . . . . . . . . . . . . . . . .
76
5 Weitergehende Konzepte und Lösungen
78
5.1
Plug-In-(De-)Aktivierung . . . . . . . . . . . . . . . . . . . . .
5.2
Security-Facade . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.3
Auswirkungen unterschiedlicher Systemanforderungen . . . . .
83
6 Bestehende Lösungen für Eclipse
78
85
6.1
Rollenabhängige Plug-Ins . . . . . . . . . . . . . . . . . . . . .
85
6.2
Eclipse-JAAS
. . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6.3
Capabilities (Activities) in Eclipse . . . . . . . . . . . . . . . .
93
6.4
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
III Praktischer Teil
99
7 Dienstplaner
101
7.1
Konzept
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.1.1
Plug-In-Struktur
. . . . . . . . . . . . . . . . . . . . . 102
7.1.2
Funktionsweise
7.1.3
Benutzerverwaltung und Rechtevergabe . . . . . . . . . 104
. . . . . . . . . . . . . . . . . . . . . . 103
7.2
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.3
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 110
8 Taschenrechner
111
8.1
Konzept
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.2
Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.3
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 118
9 Control System Studio
120
9.1
Konzept
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
9.2
Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
9.3
Oene Probleme und Zusammenfassung
10 Zusammenfassung und Ausblick
. . . . . . . . . . . . 124
126
Inhaltsverzeichnis
vi
IV Anhang
129
A Verweise
130
A.1
Eclipse-Newsgroups . . . . . . . . . . . . . . . . . . . . . . . . 130
B Eingesetzte Werkzeuge
B.1
B.2
B.3
Java
132
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
B.2.1
Startkongurationen für RCP-Anwendungen . . . . . . 133
B.2.2
OSGi-Konsole . . . . . . . . . . . . . . . . . . . . . . . 133
Java Policy-Tool
. . . . . . . . . . . . . . . . . . . . . . . . . 135
C CD-Inhalt
136
C.1
Java
C.2
Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
C.3
Ausführbare Beispiele zu JAAS
C.4
Ausführbares Beispiel zu Eclipse-JAAS . . . . . . . . . . . . . 137
C.5
Ausführbares Beispiel zu Capabilities . . . . . . . . . . . . . . 139
C.6
Taschenrechner
. . . . . . . . . . . . . . . . . 136
. . . . . . . . . . . . . . . . . . . . . . . . . . 139
Abbildungsverzeichnis
141
Literaturverzeichnis
143
Abkürzungsverzeichnis
151
Index
153
Erklärung
159
Motivation
Im Bereich der Anwendungssoftware, insbesondere im Mehrbenutzer- und
Kai Meyer und
Netzwerkbetrieb, spielen Sicherheitskonzepte eine wichtige Rolle.
Torsten Witte
Neben
Aspekten wie Netzwerksicherheit und Verschlüsselung ist Benutzerauthentizierung und -autorisierung in Anwendungen, in denen Daten oder Funktionalitäten vor unberechtigtem Zugri geschützt werden müssen, ein zentrales Thema und die Grundlage für Sicherheit. Für die Benutzerautorisierung
sind im Laufe der Zeit unterschiedliche Konzepte, Standards und proprietäre
Lösungen entstanden. Einhergehend mit der stetig steigenden Verbreitung
von Rich-Client-Anwendungen ergeben sich weitere Anforderungen und neue
Möglichkeiten für die Benutzerautorisierung als bei Thin-Client-Lösungen.
Die Anforderung, oine arbeiten zu können, erfordert neben (teilweiser) lokaler Datenhaltung und Datensynchronisation zwischen Client und Server
auch eine clientseitige Regelung des Zugris auf diese Daten. Somit reicht
es nicht mehr, nur auf dem Server die einzelnen Funktionsaufrufe gegen unbefugte Benutzung zu sichern. Zusätzlich muss clientseitig eine Instanz vorhanden sein, die entscheidet, ob dem Benutzer einzelne Komponenten bzw.
Daten zur Verfügung stehen. Darüber hinaus bieten sich bei der Nutzung von
Rich-Clients bessere Möglichkeiten an, dem Benutzer mittels der graschen
Benutzungsoberäche über z.B. nicht gewährte Funktionen Rückmeldung zu
geben. Die meisten Arbeiten, die Sicherheitsmechanismen wie Zugriskontrolle und Verschlüsselung behandeln, decken den Bereich der Sicherheit gut
ab, berücksichtigen jedoch nicht die Auswirkungen in der Handhabung der
jeweiligen Endanwendung für den Benutzer.
Die Problematik, die somit auftritt, ist, dem Benutzer nicht nur gewisse
Aktionen, aufgrund der ihm in seiner Rolle zugesicherten Rechte, zu verbieten, sondern ihm auch eindeutig zu zeigen, dass er sie nicht ausführen darf.
Dies muss sogar möglich sein, ohne erneut auf einen Server zurück zu greifen.
Im Kern steht also die Frage:
Wie können die durch eine Zugrisver-
waltung (je nach Benutzerrolle) gewährten und nicht gewährten Rechte im
gesamten System umgesetzt und für einen Benutzer clientseitig und jederzeit
eindeutig kenntlich gemacht werden?
1
Motivation
2
Im Rahmen dieser Arbeit wird versucht, die Brücke zwischen der Zugriskontrolle und der Benutzungsoberäche zu schlagen. Dazu wird der aktuelle
Stand der laufenden Diskussionen zu diesem Thema aufgearbeitet. Es wird
der Frage nachgegangen, welche Konzepte es für die Zugrisverwaltung gibt
und was sie in Bezug auf Aspekte wie Granularität der Rechte, Rechteverwaltung, Feedback für den Benutzer sowie der Sicherheit der verwendeten
Methode bieten. Des Weiteren wird untersucht, auf welche Art und Weise
die Auswirkungen der Autorisierung am sinnvollsten in der Benutzungsoberäche dargestellt werden können.
Ausgangspunkte der Arbeit
Kai Meyer und
Torsten Witte
Authentizierung und Autorisierung
Authentizierung ist die Verizierung der Zughörigkeit der angegebenen Identität zu dem momentanen Benutzer, z.B. über die Angabe eines Benutzernamens und des dazugehörigen Passwortes. Über Autorisierung werden dann
der bestätigten Identität ihre Berechtigungen im System zugeteilt. Diese Berechtigungen können von einfachen Lese-/Schreibzugrien bis hin zur Ausführung komplexer Aktionen reichen.
Zu den bekanntesten Authentizie-
rungs- und Autorisierungskonzepten gehören u.a. RBAC (Role Based Access
Control - 1992: Ferraiolo und Kuhn), XACML (eXtensible Access Control
Markup Language - 2003: OASIS) und speziell für Java JAAS (Java Authentication and Authorization Service - 2004 (seit JDK 1.3): Sun).
Rich-Clients
Im Gegensatz zu herkömmlichen Thin-Clients bieten Rich-Clients eine breitere Palette an nativen GUI-Elementen (Graphical User Interface) und erhöhen somit die Benutzungsfreundlichkeit. Das Arbeiten ohne ständige Serververbindung ist mit Rich-Clients ebenfalls möglich und der Netzwerkverkehr
kann darüber hinaus auch im Online-Betrieb reduziert werden.
Eclipse Rich-Client-Platform
Die Eclipse Rich-Client-Platform (RCP) bietet eine solide Grundlage für heutige Rich-Client-Applikationen und spielt auf diesem Gebiet eine immer stärkere Rolle.
Zum einen ist sie oen für eigene Erweiterungen und zum an-
deren bietet sie bereits viele Mechanismen mit denen schnell und einfach
Motivation
3
Rich-Client-Applikationen entwickelt werden können.
Einige davon lassen
sich unter anderem für die Benutzerautorisierung verwenden.
Ziel der Arbeit
Diese Arbeit gibt einen Überblick über den Stand der aktuellen Diskussio-
Kai Meyer und
nen zu dem Thema Benutzerautorisierung in (Rich-Client-)Anwendungen.
Torsten Witte
Des Weiteren werden eigene konzeptionelle Lösungen für Zugriskontrollmechanismen mit Auswirkungen auf die Benutzungsoberäche erarbeitet und
vorgestellt. Für diese werden in konkreten Projekten softwaretechnische Lösungen entworfen und prototypisch umgesetzt. Dazu kommt die Eclipse RichClient-Platform (RCP) zum Einsatz. Auf Basis dieser Konstruktionen soll es
Anwendungsentwicklern, die die Eclipse RCP einsetzen, auf einfache Weise
möglich sein, Zugriskontrollen in ein Anwendungssystem zu integrieren, so
dass für den Benutzer jederzeit seine gewährten Rechte eindeutig erkennbar
sind. Die mögliche Ausblendung nicht gewährter Aktionen (Menüeinträge,
Schaltächen, usw.) führt zudem zu einer Komplexitätsreduktion der gesamten Benutzungsoberäche.
Vorgehensweise der Autoren
Um das festgesteckte Ziel zu erreichen, haben die Autoren die Literatur
Kai Meyer und
zu den Themen Benutzerautorisierung und benutzergerechte Softwaregestal-
Torsten Witte
tung sowohl innerhalb als auch auÿerhalb des Eclipse-Kontextes durchsucht.
Ebenso wurden gemeinsam Lösungen ermittelt, wie Autorisierung und Benutzungsoberächen miteinander in Wechselwirkung treten können. Die gesammelten Methoden und Konzepte wurden analysiert und anhand ausgewählter Kriterien miteinander verglichen. Dazu haben die Autoren theoretische Szenarien durchgespielt sowie kleine Beispielanwendungen entwickelt
und getestet. Sofern möglich, sind die Autoren mit den Verfassern der für die
Eclipse RCP vorgeschlagenen Techniken in Kontakt getreten. Dazu gehören
Berthold Daum und Je McAer. Vor dem Hintergrund realer Projekte und
mittels der gewonnenen Erkenntnisse entwickelten beide Autoren gemeinsam
Prototypen, die den jeweiligen Anforderungen an die Benutzerautorisierung
gerecht werden.
Die verwendeten Werkzeuge und Beispielprogramme sind
dieser Arbeit auf einer CD beigefügt.
Motivation
4
Aufbau der Arbeit
Kai Meyer und
Die Arbeit gliedert sich in einen Grundlagenteil sowie einen theoretischen
Torsten Witte
und einen praktischen Teil.
Teil 1 - Grundlagen
Um auf die anschlieÿenden Kapitel vorzubereiten, befasst sich der Grundlagenteil mit Begrien und Denitionen, auf die die späteren Kapitel aufbauen.
Ferner wird eine kurze Einleitung in die Eclipse RCP und deren
Plug-In-Konzept gegeben. Die nötigen Grundlagen der Plug-In- bzw. RCPEntwicklung werden an dieser Stelle erklärt.
Teil 2 - Theorie
Der theoretischen Teil beginnt mit einer grundsätzlichen Diskussion über die
Darstellung von Berechtigungen innerhalb von Benutzungsoberächen. Anschlieÿend werden die heute existierenden Authentizierungs- und Autorisierungsmechanismen RBAC (Role Based Access Control), LDAP (Lightweight
Directory Access Protocol), JAAS (Java Authentication and Authorization
Service), XACML (eXtensible Access Control Markup Language), deren Einzelaufgaben und ihr Zusammenspiel vorgestellt und diskutiert. Insbesondere
stellen die Autoren die Möglichkeiten, der Eclipse RCP vor (z.B. Capabilities
und Plug-In-(De-)Aktivierung) und untersuchen in diesem Kontext angesiedelte OpenSource-Lösungen (wie Eclipse-JAAS). Es wird sich mit der Frage
beschäftigt, welche vorhandenen Eclipse-Mechanismen für die Zugrisverwaltung verwendet werden können und was ggf. ergänzt werden muss. Auch
werden hier verschiedene konzeptionelle Lösungen für o.g. Problemstellung
erarbeitet.
Teil 3 - Praxis
Der anschlieÿende praktische Teil beschäftigt sich mit der softwaretechnischen Umsetzung der im zweiten Teil vorgestellten konzeptionellen Lösungen
in Form von Prototypen. Dazu wird ein erweiterbarer Taschenrechner vorgestellt, der als funktioneller Prototyp für das im Anschluss beschriebene
CSS-Projekt dient.
Auÿerdem werden Auszüge aus der Realisierung des
Autorisierungsmechanismus eines Dienstplaner-Systems für ein Alten- und
Pegeheim skizziert.
Motivation
5
Abgrenzung der Arbeit
Komplette Sicherheit wird nur durch Sicherheit auf jeder einzelnen Systeme-
Kai Meyer und
bene (Server, Netzwerk, Client, Betriebssystem) gewährleistet.
Torsten Witte
Der Fokus
dieser Arbeit liegt jedoch überwiegend auf der clientseitigen Benutzerautorisierung. So wird im praktischen Teil vorausgesetzt, dass im Anwendungssystem angemeldete Benutzer korrekt authentiziert sind.
Ebenso werden
Schutzmaÿnahmen gegen Angrie, die sich gegen die zugrunde liegenden
Technologien oder die Programmiersprache Java richten, in dieser Arbeit
nicht behandelt.
Konventionen
Zu Beginn eines Kapitels oder Abschnittes ist am äuÿeren Seitenrand der
Kai Meyer und
Autor vermerkt. Falls verschiedene Autoren Unterabschnitte zu einem Ab-
Torsten Witte
schnitt beitragen, dann ist der jeweilige Autor bei jedem Unterabschnitt angegeben.
Sind dagegen alle Unterabschnitte von dem selben Autor, dann
wird dieser nur zu Beginn des umfassenden Abschnittes genannt.
Bei Textpassagen, die wörtlich oder sinngemäÿ aus Veröentlichungen entnommen wurden, sind am Ende des jeweiligen Abschnitts die zugehörigen
Quellenangaben in eckigen Klammern aufgelistet. Direkte Zitate sind kur-
siv gekennzeichnet. Denitionen oder Kernbegrie eines Abschnittes werden
fett dargestellt.
Der Text enthält meist maskuline Bezeichnungen, um Textpassagen zu vermeiden wie Für einen Anwender/eine Anwenderin, der/die nicht die Berechtigung besitzt, . . . . Frauen sind selbstverständlich ebenfalls gemeint.
Zu Beginn der Erstellung dieser Arbeit war Eclipse in der Version 3.2.2 ak-
1
tuell und Version 3.3 befand sich noch in der Entwicklung . Daher bezieht
sich diese Arbeit auf die zu der Zeit aktuell verfügbaren Version.
1 Eclipse
3.3 wurde am 29.06.2007 veröentlicht.
6
Teil I
Grundlagen
7
Teil 1 - Grundlagen
8
Kai Meyer und
Torsten Witte
Der erste Teil dieser Arbeit liefert die Grundlagen für die nachstehenden
Teile. So ist das erste Kapitel wichtigen Begrien und Denitionen gewidmet, die vorab einen Einstieg in die Thematik bilden.
Das anschlieÿende
zweite Kapitel stellt Rich-Clients und die Eclipse Rich-Client-Platform in
ihren Grundzügen vor. Diese Einführung reicht aus, um selbst Eclipse RCPNeulingen das Verständnis der folgenden Teile zu ermöglichen.
Kapitel 1
Begrie und Denitionen
Die Kernfrage dieser Arbeit handelt von der korrekten und benutzergerechten
Kai Meyer und
Umsetzung von Benutzerrechten innerhalb der Benutzungsoberäche eines
Torsten Witte
Softwaresystems. In diesem Zusammenhang werden einige Begrie verwendet, die an dieser Stelle erläutert werden.
1.1 Benutzer
Am Entwicklungsprozess von Software sind verschiedene Akteure beteiligt.
Dazu gehören neben den Entwicklern, die die Anwendungssoftware konstruieren, auch die
Benutzer, die die Anwendungssoftware am Arbeitsplatz ein-
setzen. Allgemein betrachtet ist ein Benutzer eine natürliche Person, die zur
Erledigung einer Aufgabe ein Hilfsmittel verwendet, um daraus einen Vorteil
zu erzielen. Dabei kann es sich u.a. um Zeitersparnis und Kostenverringerung
handeln. Im IT-Bereich ist also ein Akteur in der Rolle des Benutzers eine
natürliche Person, die zur Erledigung einer Aufgabe ein Softwareprodukt verwendet, um ihre (tägliche) Arbeit schneller und besser erledigen zu können.
In der Regel wird die Benutzerrolle von mehreren Akteuren eingenommen.
Das Leitbild Arbeitsplatz für eigenverantwortliche Expertentätigkeit des
+
Werkzeug- und Material-Ansatzes (WAM) [Z 98] betrachtet Benutzer als
kompetente Akteure und Fachleute in ihrem Arbeitsgebiet.
Nutzer und Endbenutzer als Synonym
Anwender sind dagegen Personen oder Organisa-
Im Folgenden werden die Begrie
für Benutzer verwendet.
tionen, die eine Benutzung veranlassen, ohne unbedingt selbst (direkt) Benutzer zu sein. Die in der Literatur ebenfalls verwendete Bezeichnung
Bediener
ist irreführend, denn eigentlich soll nicht der Benutzer der Software dienen,
sondern umgekehrt. Daher wird der Begri hier vermieden.
+
[Z 98, S.90f ], [Eng93, S.34]
9
Torsten Witte
Teil 1 - Grundlagen
10
1.2 Benutzungsoberächen und Benutzungsfreundlichkeit
Torsten Witte
Damit ein Benutzer mit dem Softwaresystem interagieren kann, ist eine geeignete Schnittstelle notwendig. Diese Mensch-Maschine-Schnittstelle muss
benutzergerecht gestaltet sein, um den Nutzer bei seiner Arbeit nicht zu beeinträchtigen oder gar zu behindern. Dazu haben im Laufe der Zeit neben
Erkenntnissen der Informatik auch solche aus der Medienpsychologie, der
Arbeitswissenschaft, der Kognitionswissenschaft, der (Software-)Ergonomie,
der Soziologie und dem Design beigetragen.
Heutzutage besitzen die meisten interaktiven Systeme
zungsschnittstellen.
grasche Benut-
Fenster, Menüs, Werkzeugleisten, Schaltächen und
Dialoge sind kaum noch vom Bildschirm wegzudenken. In dieser Arbeit werden in diesem Zusammenhang auch die Begrie
User Interface)
oder
Benutzungsoberäche
GUI
(engl.
verwendet.
Graphical
Die weit ver-
breitete Bezeichnung Benutzeroberäche ist etwas unglücklich gewählt, da
es sich bei der Oberäche des Benutzers um seine Haut handelt und nicht
um eine Schnittstelle zwischen Mensch und Maschine.
Auch die wörtliche
Übersetzung von Graphical User Interface, nämlich grasche Benutzerschnittstelle ist nicht ganz treend formuliert. Das Wort Bedienoberäche
wird ebenfalls vermieden (vgl. Bediener in Abschnitt 1.1).
Die einzelnen Menüs und deren Menüpunkte, Werkzeugleisten, Schaltächen,
Eingabe- und Auswahlfelder, Ankreuz-Kästchen, Schieberegler, usw., die in
einer graschen Benutzungsoberäche zu nden sind, werden unter dem Sammelbegri
Interaktionsobjekte zusammengefasst.
Die Gestaltung einer Benutzungsoberäche bezieht sich nicht nur auf deren Layout (Präsentation) oder die Nutzung der unterschiedlichen Interaktionsmöglichkeiten (Handhabung) mit dem Computer. Auch die Vorstellung
oder das Bild, das sich die Benutzer beim Einsatz im jeweiligen Anwendungs+
kontext machen, muss berücksichtigt werden. In [Z 98, S.71] wird dazu das
Benutzungsmodell eingeführt.
Es soll verdeutlichen, mit welchen Mitteln
und auf welche Weise die anstehenden Aufgaben eines Benutzers unterstützt
werden. Ein Benutzungsmodell ist ein fachlich orientiertes Modell darüber,
wie Anwendungssoftware bei der Erledigung der anstehenden Aufgaben im
jeweiligen Einsatzkontext benutzt werden kann. Das Benutzungsmodell umfasst eine Vorstellung von der Handhabung und Präsentation der Software
aber auch von den fachlichen Gegenständen, Konzepten und Abläufen, die
von der Software unterstützt werden.
Benutzungsoberächen und Benutzungsfreundlichkeit
11
Grasche Benutzungsoberächen verwenden Symbole und Metaphern,
um die Interaktion des Menschen mit dem Computer zu erleichtern.
Die
bekannteste Metapher ist die des Schreibtisches oder Desktops. Dort gibt es
einen Arbeitsplatz, an dem symbolisch dargestellte Dokumente mit Hilfe der
Maus ausgewählt und z.B. in einem Ordner oder dem Papierkorb abgelegt
werden können. Objekte aus dem Alltag werden auf Datenobjekte im System
abgebildet und umgekehrt.
Das Prinzip der direkten Manipulation ist auf Shneiderman ([Shn82; Shn83;
Shn87]) zurückzuführen. Durch die Verwendung und Darstellung von konkreten Objekten (z.B. Textdokumenten) lässt sich die Interaktion des Benutzers
mit dem System auf einen relativ kleinen Satz von Operationen beschränken (z.B. Umbenennen, Bearbeiten, Drucken, Löschen). Dies vermittelt den
Eindruck, die am Bildschirm dargestellten Objekte unmittelbar handhaben
zu können. Shneiderman führte die direkte Manipulation als Sammelbegri
für Benutzungsschnittstellen mit folgenden Eigenschaften ein:
•
Permanente Sichtbarkeit aller relevanten Objekte
•
Ersetzung komplexer Kommandos durch physische Aktionen, wie Mausbewegungen, Selektionsaktionen und Funktionstastenbetätigungen
•
Schnelle, umkehrbare, einstuge Benutzeraktionen mit unmittelbarer
Rückmeldung
Das bedeutet aber noch nicht, dass eine grasche Benutzungsoberäche
von vornherein benutzergerecht gestaltet ist.
Dazu muss sie, neben dem
Benutzungsmodell, einige weitere Kriterien erfüllen. Ein wichtiger Aspekt in
der Mensch-Computer-Interaktion ist die
und Hardware (engl.:
usability).
Gebrauchstauglichkeit von Soft-
Hierfür gibt es die im Jahr 2006 über-
arbeitete Norm ISO 9241 Ergonomie der Mensch-System-Interaktion der
International Organization for Standardization [ISO]. Die Norm
deniert, welche Anforderungen an die Gebrauchstauglichkeit von Soft- bzw.
Hardware gestellt werden. Nach Teil 110 Grundsätze der Dialoggestaltung
(ersetzt den bisherigen Teil 10) und Teil 11 Anforderungen an die Gebrauch-
stauglichkeit muss die Schnittstelle folgende Merkmale aufweisen:
•
Aufgabenangemessenheit
•
Selbstbeschreibungsfähigkeit
•
Steuerbarkeit
•
Erwartungskonformität
•
Fehlerrobustheit
•
Individualisierbarkeit
Teil 1 - Grundlagen
12
•
Erlernbarkeit
Als Leitkriterien für die Gebrauchstauglichkeit von Software werden u.a. genannt:
•
Eektivität zur Lösung einer Aufgabe
•
Ezienz der Handhabung des Systems
•
Zufriedenheit der Nutzer einer Software
Im Kontext dieser Arbeit sind besonders die Aufgabenangemessenheit, die
Erwartungskonformität und die Individualisierbarkeit von Bedeutung.
Ein
aufgabenangemessen, wenn er den Benutzer unterstützt, seine
Arbeitsaufgabe eektiv und ezient zu erledigen. Weiter ist ein Dialog erwartungskonform, wenn er konsistent ist und den Merkmalen des BenutDialog ist
zers entspricht, z.B. seinen Kenntnissen aus dem Arbeitsgebiet, seiner Ausbildung und seiner Erfahrung sowie allgemein anerkannten Konventionen.
Ein Dialog ist
individualisierbar, wenn das Dialogsystem Anpassungen an
die Erfordernisse der Arbeitsaufgabe sowie an die individuellen Fähigkeiten
und Vorlieben des Benutzers zulässt.
+
[ZI93, S.9, S.145, S.160 ], [Z 98, S.71], [Sch06]
1.3 Identizierung
Kai Meyer
Identizierung oder auch Identikation ist laut Duden [Dud02] eine Fest-
stellung der Identität . Bei [ITW07] steht unter Identikation: Die Identikation ist die Überprüfung einer Person oder eines Objektes in Bezug auf
vorgelegte, eindeutig kennzeichnende Merkmale, die Identität. Die Begrie
Identikation und Identizierung werden häug synonym verwendet.
Da
der Begri Identikation auch für die Einfühlung in einen anderen Menschen
steht, wird in dieser Arbeit der Begri
Identizierung verwendet.
In einem
Computersystem bedeutet Identizierung somit, dass der aktuelle Benutzer
einer dem System bekannten Identität zugeordnet wird.
Im Standardfall
erfolgt dies durch einfache Eingabe eines Benutzernamens in einem Log-inDialog.
Die Identizierung kann aber ebenso durch die Wiedererkennung
eines Fingerabdrucks geschehen.
noch keine Rechte im System.
Durch diesen Vorgang besitzt die Person
Zuerst muss die Identität noch authenti-
ziert (Abschnitt 1.5) werden, bevor der Benutzer durch die Autorisierung
(Abschnitt 1.6) seine Rechte erhält.
Ein
Identity-Management regelt und organisiert die Identizierung ei-
ner Person oder Prozesses in dem betreenden System.
Das Management
Single Sign-On
13
unterstützt darüber hinaus bei der Verwaltung der Identitäten, besonders
bei Verwendung eines Intranets oder des Internets. Dazu gehört das Erzeugen bzw.
Löschen von Identitäten sowie deren Zuordnung zu Rollen (vgl.
RBAC, Abschnitt 4.1). In groÿen Unternehmen kann dadurch die Zeit, bis
ein neuer Anwender produktiv wird, reduziert werden (siehe auch [SNL06,
S.39]). Des Weiteren kann das Identity-Management die Identitäten anderen
Anwendungen und Services in heterogenen Umgebungen bereit stellen, um
so ein Single Sign-On (SSO) zu gewährleisten.
[ITW07], [Dud02], [SNL06]
1.4 Single Sign-On (SSO)
Gerade groÿe Organisationen arbeiten mit verschiedenen Diensten und Programmen, die durch ein Log-in geschützt sind.
Ein
Single Sign-On
Kai Meyer
er-
spart dem Benutzer, sich bei jedem Service separat anzumelden und sich
ebenso den betreenden Account zu merken.
Auÿerdem beugt es Sicher-
heitsproblemen vor, die dadurch entstehen, dass sich ein Benutzer nicht bei
einem der Dienste abgemeldet hat. Wie schon dem Begri Single Sign-On
zu entnehmen ist, meldet sich der Benutzer nur ein einziges Mal an.
Das
Identity-Management kümmert sich ab diesem Zeitpunkt um die An- sowie
Abmeldung bei allen gestarteten Anwendungen.
Dies erhöht nicht nur die
Sicherheit, sondern steigert auch die Ezienz der Anwendung, da der Arbeitsuss der Benutzer nicht ständig durch einen erneuten Anmeldevorgang
gestört wird.
[SNL06]
1.5 Authentizierung
Ähnlich wie bei Identizierung und Identikation gibt es auch bei der Verwendung der Begrie Authentizierung und Authentisierung Unterschiede,
obwohl sie im normalen Sprachgebrauch oft synonym verwendet werden. Authentizierung ist die Überprüfung (Verizierung) der angegebenen Identität
eines Gegenübers, z.B. einer Person oder eines Computersystems. Authenti-
sieren wird als glaubwürdig, rechtsgültig machen [Dud02] beschrieben. Da
es in dem hier geschilderten Vorgang um die Überprüfung der Identität geht,
wird im weiteren Verlauf der Arbeit der Begri
Authentizierung
ver-
wendet. Für die Authentizierung kann von einer sich anmeldenden Person
abgefragt werden:
Kai Meyer
Teil 1 - Grundlagen
14
•
Wissen, das nur diese Person haben kann (z.B. Passwörter, PINs)
•
Besitz, der der Person zugeordnet werden kann (z.B. Schlüssel, ChipKarten)
•
biometrische Merkmale der Person selbst (z.B. Fingerabdruck, Iris)
Allerdings hat jede Form der Authentizierung ihre Schwachpunkte. Passwörter können geraten oder ausspioniert, Schlüssel bzw. Karten gestohlen und
Scanner für Fingerabdrücke überlistet werden.
Durch Kombinationen der
genannten Merkmale (z.B. Abfrage von Wissen und Besitz) lässt sich die
Sicherheit der Authentizierung erhöhen. Für die richtige Wahl der Authentizierungsverfahren ist nicht nur dieser Aspekt wichtig, sondern auch der
Aspekt der technischen Möglichkeiten. So hat z.B. nicht jeder einen Kartenleser oder Scanner für biometrische Daten an seinem Arbeitsplatz.
Die Grenze zwischen Identizierung und Authentizierung ist manchmal
schwer zu nden. From a technical perspective, most of us get confused when
we try to distinguish between identication and authentication processes.
[SNL06, S.29] Bei einem Log-in-Dialog sind die Verantwortlichkeiten noch
klar erkennbar. Die Eingabe des Benutzernamens ist die Identizierung, die
des Passwortes die Authentizierung.
Doch schon beim Einscannen eines
Fingerabdrucks sind die Grenzen verwischt.
Denn durch das Einlesen des
Fingerabdrucks wird die entsprechende Identität ermittelt, aber ebenso bestätigt, dass die Person auch zu der Identität gehört.
[SNL06], [Dud02], [Sie06]
1.6 Autorisierung
Kai Meyer
Autorisierung
ist die Festlegung, welche Rechte die im System angemel-
dete und somit auch authentizierte Person bekommt. Die Rechte geben an,
welche Funktionen vom Benutzer ausgeführt werden dürfen, welche Dateien
gelesen und geschrieben oder welche Software-Komponenten zur Verfügung
stehen. Um dies zu erreichen, gibt es verschiedene Techniken. Eine der bekanntesten Methoden ist die Verwendung von Access Control Lists (ACLs).
Sie enthalten alle Benutzer und die ihnen gewährten Rechte, wie z.B. Leseoder Schreibrechte. Auch die Zuordnung von Benutzern zu Rollen ist weit
verbreitet. Dabei überprüft die Anwendung, ob ein Angehöriger der Rolle A
Aktion B ausführen darf. Im UNIX-Betriebssystem legt der Erzeuger einer
Datei die Zugrisrechte für alle anderen Benutzer fest. Auf diese Thematik
wird in Abschnitt 1.7 noch weiter eingegangen.
[SNL06]
Rechtevergabe und -entzug
15
1.7 Rechtevergabe und -entzug
Eingangs wurden Benutzer als am Softwareentwicklungsprozess beteiligte
Akteure eingeführt.
sonen.
Wie alle Akteure sind auch Benutzer natürliche Per-
Juristisch gesehen ist eine natürliche Person der Mensch in seiner
Rolle als Rechtssubjekt, d.h. als Träger von Rechten und Pichten. Die sog.
Rechtsfähigkeit beginnt gemäÿ Ÿ1 des Bürgerlichen Gesetzbuches (BGB) mit
der Vollendung der Geburt. Demnach besitzt jeder Mensch von Beginn seines Lebens gewisse Rechte.
In Bezug auf ein Softwaresystem ist das eher die Ausnahme. Schlieÿlich darf
nicht jede natürliche Person bestimmte Daten einsehen oder gar verändern
(schon aus juristischen Gründen). Somit müssen diese Daten vor unberechtigtem Zugri geschützt werden. Den meisten Personen wird also der Zugri
auf alle Daten und Funktionen innerhalb eines Systems bzw. auf das System
selbst verwehrt.
Auch die Benutzer, die auf das System zugreifen dürfen,
besitzen trotzdem nicht die Berechtigung, alles zu tun, und haben nur eingeschränkte Rechte. Lediglich ein Administrator oder der Firmenchef besitzt
alle Rechte, wenn überhaupt.
Sobald eine Rechteverwaltung/Zugriskontrolle in ein System integriert
werden soll, stellt sich eine Reihe von Fragen. Abgesehen von den technischen
Schwierigkeiten, die zu lösen sind, sollte folgendes im Vorfeld geklärt werden:
•
Welche Rechte werden benötigt?
•
Auf welcher Ebene?
(Betriebssystem-, Dateisystem-, Anwendungs-,
Funktions-Ebene)
•
Wer hat das Recht, Rechte zu vergeben?
•
Wer hat das Recht, Rechte zu entziehen?
•
Können Rechte an andere authentizierte Benutzer weitergereicht werden?
Je nach Kontext und Betrachtungsebene belaufen sich die Rechte auf
einfache Lese- und Schreibrechte. Darüber hinaus können zum Einfügen, Löschen und Verändern einzelner Daten eigene Berechtigungen erforderlich sein.
Aus fachlicher Sicht kommen domänenspezische Berechtigungen hinzu, die
meist nur gröÿere Konstrukte der erstgenannten sind.
Zum Beispiel darf
aufgrund der Organisation innerhalb eines Alten- und Pegeheimes nur die
Heimleitung die Freistellungsanträge von Mitarbeitern genehmigen. Vorstellbar ist also das Recht Freistellungsanträge genehmigen für eine bestimmte
Torsten Witte
Teil 1 - Grundlagen
16
Benutzergruppe. Im System kann dies durch eine einfache Schreibberechtigung umgesetzt werden, die sich auf ein Feld mit booleschen Werten (genehmigt/abgelehnt) einer Datenbanktabelle bezieht.
Für die Vergabe und den Entzug von Rechten gibt es unterschiedliche
Autorisierungsstrategien:
•
Zentral: z.B. durch einen Administrator (z.B. bei Mandatory Access
Control (MAC))
•
Dezentral: durch verschiedene Benutzer (i.d.R. bei Discretionary Access Control (DAC))
•
Eigentümerprinzip: Der Erzeuger eines Objektes wird sein Eigentümer
und kann Rechte am Objekt vergeben/entziehen
•
Hierarchisch dezentralisiert: Eine zentrale Autorität vergibt Administratorrechte für einzelne Teile der Anwendung an Sub-Administratoren
•
Kooperativ: Die Vergabe von Rechten ndet nur in Zusammenarbeit
einer Gruppe von Benutzern statt (4-Augen-Prinzip)
Ebenso existieren verschiedene Methoden für die Menge der vergebenen
Berechtigungen zu einem Zeitpunkt:
•
Need-to-know: Jeder Benutzer bekommt nur die Rechte, die er höchstens braucht.
•
Minimum privilegies: Über das Need-to-know Prinzip hinaus bekommt
jeder Nutzer nur die Rechte, die er aktuell braucht.
Gerade der Entzug von Rechten führt weitere Fragen mit sich.
Falls
Benutzer ihre Rechte an andere Benutzer weiterreichen können, sollen dann
weitergereichte Rechte ebenfalls entzogen werden, wenn dem Benutzer, der
ein Recht weitergereicht hat, das betreende Recht entzogen wird?
Unabhängig davon ist zu klären, welche Auswirkungen sich für den Benutzer
ergeben. Folgendes Szenario ist vorstellbar: Ein Benutzer bearbeitet gerade
ein Dokument (weil er die Befugnis hat) und ihm wird währenddessen dieses
Recht entzogen.
Ab wann gilt der Entzug des Rechtes?
Sofort oder erst
nach einem Neustart der Anwendung? Wann wird der Benutzer darüber in
Kenntnis gesetzt und was passiert mit dem bearbeiteten Dokument? Es gibt
verschiedene, mehr oder weniger sinnvolle, Möglichkeiten:
1. Es erscheint sofort ein Meldungsfenster mit einem entsprechenden Hinweis.
Rechtevergabe und -entzug
17
a. Der Benutzer kann noch weiter arbeiten und seine Änderungen an
diesem Dokument abspeichern.
b. Der Benutzer kann noch weiter arbeiten, wird aber nicht abspeichern können.
c. Das Dokument wird geschlossen und alle Änderungen rückgängig
gemacht.
2. Erst beim Speichern erscheint eine Meldung über die fehlende Berechtigung.
a. Das aktuelle Dokument wird noch gespeichert.
b. Das aktuelle Dokument wird nicht gespeichert und alle Änderungen verworfen.
3. Beim nächsten Önen des Dokumentes erscheint eine Meldung über die
entzogenen Rechte.
a. Bei der vorherigen Bearbeitung wurde das Dokument noch gespeichert.
b. Bei der vorherigen Bearbeitung wurde das Dokument nicht gespeichert und alle Änderungen verworfen.
Sicherlich gibt es noch weitere Varianten.
Aus Benutzersicht ist wohl eine
möglichst schnelle Rückkopplung wünschenswert, ohne die aktuelle Arbeit
zu unterbrechen.
Die Beantwortung dieser Fragen hängt gewiss davon ab,
wie oft Rechte (während des laufenden Betriebs) entzogen werden.
Einige der genannten Fragen werden häug auf Datenbank-Ebene diskutiert, um den Zugri auf die darin enthaltenen Daten zu schützen.
Viele
Datenbanksysteme bieten vernünftige Lösungen an, so dass diese in der eigenen Anwendung nur aufgegrien werden brauchen. Dadurch besteht der
Schutz sehr nah an den Daten selbst. Allerdings ist damit noch kein Bezug
zu der Benutzungsoberäche der eigenen Anwendung geschaen.
Im (aus
Entwicklersicht) einfachsten Fall erhält der Benutzer entsprechende Meldungen erst, wenn es aus seiner Sicht zu spät ist (nämlich nach getaner Arbeit)
und kann dennoch die verwehrte Aktion innerhalb der GUI jederzeit erneut
anwählen.
Auf jeden Fall sollte die Rechteverwaltung von Beginn der Entwicklung
an mit in die Architektur der Anwendung einbezogen werden. Dies erspart
unnötige Arbeit und erhöht die Sicherheit des Systems.
[Sch05, S.39], [Bru04, Kap.7]
Teil 1 - Grundlagen
18
1.8 Filterregeln bei Autorisierung
Torsten Witte
Zum Schutz vor Angrien aus einem anderen Netzwerk (z.B. dem Internet)
werden Firewalls eingesetzt. Diese lassen lediglich bestimmte Dienste in das
lokale Netzwerk durch.
Filterregeln. Die
Für diese Autorisierung von Diensten gibt es zwei
Verbotsregel besagt, dass als gefährlich eingestufte Dien-
ste verboten werden. Dies ist ein sehr einfaches Verfahren. Dienste, die nicht
explizit verboten werden, bleiben erlaubt und werden nicht in ihrer Ausführung behindert. Riskante Dienste können dabei allerdings übersehen werden.
Um dies zu vermeiden, ist es sicherer, nach der
Erlaubnisregel vorzugehen.
Dabei werden von vorn herein alle Dienste verboten und nur die als sicher
eingestuften Dienste erlaubt.
Diese Filterregeln lassen sich von dem Firewall-Kontext auch auf die Benutzerautorisierung übertragen. Nach der Verbotsregel werden einem Benutzer
grundsätzlich alle Dienste erlaubt und nur bestimmte Funktionalitäten oder
Komponenten verboten.
Im Gegensatz dazu werden dem Benutzer analog
zur Erlaubnisregel generell alle Dienste verboten und nur bestimmte erlaubt.
[Bru04, Kap.3]
1.9 Zusammenfassung
Kai Meyer und
Die in diesem Kapitel genannten Begrie und Denitionen bilden das Basis-
Torsten Witte
vokabular und die Grundlage für diese Arbeit. Sie wurden hier vorgestellt,
um von Anfang an Missverständnissen vorzubeugen, da einige Begrie in der
Literatur unterschiedlich verwendet werden. Im weiteren Verlauf dieser Arbeit werden die Begrie durchgehend verwendet:
Benutzer werden von einem Softwaresystem authentiziert, um ihre Identität zu bestätigen. Ein Single Sign-On erleichtert dabei den Anmeldevorgang
bei anwendungsübergreifenden Systemen.
Über die Autorisierung erhalten
die Benutzer ihre Berechtigungen innerhalb des Systems.
Dies kann über
unterschiedliche Strategien und Filterregeln realisiert werden.
Wenn die Benutzer ihren Aufgaben nachkommen, interagieren sie über die
Benutzungsoberäche und Interaktionsobjekte mit der Anwendung. Die Oberäche sollte daher für eine benutzergerechte Gestaltung bestimmte Kriterien
erfüllen und ein passendes Benutzungsmodell umsetzen, um die Benutzer
nicht bei ihrer Arbeit zu behindern.
Das nächste Kapitel liefert einen Einblick in eine weitere Grundlage dieser
Arbeit: die Eclipse Rich-Client-Platform.
Kapitel 2
Die Eclipse Rich-Client-Platform
Dieses Kapitel behandelt Grundlagen von Rich-Clients, Eclipse und der
Torsten Witte
Eclipse RCP. Es ist nicht das Ziel, Eclipse oder die Entwicklung von EclipseRich-Clients in vollem Umfang und bis in das letzte Detail zu erläutern,
sondern lediglich einen kurzen Einblick zu geben und auf spätere Kapitel
vorzubereiten.
2.1 Was ist ein Rich-Client?
Ein Rich-Client ist ein Ableger des Fat-Clients mit reichhaltigeren Problemlösungen.
Er bietet die Vorteile eines Fat-Clients sowie einige eines Thin-
Clients ohne zusätzliche Nachteile.
Um einen Rich-Client genauer denieren und abgrenzen zu können, ist es
daher nötig, zuerst die Begrie Thin-Client und Fat-Client zu klären.
In einer Client-Server-Architektur haben
Thin-Clients nur die Aufgabe,
die Daten darzustellen, die sie vom Server erhalten.
Diese Daten werden
meist in Form von HTML-Dateien über das Intra- bzw. Internet übertragen.
Zudem übernehmen Thin-Clients die Interaktion mit dem Benutzer, d.h. die
Eingabe über Formulare. Daher reicht ein gängiger Webbrowser auf Clientseite aus. Die gesamte Logik der Anwendung bendet sich auf dem Server.
Vorteile von Thin-Clients:
•
Kaum bis gar kein Installationsaufwand des Clients, denn Webbrowser
sind bereits in den meisten Betriebssystemen integriert.
•
Reduzierung des Trainingsaufwandes, da jeder seinen bevorzugten Webbrowser verwenden kann und das Benutzungsmodell für alle Anwendungen gleich ist.
19
Torsten Witte
Teil 1 - Grundlagen
20
•
Anwendungen können leicht über das Internet zur Verfügung gestellt
werden. So können Mitarbeiter auch von zu Hause aus arbeiten.
•
Änderungen, die auf dem Server durchgeführt werden, werden automatisch und ohne Installationsaufwand von allen Clients übernommen.
•
Benutzungsoberächen sind relativ einfach und günstig zu implementieren.
Nachteile von Thin-Clients:
•
Reine HTML-Seiten sind statisch und nur sehr wenige Dialogelemente
1
stehen zur Verfügung. Darunter leidet die Benutzungsfreundlichkeit.
•
Thin-Clients können nur Online verwendet werden. Der Server ist die
einzige Datenquelle, die sie besitzen.
•
Sie sind nicht geeignet für Anwendungen, die einen groÿen Rechenaufwand für die Darstellung benötigen.
Diese Aufgabe überschreitet
meistens die Rechenleistung des Servers. Auÿerdem ist der Durchsatz
des Datentransfers begrenzt.
Ein
Fat-Client ist das Gegenstück zum Thin-Client.
Zu einem Fat-Client
werden zu der API (Application Programming Interface) auch die dazugehörige Hardware, und deren Abstraktionsschicht (engl. Hardware Abstraction
Layer, HAL) gezählt. Ein Fat-Client ist also weder hardware-, noch plattformunabhängig. Auÿerdem erfüllt er nur die vom Server erwartete Aufgabe.
Dabei wird der Server jedoch so weit wie möglich entlastet, denn die eigentliche Datenverarbeitung wird clientseitig durchgeführt. Die grasche Benutzungsoberäche wird ebenfalls von dem Client zur Verfügung gestellt. Für
exible Anwendungen ist ein Fat-Client demnach allerdings nicht geeignet.
Aktualisierungen sind ebenfalls aufwendig.
Um nun die Vorteile beider Client-Architekturen zu nutzen und den Nachteilen entgegenzuwirken, bietet sich der
Rich-Client
an.
Rich-Clients be-
sitzen ein robustes Komponentenmodell, das durch Module und Plug-Ins
erweiterbar ist. So löst ein Rich-Client nicht nur ein Problem (was bei FatClients üblich ist), sondern kann auch noch artverwandte oder gar artfremde
Probleme lösen. Idealerweise können fremde Lösungen (z.B. von verschiedenen Anbietern) innerhalb eines Rich-Clients zusammen arbeiten, so dass sie
wie eine einzige Anwendung erscheinen. Software-Entwickler und -Anbieter
1 Dieser
Umstand hat zur Entwicklung vieler neuer Technologien beigetragen, die in
HTML eingebettet werden. Da sind u.a. zu nennen: Applets, JavaScript, ActiveX, Flash.
Alle diese Techniken haben ihre Vor- und Nachteile.
Was ist ein Rich-Client?
21
können mit Hilfe von Rich-Client-Plattformen auch sogenannte Rich-ClientDistributionen aus bestimmten Modulen/Plug-Ins bündeln und bestimmten
Benutzergruppen fertig zur Verfügung stellen. So erhält Benutzergruppe 1
eine Anwendung, die aus Plug-In
für Benutzergruppe 2 aus Plug-In
A und B besteht, während die Anwendung
B und C zusammengesetzt ist.
Eigenschaften und Aufgaben von Rich-Clients:
•
Robustes Komponentenmodell
•
Erweiterbarkeit
•
Anpassungsfähigkeit an den Endbenutzer
•
Anpassungsfähigkeit an verschiedene Geräte (Hardwareunabhängigkeit)
•
Sowohl Online- als auch Oine-Arbeiten möglich
•
Einfache Verteilung an Endbenutzer
•
Einfache Aktualisierung des Clients
•
Komplexe (native) Benutzungsoberäche
•
Entlastung des Servers
•
Lokale Datenhaltung
•
Anwendungslogik auf Clientseite
•
Synchronisation der lokalen Daten mit dem Server
Kurz zusammengefasst sollte ein Rich-Client alles können, was eine übliche Desktop-Anwendung zu bieten hat und zusätzlich die Kommunikation
mit einem Server gestatten. Darüber hinaus sollen alle denkbaren Vorteile
der Serveranbindung zur Geltung gebracht werden.
[KB06, S.8 ], [Dau05b, S.1 ], [Bea05], [Bur05]
Teil 1 - Grundlagen
22
2.2 Was ist die Eclipse Rich-Client-Platform?
In short, Eclipse is an ideal technology for building rich client
applications.
Je McAer, Jean-Michel Lemieux [ML06, S.25]
Torsten Witte
Die Eclipse Rich-Client-Platform (RCP) ist eine erweiterbare Plattform für
die Entwicklung und den Einsatz von nativen Java-Anwendungen. Mit ihrer
Hilfe können schnell und einfach Rich-Client-Anwendungen erstellt werden.
Die Eclipse RCP stellt bereits die Infrastruktur für die Entwicklung einer
kompletten Rich-Client-Anwendung zur Verfügung.
Beispielsweise können
vorgefertigte Plug-Ins für einen Update-Mechanismus oder ein Hilfesystem
verwendet werden. Das UI-Framework sorgt durch SWT (Standard Widget
Toolkit) und JFace für native GUI-Elemente. Somit können sich Rich-ClientEntwickler ganz auf ihre Problem-Domäne konzentrieren. The RCP part is
easy; it's your domain that is hard. [ML06, S.59]
Merkmale der Eclipse RCP:
•
Plattform für die Entwicklung und den Einsatz von Rich-Client-Anwendungen
•
beschleunigt die Desktop-Entwicklung
•
beinhaltet Equinox, ein auf dem OSGi-Standard basierendes Komponenten-Framework
•
durch das zugrunde liegende Plug-In-Modell können Anwendungsmerkmale über eine groÿe Produktpalette hinweg gemeinsam verwendet werden
•
das Plug-In-Modell ermöglicht verteilte Entwicklung, auch über geograsch und organisatorisch getrennte Teams hinweg
•
ist fähig, native GUI-Anwendungen auf einer Vielzahl von Betriebssystemen einzusetzen, wie z.B. Windows, Linux oder Mac OSX
•
integrierter Update-Mechanismus für den Einsatz von Desktop-Anwendungen von einem zentralen Server aus
•
bietet Oenheit und Flexibilität gegenüber eigenen Erweiterungen
•
Verwaltung von Benutzerpräferenzen
[ML06], [Dau05b], [MA06]
Zur Entstehungsgeschichte der Eclipse RCP
23
2.2.1 Zur Entstehungsgeschichte der Eclipse RCP
Eclipse [Ecla] wurde im November 2001 von IBM veröentlicht und ist seit
dem frei verfügbar.
Es war zunächst als eine Plattform für Softwarewerk-
zeuge geplant und bis Version 2.1 auch nur als solche interessant. In Version
3.0 wurde die gesamte Plattform neu organisiert. Die bis dahin proprietäre
Ablaufumgebung wurde auf die standardisierte OSGi-Plattform umgestellt
2
(Equinox ).
Die IDE (Integrated Development Environment) wurde vom
Kern getrennt. Der Kern ist sehr klein und hat nur die Aufgabe, Plug-Ins
zum Ablauf zu bringen.
Die Eclipse RCP besteht aus der Laufzeitumge-
bung, SWT, JFace und der Generic Workbench (siehe Abschnitt 2.3). This
is a generic platform for running applications. [ML06, S.5] Die Eclipse-IDE
selbst ist nur noch eine spezische Rich-Client-Anwendung auf Basis dieser
RCP. Zur Zeit der Erstellung dieser Arbeit ist Eclipse in der Version 3.2.2
verfügbar.
[Dau05b, S.9f, S.25 ], [ML06, S.6f, S.13f, S18f ], [Equ]
2.2.2 Open Service Gateway Initiative (OSGi)
Der Zweck der Open Service Gateway Initiative (OSGi) [OSG] ist die
Standardisierung von Diensten, die auf lokalen Netzwerken und eingebetteten Geräten zum Einsatz kommen sollen. OSGi-konforme Dienste können auf
OSGi-konformen Servern ausgeführt werden. Der Ablaufkern von Eclipse arbeitet als ein solcher OSGi-Server. Der Vorteil dieser Ablaufumgebung liegt
unter anderem darin, dass Hot Plugging möglich ist, also der Austausch von
Bundles im laufenden Betrieb.
Bundles (zu deutsch Bündel) sind Java-
Module; im Fall von Eclipse sind es die Plug-Ins.
A bundle is a plug-in.
A plug-in is a bundle.
They are the same thing. [ML06, S.18] Im weite-
ren Verlauf dieser Arbeit wird daher im OSGi-Kontext von Bundles und im
Eclipse-Kontext von Plug-Ins die Rede sein, obwohl das selbe gemeint ist.
[Dau05b, S.9f, S.26f ], [ML06, S.18f ]
2.2.3 Erfolg der Eclipse RCP
Die Eclipse RCP spielt auf dem Gebiet der Rich-Client-Anwendungen eine
immer gröÿere Rolle. Laut einer Umfrage von Evans Data [Eva] im September 2006 ist die Akzeptanz der Eclipse Rich-Client-Platform gegenüber einer
2 Equinox
ist eine Implementierung der OSGi R4.0-Spezikation, eine Menge von Bundles die verschiedene optionale OSGi-Dienste und die übrige Infrastruktur zur Ausführung
OSGi-basierter Systeme zur Verfügung stellt.
Teil 1 - Grundlagen
24
früheren Untersuchung aus dem Jahr 2005 um 130% gestiegen. 22% der rund
400 Teilnehmer gaben an, dass sie bereits Rich-Client-Anwendungen basierend auf der Eclipse RCP erstellen. 69% gaben an, innerhalb der nächsten
sechs Monate mit Eclipse RCP arbeiten zu wollen.
[MA06], [Unb06]
2.3 Die Eclipse Plug-In-Architektur
Everything in Eclipse is a plug-in. An RCP application is a collection of
plug-ins and a Runtime on which they run.
Je McAer, Jean-Michel Lemieux [ML06, S.13]
Torsten Witte
Eine Plattform unterscheidet sich von einer erweiterbaren Anwendung dadurch, dass die Plattform lediglich eine kleine Laufzeitumgebung zur Verfügung stellt, auf der die einzelnen Komponenten ablaufen, die die eigentliche
Anwendung ausmachen.
Dadurch ist die Anwendung kein fester Klotz,
sondern exibel und einzelne Komponenten können leicht ausgetauscht werden (siehe Abbildung 2.1). Genau das bietet auch die Eclipse Rich-Client-
(a) Erweiterbare Anwendung
(b) Plattform
Abbildung 2.1: Erweiterbare Anwendung vs. Plattform [ME05, S.4]
Platform. Die einzelnen Plug-Ins werden zu einer gesamten Anwendung zusammengesteckt und auf der Laufzeitumgebung, der Eclipse RCP, ausgeführt.
Plug-Ins
25
Abbildung 2.2: Eclipse-Plattform [Dau05a, S.347]
An dieser Stelle sei ein kurzer Blick auf die Eclipse-Plattform in Abbildung 2.2 geworfen. Der dunkel gekennzeichnete Teil entspricht der Laufzeitumgebung aus Abbildung 2.1(b). Er macht bis auf einige Komponenten der
Generic Workbench die Eclipse RCP-Minimaldistribution aus. Die Generic
Workbench stellt die Kernfunktionalität der Rich-Client-Platform dar.
Sie
verwaltet die globalen Menü- und Werkzeugleisten, Editoren, Views, Präferenzen, Wizards usw.
Somit stehen diese Funktionen jeder Rich-Client-
Anwendung zur Verfügung.
Der hellere Teil in der Grak entspricht den
Plug-Ins aus Abbildung 2.1(b) und enthält die Komponenten für die EclipseIDE. Diese Komponenten können auch für eigene Rich-Client-Anwendungen
wiederverwendet werden (z.B. die Plug-Ins
Help
und
Update).
Im Weiteren werden die Konzepte der einzelnen Bestandteile der EclipseArchitektur vorgestellt.
[Dau05a], [ME05], [ER05]
2.3.1 Plug-Ins
Ein
Plug-In bildet die kleinste Einheit in der Eclipse RCP-Architektur, die
eine Funktion bereitstellt und getrennt von anderen Komponenten entwickelt
und ausgeliefert werden kann.
Für gewöhnlich wird ein kleines Werkzeug
Kai Meyer
Teil 1 - Grundlagen
26
durch ein Plug-In realisiert, während komplexe Werkzeuge aus mehreren
Plug-Ins bestehen.
So ist z.B. fast die gesamte Funktionalität der Eclipse
Plattform in Plug-Ins enthalten. Nur der Kern, also die Platform Runtime,
ist kein Plug-In. Die einzelnen Plug-Ins können selbstständig ihre Aufgaben
durchführen oder andere Plug-Ins benutzen beziehungsweise deren Funktionalität erweitern.
Die Anbindung eines Plug-Ins an den Rest des Systems
wird über die Extension-Registry (siehe Abschnitt 2.3.3) geregelt.
Grundsätzlich besitzt jede RCP-Anwendung ein bestimmtes Plug-In, welches als
Anwendungs-Plug-In oder RCP-Plug-In bezeichnet wird.
Die-
ses Plug-In konguriert die RCP-Anwendung und identiziert die Anwendung gegenüber der Eclipse Rich-Client-Platform (siehe dazu Abschnitt 2.4.3).
Um Plug-Ins besser strukturieren zu können, sieht die Eclipse RCP Fragmente und Features vor.
Fragmente sind im Gegensatz zu Plug-Ins keine eigenständigen Komponenten.
So besitzen sie auch keine korrespondierende Repräsentation auf der
OSGi-Plattform. Fragmente bieten lediglich weitere Funktionalitäten zu einem existierenden Plug-In an.
Dazu gehören unter anderem Sprachpakete
und ergänzende Funktionen für andere Betriebssysteme oder Datenbanken.
Der Vorteil von Fragmenten ist, dass sie unabhängig vom Rest des Plug-Ins
erstellt und somit auch zu einem späteren Zeitpunkt ausgeliefert werden können.
Ein
Feature
hingegen dient der Gruppierung von mehreren Plug-Ins, die
eine abgeschlossene Funktionsgruppe bilden. Darüber hinaus werden Features für Update-Sites (siehe Abschnitt 2.5) benötigt. Eigenen Code besitzt ein
Feature nicht, sondern liefert lediglich weitere Information zu den Plug-Ins,
die dieses Feature beinhaltet.
[Dau05b, S.59], [Dau05a, S.439 ], [Ecl06]
2.3.2 Lebenszyklus von Bundles/Plug-Ins
Torsten Witte
Wie das Zustandsdiagramm in Abbildung 2.3 auf Seite 28 zeigt, kann ein
OSGi-Bundle im Verlauf seines Lebens bis zu sieben verschiedene Zustände
einnehmen:
•
Deployed: Ein Bundle ist aufgeboten, wenn es physikalisch auf der
Festplatte vorhanden ist.
Es kann vorkommen, dass ein Bundle le-
diglich auf einem Server aufgeboten ist und nie auf der ausführenden
Maschine vorhanden sein wird. Dieser Zustand wird formal nicht vom
System repräsentiert.
Daher ist er in Abbildung 2.3 nur als schwar-
zer Punkt vermerkt.
Dennoch wird der Begri verwendet, um über
Bundles zu sprechen, die installiert werden könnten.
Lebenszyklus von Bundles/Plug-Ins
•
27
Installed: Ein installiertes Bundle ist aufgeboten und im OSGi-Framework enthalten, so dass es ausgeführt werden kann. Im Fall von Eclipse
werden die Registerbeiträge (engl. registry contributions) installierter
Plug-Ins noch nicht zu der Extension-Registry (siehe Abschnitt 2.3.3)
hinzugefügt.
•
Resolved: Damit ein Bundle den Zustand Aufgelöst erreichen kann,
muss es installiert sein.
Da ein Bundle von anderen Bundles abhän-
gig sein kann, müssen zusätzlich alle vorausgesetzten Bundles ebenfalls
aufgelöst sein. Innerhalb der Eclipse-Laufzeitumgebung sind die Registerbeiträge aufgelöster Plug-Ins in die Extension-Registry eingebunden.
Aufgelöste Bundles können vollständig betriebsbereit sein.
Es
kann aber vorkommen, dass so ein Bundle nie gestartet wird, da kein
Programmcode aus dem Bundle aufgerufen wird.
•
Starting: Ein aufgelöstes Bundle wechselt in den aktiven Zustand indem es startet. Es bleibt in diesem Zustand bis die start()-Methode
des Bundle-Activator vollständig ausgeführt wurde
(siehe Abschnitt 2.4.2).
•
Active:
Ein aktives Bundle ist aufgelöst gewesen und die start()-
Methode wurde erfolgreich durchgeführt.
Aktive Bundles sind voll-
ständig betriebsbereit.
•
Stopping: Aktive Bundles wechseln zurück in den aufgelösten Zustand
indem sie angehalten werden. In diesem Zustand bleiben sie solange
die stop()-Methode des Bundle-Activator ausgeführt wird.
•
Uninstalled: Bundles erreichen den Zustand Deinstalliert nur, wenn
sie bereits im installierten Zustand gewesen sind und deinstalliert werden. Sollte das Bundle sogar aktiv geworden sein, muss es erst angehalten werden, um deinstalliert werden zu können. Deinstallierte Bundles
benden sich immer noch im System. Sie sind nicht von der Festplatte
gelöscht und beim nächsten Start der Plattform wieder verfügbar (Installed).
In dem Diagramm ist ebenfalls dargestellt, dass Bundles nur in den Zuständen Installed und Resolved aktualisiert werden können. Das bedeutet, dass bereits aktive Bundles gestoppt werden müssen, bevor eine Aktualisierung stattnden kann. Ein aktualisiertes Bundle bendet sich nach dem
Update stets wieder im Zustand Installed.
Dementsprechend müssen die
betreenden Bundles neu aufgelöst werden, um sie wieder in die (laufende)
Anwendung einzubinden. Weitere Informationen zu Updates in der Eclipse
RCP benden sich in Abschnitt 2.5.
Teil 1 - Grundlagen
28
Abbildung 2.3: Lebenszyklus von Bundles [ML06, S.460]
Für die Beobachtung und Steuerung, der in einer Eclipse RCP vorhandenen
Plug-Ins eignet sich die OSGi-Konsole (Anhang B.2.2). Der Lebenslauf der
Eclipse-Workbench ist in [ML06, S.217 ] dargestellt. Der Lebenslauf einer
ganzen Eclipse-Rich-Client-Anwendung ist in [ML06, S.475 ] beschrieben.
[ML06, S.455, S.459f ]
2.3.3 Extension-Points, Extensions und ExtensionRegistry
Torsten Witte
Ein
Erweiterungspunkt
oft auch als Steckdose
(engl.
extension
bezeichnet) deniert eine
Schnittstelle eines Plug-Ins.
Diese Schnittstelle kann
von (anderen) Plug-Ins in Form von
(engl.
diese
alle
Erweiterungen
extensions; bei obiger Metapher als Stecker
bezeichnet) erfüllt werden.
ster
point;
(engl.
Das
Erweiterungsregi-
extension registry) von Eclipse verwaltet
Beziehungen
zwischen
Erweiterungspunkte
Plug-Ins.
und
aufgelösten Plug-Ins registriert.
Hier
Erweiterungen
sind
aller
Jede Eclipse RCP-
Anwendung besitzt so ein Register. Die nebenstehende
Abbildung wurde aus [ME05, S.11] entnommen.
Plug-Ins bieten sich selbst für Erweiterungen an. Such a plug-in is es-
sentially saying, If you give me the following information, I will do . . . [ML06, S.21].
Dazu deklarieren sie Erweiterungspunkte.
Andere Plug-Ins
liefern dann die benötigte Information zu diesen Erweiterungspunkten über
Extension-Points, Extensions und Extension-Registry
Erweiterungen.
29
In welchen Relationen Plug-Ins zu Erweiterungen stehen
können, listet Azad Bolour in [Bol03, Abschnitt 2.3.2] auf:
1. Ein Plug-In kann mehrere Erweiterungspunkte anbieten
2. Ein Plug-In kann sowohl Erweiterungspunkte als auch Erweiterungen
anbieten
3. Mehrere Plug-Ins können einen Erweiterungspunkt erweitern
4. Ein Plug-In kann den selben Erweiterungspunkt mehrmals erweitern
5. Ein Plug-In kann verschiedene Erweiterungen für unterschiedliche PlugIns vorsehen
6. Eine einzige Erweiterung eines einzelnen Plug-Ins kann mehrere Callback-Objekte erzeugen (siehe Abschnitt 2.4.5)
7. Ein Plug-In kann Erweiterungen zu seinen eigenen Erweiterungspunkten
anbieten
Auf diese Weise entstehen Abhängigkeiten zwischen Plug-Ins, die einer Anbie+
ter-Kunde-Beziehung gleichen (vgl. Vertragsmodell [Z 98, S.45]). Wie Abhängigkeiten zwischen Plug-Ins aufgebaut sein können, ist in Abschnitt 2.3.4
beschrieben.
Die Vorteile von Erweiterungspunkten und Erweiterungen sind:
•
Sie werden lediglich deklarativ angegeben. Dadurch können sie geltert, überprüft und zusammengesetzt werden.
•
Sie unterstützen Lazy-Loading. Plug-Ins, die Erweiterungen beitragen,
können im System präsent sein, ohne dass es nötig ist, ihren Code zu
laden.
•
Sie können zur Laufzeit hinzugefügt und entfernt werden.
•
Der Mechanismus kann verwendet werden, um Code und/oder Daten
beizutragen.
Die Eclipse RCP bietet bereits einen Satz von Erweiterungspunkten an. Einige davon sind in Abschnitt 2.4.4 aufgelistet.
Zusätzlich können eigene
(domänenspezische) Erweiterungspunkte deniert werden.
In Abschnitt 2.4.5 wird ein tieferer Blick auf die Verwendung und das Zusammenspiel von Extension-Points, Extensions und Extension-Registry auf
programmiertechnischer Ebene geworfen.
[ML06, S.21, S.392 ], [ME05], [Bol03]
Teil 1 - Grundlagen
30
2.3.4 Plug-In-Abhängigkeiten
Torsten Witte
Plug-Ins önen sich für andere Plug-Ins, indem sie Erweiterungspunkte anbieten und Teile ihrer Paketstruktur und somit die darin enthaltenen Klassen
und Schnittstellen veröentlichen. Dies hat den Vorteil, dass andere Plug-Ins
diese Klassen und Schnittstellen verwenden können. Somit können Plug-Ins
über die denierten Schnittstellen miteinander kommunizieren (wie in Abschnitt 2.4.5 zu sehen). Auch muss Logik nur einmal implementiert werden,
da vorhandene (Hilfs-)Klassen wiederverwendet oder erweitert werden können.
(a)
(b)
(c)
Abbildung 2.4: Plug-In-Abhängigkeiten
Verwendet z.B. ein Plug-In
Plug-Ins
A
oder importiert
direkten Abhängigkeit von
B
B
B
einen Erweiterungspunkt eines anderen
die Paketstruktur von
B zu A (vgl.
A,
führt dies zu einer
Abbildung 2.4(a)). D.h. ohne
A kann
A
nicht den Zustand Aufgelöst erreichen (siehe Abschnitt 2.3.2). Plug-In
kann dagegen auch ohne Plug-In
B
aktiv werden.
B kann aber auch zu einem anderen Plug-In A beitragen, ohne
davon direkt abhängig zu sein. Dabei wird der Weg über ein drittes Plug-In C
gegangen (Abbildung 2.4(b)). Der Erweiterungspunkt org.eclipse.ui.popupMenus des UI-Plug-Ins erlaubt zum Beispiel, Menüpunkte in Kontextmenüs
anderer Plug-Ins hinzuzufügen. Wenn B einen Menüpunkt zu A hinzufügt,
sind beide Plug-Ins (A und B) direkt von dem UI-Plug-In (also C) abhängig: B, weil es eine Klasse vom Typ IActionDelegate anbietet und den
Extension-Point erweitert (beides kommt aus C), und A, weil es ebenfalls zur
Ein Plug-In
Benutzungsoberäche beiträgt. Somit können beide Plug-Ins ohne das dritte
Plug-In
C
nicht gestartet werden.
Trotzdem sind
A
und
B
unabhängig voneinander.
Falls sich nur
B
in der
Einleitung
31
Laufzeitumgebung bendet, verlaufen die Beiträge zu
A
jedoch nicht. Sollte nur Plug-In
A ins Leere.
wird dieses normal ausgeführt, ohne irgendwelche Beiträge von
ist
B
nicht verfügbar und
A
weiÿ nichts von
B.
B. Schlieÿlich
Erst wenn beide Plug-Ins in
der Laufzeitumgebung angemeldet sind, sind die Beiträge von
von
A
Dies stört
in der Umgebung vorhanden sein, dann
B
innerhalb
vorzunden.
Plug-Ins sind in der Lage, ihre eigenen Abhängigkeiten an Dritte weiterzureichen.
Benötigt Plug-In
B
z.B. Schnittstellen von Plug-In
A,
da es
sich selbst für Erweiterungen zur Verfügung stellt, für die diese Schnittstellen benötigt werden, dann kann Plug-In
mögliche erweiternde Plug-Ins von
B
B
(hier
die Abhängigkeit zu Plug-In
C)
A
an
durchreichen. Auf diese Weise
sind Plug-Ins nur noch von dem Plug-In direkt abhängig, das sie erweitern.
Die Struktur unterhalb des durchreichenden Plug-Ins muss dabei nicht bekannt sein (vgl. Fassade [GHJV95, S.212]).
C
kann ohne
A
und ohne
B
nicht existieren. Da
stieren kann, reicht es aus, wenn
bleibt
C
von
A
C
nur von
B
B
ebenfalls ohne
A
nicht exi-
direkt abhängig ist. Indirekt
abhängig (siehe Abbildung 2.4(c)).
2.4 Eclipse-Architektur in der Praxis
In den folgenden Abschnitten wird erläutert, wie ein Plug-In intern aufgebaut ist, wie Plug-Ins zueinander in Beziehung treten und wie die einzelnen
Funktionen einer zu entwerfenden Anwendung auf Plug-Ins abgebildet werden sollten.
Seit Eclipse-Version 3.1 erleichtert die Plug-In Development Environment
(PDE) die Entwicklung von Rich-Client-Anwendungen. PDE stellt einfach
zu bedienende Werkzeuge wie Wizards und Formular-Editoren zur Verfügung.
Diese unterstützen Entwickler beim Entwickeln, Testen, Beseitigen
von Fehlern (debugging), Aufbau und Einsatz von Eclipse Plug-Ins. Durch
die PDE ist es möglich, schnell und ohne viel Kenntnis der inneren Strukturen (XML-Tags usw.) eigene Rich-Client-Anwendungen zu erzeugen. So ist
es nur bedingt nötig, zu wissen, welche Daten in welche Datei gehören, oder
die erforderlichen XML-Dateien von Hand zu schreiben. Dennoch wird an
einigen Stellen in dieser Arbeit (wie hier) ein kurzer Blick in diese Dateien
geworfen, um Zusammenhänge zu verdeutlichen und so das Verständnis zu
erleichtern.
[MG03]
Torsten Witte
Teil 1 - Grundlagen
32
2.4.1 Aufbau von Plug-Ins
Kai Meyer
Der Ausspruch Everything in Eclipse is a plug-in. [ML06, S.13] ist zwar
korrekt, kann allerdings auch irreführend sein. Ist nun alles in Eclipse ein
einziges Plug-In oder sollte jede noch so kleine Funktion ein neues Plug-In
bilden? Diese Frage ist nicht ganz einfach zu beantworten, da es in Eclipse
durchaus die Möglichkeit gibt, dass ein Plug-In nur aus dem OSGi- und dem
Plug-In-Manifest (siehe Abschnitt 2.4.2) besteht.
Aber es ist ebenso vor-
stellbar, dass die gesamte Anwendung in einem einzigen Plug-In steckt. Hier
ist zu empfehlen, dass die Plug-Ins gemäÿ ihren fachlichen Aufgaben und
in Übereinstimmung mit der Architektur erstellt werden. Ein Plug-In sollte
eine bestimmte Funktion anbieten und dazu alle benötigten Komponenten
(Hilfeseiten, Icons, Schematas, . . . )
beinhalten.
Abgesehen von den Plug-
Ins, die den Kern der Anwendung bilden, sollte das Fehlen eines bestimmten
Plug-Ins lediglich dazu führen, dass in der laufenden Anwendung nur genau
diese Funktionalität fehlt. Dies ermöglicht es zusätzlich, ein Plug-In gezielt
ohne Seiteneekte durch ein anderes zu ersetzen, welches die gleiche Aufgabe
erfüllt, aber von einem anderen Anbieter sein kann.
Als Vorbild für die Strukturierung der Plug-Ins können die Schichten einer
Schichtenarchitektur dienen. Zudem erweist sich eine Unterteilung in PlugIns für die Geschäftslogik und Plug-Ins für die Benutzungsoberäche oft als
sinnvoll.
Fragmente und Features, die der besseren Strukturierung von Plug-Ins dienen, werden in den Abschnitten 2.4.6 und 2.4.7 beschrieben.
[Dau05a, S.439 ]
2.4.2 OSGi-Manifest, Plug-In-Manifest und BundleActivator
Kai Meyer
manifest.mf und die plugin.xml sind fester Bestandteil jedes Plug-Ins.
Die
Diese beiden Dateien steuern die Einbettung der Plug-Ins in die Workbench
und beschreiben den Aufbau der Plug-Ins.
Das
OSGi-Manifest
manifest.mf
enthält seit Eclipse 3.1 eine Beschrei-
bung des Plug-Ins und dessen Beziehung zum Rest der Welt innerhalb der
OSGi-Umgebung. So sind hier u.a. folgende Daten zu einem Bundle festgehalten:
•
der Name des Bundles
•
ein symbolischer Name (als Id)
OSGi-Manifest, Plug-In-Manifest und Bundle-Activator
•
die Versionsnummer
•
der Bundle-Activator
•
die benötigten Bundles
•
die durchgereichten Bundles
•
die veröentlichten Pakete dieses Bundles
33
In älteren Versionen von Eclipse standen sämtliche Informationen nur in der
plugin.xml,
die auch als
Plug-In-Manifest
bezeichnet wird. Das OSGi-
Manifest wurde daraus bei jedem Start neu generiert.
Doch seit Eclipse
3.1 enthält die in XML (eXtensible Markup Language) geschriebene Datei
plugin.xml
nur die neu denierten Erweiterungspunkte, einen Verweis auf
deren Schemata sowie die von einem Plug-In angesprochenen Erweiterungspunkte.
Zur Veranschaulichung, wie diese Dateien aussehen, folgen Auszüge aus
der
manifest.mf
und der
plugin.xml
aus dem
DienstplanRCP-Plug-In
Dienstplaner-Projektes, welches in Kapitel 7 genauer erläutert wird.
Quellcode 2.1: manifest.mf
Manifest−Version: 1.0
Bundle−ManifestVersion: 2
Bundle−Name: DienstplanRCP Plug−in
Bundle−SymbolicName: DienstplanRCP; singleton:=true
Bundle−Version: 1.0.0
Bundle−Activator: dienstplanrcp.DienstplanerPlugin
Bundle−Localization: plugin
Require−Bundle: org.eclipse.ui; visibility: =reexport,
org. eclipse .core.runtime; visibility: =reexport,
org. eclipse .update.congurator,
org. eclipse . ui .forms; visibility: =reexport,
org. eclipse .update.core; visibility: =reexport,
org. eclipse .update.ui,
DP_Server_Jar;visibility:=reexport
Eclipse −LazyStart: true
Export−Package: dienstplanrcp,
dienstplanrcp.actions ,
dienstplanrcp.comparator,
dienstplanrcp.dnd,
...
dienstplanrcp.widgets.tree
des
Teil 1 - Grundlagen
34
Quellcode 2.2: plugin.xml
<?xml version="1.0" encoding="UTF−8"?>
<?eclipse version="3.2"?>
<plugin>
<extension−point id="canShowDienstplan"
name="Can Show Dienstplan"
schema="schema/canShowDienstplan.exsd"/>
...
<extension−point id="navigationPerspective"
name="Navigations
Perspective"
schema="schema/navigationPerspective.exsd"/>
<extension
id="dienstplanerID"
point="org.eclipse.core.runtime.applications">
<application>
<run
class ="dienstplanrcp.Dienstplaner">
</run>
</application>
</extension>
Der
Bundle-Activator bildet die Verbindung zwischen der OSGi-Plattform,
den Bundles, der Workbench und den zu diesem Plug-In gehörenden Objek-
org.eclipse.core.org.eclipse.ui.plugin.AbstractUIPlugin,
ten. Der Activator ist entweder eine Unterklasse von
runtime.Plugin
oder von
falls das Plug-In mit einer Benutzungsoberäche ausgestattet ist.
nur einen Bundle-Activator pro Plug-In gibt, wird er auch oft als
Klasse bezeichnet.
Da es
Plug-In-
Zudem wird der Activator meist als Singleton (vgl. dazu
[GHJV95, S.157]) implementiert. Zur Regulierung des Lebenszyklusses wer-
start(BundleContext context), stop(BundleContext context) sowie getBundle() angeboten (siehe dazu auch Abschnitt 2.3.2). Des Weiteren
den
beinhaltet der Activator Methoden für die Ressourcen- und Benutzungso-
getPluginPreferences(), getStateLocation(), getDialogsettings(), getWorkbench() und imageDescriptorFormPlugin().
berächenverwaltung. Dazu gehören
[ML06, S.16 ], [Dau05a, S.363]
2.4.3 Anwendungsklassen
Torsten Witte
Jede RCP-Anwendung muss mindestens eine Anwendungsklasse am Erweiterungspunkt
org.eclipse.core.runtime.applications
deklarieren. Üb-
licherweise wird dies in dem Anwendungs-Plug-In der RCP-Anwendung gemacht. Anwendungsklassen implementieren das
IPlatformRunnable-Inter-
OSGi-Manifest, Plug-In-Manifest und Bundle-Activator
face und stellen eine
run()-Methode bereit3 .
35
Das Interface dient dazu, seine
Implementatoren gegenüber Eclipse als Eintrittspunkt der Anwendung zu
identizieren.
Die
run()-Methode
ist dabei vergleichbar mit der
main()-
Methode einer einfachen Java-Anwendung.
Es ist durchaus möglich, mehrere Eintrittspunkte zu spezizieren. Welcher
der Eintrittspunkte beim Start von Eclipse aktiv werden soll, lässt sich über
eine kleine Kongurationsdatei auÿerhalb des Plug-Ins nachträglich steuern.
Eine minimale Anwendungsklasse mit einer typischen Implementierung der
run()-Methode
sieht so aus:
import org.eclipse.core.runtime.IPlatformRunnable;
import org.eclipse.swt.widgets.Display;
import org.eclipse.ui.PlatformUI;
public class Application implements IPlatformRunnable {
public Object run(Object args) throws Exception {
}
Display display = PlatformUI.createDisplay();
try {
int returnCode = PlatformUI.createAndRunWorkbench(display,
new ApplicationWorkbenchAdvisor());
if (returnCode == PlatformUI.RETURN_RESTART) {
return IPlatformRunnable.EXIT_RESTART;
}
return IPlatformRunnable.EXIT_OK;
} nally {
display .dispose ();
}
}
Zunächst wird über die Klasse
PlatformUI
zeugt, welches die Bildschirmanzeige repräsentiert.
Advisor
Display-Exemplar erDann wird der Workbench-
ein neues
generiert, der für die Konguration der Benutzungsoberäche zu-
ständig ist. Anschlieÿend wird die Workbench über
RunWorkbench() gestartet.
PlatformUI.createAnd-
Wenn die Workbench wieder beendet wird, wird
deren Rückgabewert noch in das OSGi-konforme
IPlatformRunnable-Proto-
koll übersetzt.
[Dau05b, S.59 ], [ML06, S.48f ]
3 In
Eclipse 3.3 ist das Interface IPlatformRunnable als deprecated markiert. Stattdessen wird das Interface IApplication mit einer start()-Methode verwendet.
Teil 1 - Grundlagen
36
2.4.4 Wichtige Erweiterungspunkte von Eclipse
Kai Meyer
Nun folgt ein Auszug aus der in [Dau05a, S.369 ] aufgeführten Liste der
von Eclipse bereitgestellten Erweiterungspunkte. Die hier vorgestellte Auswahl ist grundlegend für die Gestaltung der Benutzungsoberäche einer RCPAnwendung. Zudem werden sie im weiteren Verlauf der Arbeit eingesetzt.
Eine Beschreibung für das Anlegen von Extension-Points und deren Schematas bendet sich in [Dau05a] ab Seite 367.
•
-.ui.actionSets
- Ein
actionSet
fasst Aktionen (Actions) zu einer
Gruppe zusammen. Eine Aktion ist in Eclipse eine abstrakte Benutzeraktion, die verschiedene Erscheinungsformen annehmen kann, wie
Menüs, Menüpunkte oder Werkzeuge auf der Werkzeugleiste. Ein angelegtes ActionSet kann über diesen Extension-Point mit all seinen Actions in ein von einem anderen Plug-In deniertes Menü eingefügt werden.
•
-.ui.activities - Über diesen Erweiterungspunkt kann die Benutzungsoberäche skaliert und somit in ihrer Komplexität reduziert werden.
Capabilities erlauben es, verschiedene Menüeinträge, Views, Editoren,
Perspektiven usw. logisch zu gruppieren und nur die Gruppen anzuzeigen, die vom Benutzer in seinem aktuellen Aufgabenkontext benötigt
werden. Eine genauere Beschreibung ist in Abschnitt 6.3 zu nden.
•
-.ui.perspectives / -.ui.perspectiveExtension - Mit dem Erweiterungspunkt
perspectives können neue Perspektiven in die Workbench
eingebracht werden. Eine Perspektive gibt die Anordnung von Editoren, Views und Menüs in der Workbench vor. Die in dem ExtensionPoint angegebene Klasse erzeugt das anfängliche Layout der Perspektive, wobei der Benutzer in der Lage ist die Anordnung der Views und
Editoren innerhalb der Perspektive nach seinen Vorlieben individuell
zu gestalten und neue Views hinzugefügen bzw.
nen kann. Mit
perspectiveExtension
vorhandene entfer-
lassen sich bereits vorhandene
Perspektiven um weiteren Komponenten anreichern.
•
-.ui.views
/
-.ui.viewActions
- Mit
die Workbench eingeführt werden.
views
können neue Views in
Views gewähren in Eclipse eine
bestimmte Sicht auf die Arbeitsmaterialien.
So können verschiedene
Views auf dem gleichen Material arbeiten, dabei aber verschiedenen
Aspekte in den Vordergrund stellen.
Mit
viewActions
Aktionen (Menüpunkte und Werkzeuge [...])
können neue
in bereits bestehende
Views eingeführt werden.
•
-.ui.editors
/
-.ui.editorActions
- Die Extension-Points
editors
Eine Beispiel-Erweiterung
und
37
editorActions verhalten sich analog zu views und viewActions,
nur werden hier Editoren der Workbench hinzugefügt.
2.4.5 Eine Beispiel-Erweiterung
Zur Erklärung, wie Extension-Points und Extensions im Code aufgebaut werden und das Zusammenspiel mit der Extension-Registry auf programmiertechnischer Ebene funktioniert, folgt ein einfaches Beispiel, das häug in der
Literatur auftaucht. Das Beispiel zeigt, wie ein Plug-In eine Aktion hinter
einem Menüpunkt innerhalb des Anwendungsmenüs unterbringen kann.
org.eclipse.ui bietet den Erweiteorg.eclipse.ui.actionSets an, um eine Menge von Menü-
Das Eclipse-User-Interface-Plug-In
rungspunkt
und Werkzeugleisteneinträgen zu der Benutzungsoberäche der Anwendung
hinzuzufügen. Damit verpichtet sich das UI-Plug-In, Beiträge von Plug-Ins
zu dem ActionSet-Erweiterungspunkt zu verwalten und zu bearbeiten. Die
plugin.xml des org.eclipse.ui-Plug-Ins enthält also folgenden Eintrag:
<?xml version="1.0" encoding="UTF−8"?>
<plugin>
...
<extension−point id="actionSets"
name="Action Sets"
schema="schema/actionSets.exsd"/>
...
</plugin>
An dieser Stelle ist eine Extension-Point Schema Denition (.exsd-Datei)
angegeben. Diese Datei enthält wiederum die eigentliche Denition des Erweiterungspunktes in Form eines XML-Schemas. U.a. wird speziziert, welche Attribute angegeben werden müssen und welche optional sind.
Dazu
gehören Pfad-Angaben zu Java-Klassen oder anderen Ressourcen (z.B. Bilder) und Zeichenketten.
Diese Zeichenketten können Repräsentationen für
boolesche Ausdrücke, Zahlen oder Texte sein.
Wie die
actionSets.exsd
genau aussieht, lässt sich in [Bol03, Abschnitt 2.3.3] nachlesen.
Die
manifest.mf
eines erweiternden Plug-Ins (hier
MyPlugin)
muss den
folgenden Eintrag enthalten, da sonst der benötigte Erweiterungspunkt und
das
IActionDelegate-Interface
nicht verfügbar sind.
Require−Bundle: org.eclipse.ui;
Hier wird auch die Abhängigkeit von
(vgl. Abschnitt 2.3.4).
MyPlugin
zu dem UI-Plug-In deutlich
Torsten Witte
Teil 1 - Grundlagen
38
Die
plugin.xml
von
MyPlugin
sieht entsprechend der o.g. Schema De-
nition so aus:
<?xml version="1.0" encoding="UTF−8"?>
<plugin>
...
<extension
point="org.eclipse. ui .actionSets">
<actionSet
id="org.myApplication.myPlugin.myActionSetId"
label="My ActionSet">
<action
id="org.myApplication.myPlugin.myActionId"
class ="org.myApplication.myPlugin.MyAction"
icon="icons/myAction.gif"
label="My Action"
menubarPath="myMenu"/>
<action
id="..."
class ="..."
label="..."/>
</actionSet>
</extension>
...
</plugin>
In diesem Fall wird für jede Aktionsmenge (actionSet) mindestens ein ein-
deutiger Bezeichner (id) und ein Name (label) benötigt. Für die einzelnen
Aktionen (action) wird jeweils eine Id (id), ein Menütext (label), ein grasches Symbol (icon) und eine Klasse des Typs
IActionDelegate (class)
angegeben. Diese Klasse implementiert die durchzuführende Aktion. Zusätzlich können noch weitere Attribute angegeben werden, z.B. an welcher Stelle
der Menüeintrag im Menü auftauchen soll (menubarPath).
Das UI-Plug-In durchsucht das Erweiterungsregister der Eclipse RCPAnwendung nach Beiträgen zu seinem Erweiterungspunkt. Dazu muss es im
Quellcode auf das Erweiterungsregister der Plattform zugreifen, welches über
folgenden Aufruf zu erhalten ist:
IExtensionRegistry registry = Platform.getExtensionRegistry();
IExtensionRegistry-Exemplar kann mit einer der getConfigurationElementsFor()-Methoden das Register nach Erweiterungen für einAn diesem
zelne Erweiterungspunkte durchsucht werden.
UI-Plug-In mit seinem Erweiterungspunkt.
Objekte des Typs
Genau das macht auch das
Die Suchergebnisse werden als
IConfigurationElement zurückgeliefert. Von diesen ObgetAttribute(String attrName)-
jekten sind die Attributwerte durch die
Fragmente
39
Methode in Form von
String-Objekten
erhältlich.
Soll ein Exemplar ei-
ner in der Erweiterung angegebenen Klasse erzeugt werden, kann dies mit
dem Aufruf von
createExecutableExtension(String propertyName)
ge-
schehen, wobei lediglich der Name des Attributes angegeben werden muss.
getExtension() oder getExtensionPoint()
IExtensionRegistry-Exemplar sind auch Objektrepräsentationen
Über die Methoden
an dem
der Er-
weiterungen und Erweiterungspunkte selbst zu beziehen.
Sind alle Erweiterungen zu einem Extension-Point gefunden und ausgewertet, können sie entsprechend behandelt werden.
Das UI-Plug-In wird den
Menütext und das Symbol jeder Aktion in der Benutzungsoberäche darstellen. Sobald der Benutzer mit der Maus auf so einen Menüeintrag klickt,
wird ein Exemplar der zugehörigen Klasse erzeugt, auf ein
IActionDelegate
run()-Methode aufgerufen.
der konkreten IActionDelegate-Klasse
gecastet und dessen
So ein Exemplar
(hier
MyAction)
wird auch als Callback-Objekt bezeichnet, da es von dem erweiterbaren
Plug-In erzeugt und dann zurückgerufen wird (vgl.
Don't call us, we call you.).
Hollywood-Prinzip:
Das Beispiel veranschaulicht auch den Lazy-
Mechanismus von Eclipse. Das konkrete Objekt wird erst erzeugt, wenn es
wirklich benötigt wird. In diesem Fall, wenn ein Benutzer auf den Menüeintrag klickt und die
run()-Methode
ausgeführt werden soll.
Abbildung 2.5
veranschaulicht den Aufbau und Ablauf von Erweiterungen nochmals grasch.
Abbildung 2.5: Erweiterungen [ML06, S.21]
[ML06, S.21f, S.392 ]
2.4.6 Fragmente
Fester Bestandteil jedes
Fragmentes
Datei ist vom Aufbau her der
ist die
plugin.xml
fragment.xml.
sehr ähnlich.
Diese XML-
Die wichtigsten
Kai Meyer
Teil 1 - Grundlagen
40
Angaben in der
fragment.xml
sind die Identikation und die Version des
Plug-Ins, auf das sich dieses Fragment bezieht. Eine eigene Plug-In-Klasse
darf ein Fragment in keinem Fall besitzen, da ein Fragment auf der OSGiPlattform keinen eigenen Namensraum bekommt, sondern vollständig mit
dem zugehörigen Plug-In verschmilzt. Eine Beschreibung, wie ein Fragment
angelegt wird, ist in [Dau05a, S.439] zu nden.
[Dau05a, S.439]
2.4.7 Features
Kai Meyer
In Eclipse besteht ein
Feature
aus dem Namen des Features, einer mög-
lichst eindeutigen Id, einer Angabe der Version, sowie dem Anbieter des
Features (Feature Provider ) und einer Liste der beinhalteten Plug-Ins. Ferner kann auch ein Branding-Plug-In und eine URL zur Update-Site (siehe
Abschnitt 2.5) speziziert werden. Das Branding-Plug-In enthält Daten für
die Produktanpassung. Dazu gehören unter anderem Grsken und weitergehende Beschreibungen für das Feature. Für das Feature kann ebenso festgelegt werden, für welchen Betriebs- und Windowing-Systeme oder für welche
Sprachen die enthaltenen Plug-Ins ausgelegt sind.
Zusätzlich können eine
genaue Beschreibung des Features sowie Urheberrechtsinformationen und Lizenzbedingungen hinterlegt werden.
Eine aus dem Dienstplaner-Projekt (siehe Kapitel 7) entliehene
sieht so aus:
<?xml version="1.0" encoding="UTF−8"?>
<feature
id="Feature_Admin"
label="Admin Feature"
version="1.0.0">
<description>
[Enter Feature Description here .]
</description>
<copyright>
[Enter Copyright Description here.]
</copyright>
<license>
[Enter License Description here .]
</license>
<url>
<update label="Dienstplaner Products"
url=" le: /localhost/UpdateSite"/>
</url>
<requires>
<import plugin="org.eclipse.ui"/>
feature.xml
Update-Sites und Updates
41
<import plugin="org.eclipse.core.runtime"/>
<import plugin="DienstplanRCP"/>
</requires>
<plugin
id="DP_BenutzerAuister"
download−size="0"
install −size="0"
version="1.0.0"
unpack="false"/>
<plugin
id="DP_EinstellungenEditor"
download−size="0"
install −size="0"
version="1.0.0"
unpack="false"/>
...
</feature>
[Dau05a, S.440 ]
2.5 Update-Sites und Updates
Eine
Update-Site ist eine Quelle im Inter- oder Intranet, die Features und
deren Plug-Ins in verschiedenen Versionen zum Download und zur Installation anbietet. Zu Testzwecken kann eine Update-Site auch auf der lokalen
Festplatte eingerichtet werden.
Im wesentlichen besteht eine Update-Site aus einem Verzeichnis für die beinhalteten Features, einem für deren Plug-Ins, sowie eine
site.xml
site.xml.
können unter anderem:
•
Gruppen zur besseren Strukturierung für Features angelegt
•
Features diesen Gruppen zugeordnet
•
die Versionsnummern der Features übernommen
•
die URL für diese Update-Site angegeben
•
und eine Beschreibung dieser Site hinterlegt
werden.
In der
Bevor eine Update-Site betriebsbereit ist, muss für die einzelnen
Features erst der Build-Prozess angestoÿen werden.
Die
site.xml
für die
Update-Site, die im Dienstplaner (siehe Kapitel 7) Verwendung ndet, sieht
wie folgt aus:
Kai Meyer
Teil 1 - Grundlagen
42
<?xml version="1.0" encoding="UTF−8"?>
<site>
<description url=" le: /localhost/UpdateSite">
Dienstplaner UpdateSite
</description>
<feature url="features/Feature_Admin_1.0.0.jar"
id="Feature_Admin" version="1.0.0">
<category name="Dienstplaner"/>
</feature>
<feature url="features/Feature_Core_1.0.0.jar"
id="Feature_Core" version="1.0.0">
<category name="Dienstplaner"/>
</feature>
<feature url="features/Feature_Dienstplan_1.0.0.jar"
id="Feature_Dienstplan" version="1.0.0">
<category name="Dienstplaner"/>
</feature>
...
<category−def name="Dienstplaner"
label="Dienstplaner Category"/>
</site>
Update-Sites können mit Hilfe der Eclipse-PDE recht einfach erstellt werden.
Eine genauere Beschreibung dieses Vorgangs ist in [Dau05a, S.448 ]
aufgeführt.
Eclipse bietet bereits die Möglichkeit vorhandene Features zu aktualisieren oder neue Features zu installieren. Zwar lassen sich die zu den Features
gehörenden Plug-Ins auch einfach in Eclipse hinein kopieren, aber wird der
in Eclipse enthaltene Update-Manager verwendet, so ergeben sich einige Vorteile. Zum einen zeigt der Manager alle Features und deren Plug-Ins an, die
auf den angegebenen Update-Sites vorhanden sind, wodurch die Auswahl des
richtigen Plug-Ins erleichtert wird. Zum anderen kann der Update-Manager
vor der Installation überprüfen, ob benötigte Plug-Ins vorhanden sind oder
ob Versionskonikte auftreten. Darüber hinaus ist es möglich, benötigte aber
noch nicht auf der lokalen Festplatte vorhandene Plug-Ins mit einem Druck
auf Add required Plugins zusammen mit dem gewünschten Plug-In herunterzuladen. Selbstverständlich muss dafür die Update-Site diese Plug-Ins
anbietet. Der Update-Manager ist zudem in der Lage, die auf der UpdateSite hinterlegte Lizenzbedingung dem Benutzer vorzulegen und zur Annahme
aufzufordern.
In Eclipse ist der Update-Manager über
Updates → Find and Install...
Help → Software
zu erreichen.
Die Suche nach Updates kann manuell von dem Benutzer oder von der
Anwendung automatisiert ausgelöst werden. Diese automatischen Updates
Abschlieÿende Bemerkungen
43
können beim Starten der Anwendung, beim Beenden oder zu bestimmten
Zeitpunkten erfolgen. Es ist sogar denkbar, dass eine Administration über
das Netzwerk diesen Vorgang startet. Jede Variante birgt ihre eigenen Vorund Nachteile. Wird beim Start nach Updates gesucht, so sind immer die
aktuellsten Versionen in Benutzung.
die benötigte Zeit für das Starten.
Allerdings verlängert dieser Vorgang
Auÿerdem kann es passieren, dass ein
Neustart der Anwendung erforderlich ist, sofern neue Versionen gefunden
wurden.
Wird erst beim Schlieÿen der Anwendung nach Updates gesucht,
ist kein Neustart erforderlich.
Jedoch wurde in diesem Fall die ganze Zeit
mit einer alten vielleicht fehlerhaften Version gearbeitet. Des Weiteren
wird in dieser Variante mehr Zeit für das Beenden des Programms benötigt.
Trit der Benutzer die Entscheidung, wann nach Updates gesucht wird, so
ist dies oft ezienter. Doch kann er bei Verwendung des Standard-UpdateManagers auch auf Update-Sites zugreifen, die nicht gewünschte Inhalte anbieten.
Ebenso kann es vorkommen, dass der Benutzer nie oder nur sehr
spärlich die Programmkomponenten aktualisiert.
Die Initialisierung des Update-Vorgangs über das Netzwerk ist die programmtechnisch anspruchsvollste. Denn es muss ein Weg gefunden werden, der erlaubt, Updates durchzuführen, ohne den angemeldeten Benutzer zu stören
oder seine bereits gemachte, aber noch nicht gesicherte Arbeit zu verwerfen.
Zusätzlich muss die Anwendung aktiv sein, wenn die Auorderung zum Update kommt. Ebenso muss für den Initiator des Vorganges erkennbar sein,
auf welchen Rechnern noch keine neuen Versionen installiert wurden.
[Dau05a, S.440 ]
2.6 Abschlieÿende Bemerkungen
Die Eclipse Rich-Client-Platform ist ein sehr groÿes Themengebiet, das hier
Kai Meyer und
nur in Auszügen behandelt werden kann. Weitere interessante Gebiete wären:
Torsten Witte
Perspektiven, Views, Editoren, Wizards, Verwendung von SWT, JFace und
Forms, Denition eigener Produkte, Internationalisierung, Verwaltung von
Benutzerpräferenzen usw. Als weiterführende Literatur ist hierfür [Dau05a;
Dau05b; Dau06; ML06] zu empfehlen. Ebenso ist eine Trennung der Entwicklungs- und der Zielplattform ratsam, um während der Entwicklung von Anwendungen auf Basis der Eclipse RCP beide Plattformen unabhängig voneinander kongurieren oder sogar austauschen zu können (siehe [ML06, S.30 ]).
Die in diesem Kapitel vorgestellten Begrie und Konzepte sind notwendig,
um die im theoretischen und praktischen Teil beschriebenen Konzepte und
Realisierung von und für die Eclipse RCP nachvollziehen zu können.
44
Teil II
Theoretischer Teil
45
Teil 2 - Theorie
46
Kai Meyer
In diesem Teil soll geklärt werden, wie die Benutzer eines Softwaresystems
autorisiert und die Auswirkungen der Autorisierung dem Benutzer kenntlich
gemacht werden können.
Dazu werden zunächst die grundsätzlichen Varianten für die grasche Repräsentation von Interaktionsobjekten im Rahmen der Benutzerautorisierung
beschrieben. Es werden ihre Vor- und Nachteile geschildert und wie sich die
jeweilige Variante auf das Verhalten eines Benutzers auswirken könnte. Anschlieÿend werden aktuelle Diskussionen zu diesem Thema zusammengefasst
und ihre Ergebnisse dargelegt.
In Kapitel 4 erfolgt eine Beschreibung bereits existierender Autorisierungsmechanismen. Innerhalb der Beschreibung wird ebenfalls untersucht in wie
weit sie Bezug auf die Benutzungsoberäche nehmen und ob sie sich für den
Einsatz in einem Rich-Client eignen.
Danach werden zwei grundlegende Konzepte vorgestellt, die die Anbindung
der graschen Benutzungsoberäche bereits beinhalten, und unter welchen
Umständen sie eingesetzt werden können.
Als Abschluss dieses Teils werden Lösungen innerhalb der Eclipse RCP vorgestellt.
Kapitel 3
Diskussionen
Dieses Kapitel greift unterschiedliche Diskussionen auf, deren Ergebnisse den
Torsten Witte
weiteren Verlauf dieser Arbeit beeinussen. Zunächst wird der richtige Einsatz von Interaktionsobjekten bei Benutzerautorisierung unter Aspekten der
benutzergerechten Softwaregestaltung diskutiert. Daraufhin wird nochmals
auf die Wichtigkeit von Gebrauchstauglichkeit gerade im Zusammenhang mit
Autorisierung eingegangen. Im Anschluss wird der aktuelle Diskussionsstand
über Benutzerautorisierung innerhalb der Eclipse RCP ermittelt. Die dort
vorgestellten Methoden und Lösungen werden später in Kapitel 6 näher betrachtet.
3.1 Interaktionsobjekte bei der Benutzerautorisierung
Im Zusammenhang mit Benutzerautorisierung ist es für die Gebrauchstaug-
Kai Meyer und
lichkeit besonders wichtig, die Benutzungsoberäche an die Berechtigungen
Torsten Witte
des aktuellen Benutzers anzupassen. In diesem Abschnitt werden die dafür
möglichen Darstellungsformen von Interaktionsobjekten und deren Verhalten
innerhalb der Oberäche diskutiert.
Dies geschieht ohne Berücksichtigung
von vorhandenen technischen Realisierungen und der Machbarkeit.
Die in
Abschnitt 1.2 geforderten Kriterien für benutzergerechte Softwaregestaltung
werden mit in die Diskussion einbezogen, um diese soweit wie möglich zu
erfüllen.
Das folgende einleitende Beispiel hat noch keinen Bezug zu Benutzerautorisierung, illustriert aber schon die Wege und Schwierigkeiten der Oberächengestaltung:
In MS-Word 2003 ist die Speichern-Schaltäche beispielsweise immer aktiv,
selbst wenn das geönete Dokument gerade gespeichert wurde. Somit erhält
47
Teil 2 - Theorie
48
der Benutzer kein Feedback über den aktuellen Bearbeitungszustand eines
Dokumentes.
Andererseits werden selten verwendete Menüpunkte aus Menüs weg geblendet und tauchen erst nach längerem Aufenthalt innerhalb des Menüs wieder
auf. Das vereinfacht die Benutzungsschnittstelle, da sie sich an die Gewohnheiten des Benutzers anpasst, und reduziert die Fehlerhäugkeit. Die Ausblendung einiger Menüpunkte kann aber auch zu verzweifelten Suchaktionen führen.
Im Folgenden werden kleine Szenarios gebildet, die verschiedene Varianten der Darstellung und des Verhaltens von Interaktionsobjekten bei nicht
gewährtem Zugri aufzeigen.
Anhand dieser Szenarien werden die Konse-
quenzen für den Benutzer und die Gebrauchstauglichkeit der Software diskutiert.
3.1.1 Meldungsfenster
Szenario 1.
Ein Benutzer klickt mit der Maus auf eine Schaltäche in der
Benutzungsoberäche.
Daraufhin erscheint ein Meldungsfenster mit dem
Hinweis, dass der Benutzer für diese Aktion nicht berechtigt ist.
Das Anzeigen eines Meldungsfensters aufgrund nicht-autorisierten Zugris ist die einfachste und wohl am meisten verwendete Variante der Rückmeldung an den Benutzer. Für die Realisierung dieses Verhaltens wird lediglich ein Mechanismus benötigt, der die auftretenden Zugrisverweigerungen
an der Oberäche darstellt. Alle Interaktionsobjekte der Anwendung bleiben
von den Benutzerberechtigungen unberührt.
Wie in dem Beispiel zu erkennen ist, erfährt der Benutzer erst nachdem
er die Aktion ausgelöst hat, dass er keine Berechtigung dafür besitzt. Dies
ist inezient und behindert ihn in seinem Arbeitsuss, weil er nicht nur die
Zeit vergeudet hat, auf die Schaltäche zu klicken, sondern zusätzlich das
Meldungsfenster schlieÿen muss. Auÿerdem widerspricht dieses Systemverhalten seinen vorhandenen Erfahrungen aus anderen Anwendungen, in denen
er jede hinter einem anwählbaren Interaktionsobjekt liegende Aktion ausführen kann. Der Benutzer muss demzufolge mühsam durch Versuch und Irrtum
erlernen, welche Aktionen er in welcher Rolle ausführen darf.
Zur Verbesserung ist statt einem einfachen Meldungsfenster ein Log-in-Dialog
denkbar. Mit diesem kann sich der Benutzer unter einer anderen Rolle anmelden, die für die jeweilige Aktion berechtigt ist.
Des Weiteren ist eine
Kombination mit optischen Kennzeichnungen vorteilhaft.
Interaktionsobjekte bei der Benutzerautorisierung
49
3.1.2 Log-in-Dialog
Szenario 2.
Ein Benutzer klickt mit der Maus auf eine Schaltäche in der
Benutzungsoberäche. Daraufhin erscheint ein Log-in-Dialog, der darauf hinweist, dass diese Aktion mit der aktuellen Benutzerkennung nicht durchgeführt werden darf. Über den Dialog ist der Benutzer in der Lage, sich (kurzfristig) mit einer anderen Nutzerkennung anzumelden. Nach erfolgreichem
Log-in wird die Aktion sofort ausgeführt.
Das hier vorgestellte Prinzip ist dem Meldungsfenster sehr ähnlich. Allerdings erlaubt es dem Benutzer seine Arbeit fortzusetzen, sofern er über
eine weitere Nutzerkennung mit entsprechenden Berechtigungen verfügt. Als
Konsequenz muss der Nutzer wissen, mit welchem Benutzernamen und Passwort er das benötigte Recht bekommt.
Je mehr Kennungen ein Benutzer
besitzt, desto schwieriger wird für ihn die richtige Auswahl. Zur Unterstützung kann der Log-in-Dialog weitere Informationen zu den benötigten Rechten bzw.
Rollen bereitstellen.
Sollte der Benutzer nicht in der Lage sein,
sich unter einer geeigneten Nutzerkennung anzumelden, ergibt sich dasselbe
Verhalten wie bei einem einfachen Meldungsfenster. Insbesondere ist das der
Fall, wenn der Benutzer nur über eine Kennung verfügt. Zur Entlastung des
Benutzers kann der Dialog nach einmaliger Eingabe von Benutzername und
Passwort die passenden Log-in-Informationen beim erneuten Anstoÿ der selben Aktion vorgeben. Auf diese Weise muss der Benutzer sich nicht mehr alle
Zugangsdaten merken und braucht nur noch zu bestätigen. Um auch noch
diese Zeit zu sparen und den Benutzer in seiner Arbeit nicht zu unterbrechen, kann der Rollenwechsel im Hintergrund geschehen. Dadurch ist dem
Benutzer allerdings nicht mehr bewusst, dass ein Wechsel stattndet und in
welcher Rolle er gerade agiert.
3.1.3 Optische Kennzeichnung
Szenario 3.
Ein Benutzer möchte eine Aktion auslösen.
Schaltäche ist jedoch rot gekennzeichnet.
Die betreende
Der Benutzer erkennt, dass er
nicht berechtigt ist, diese Aktion durchzuführen. Daraufhin lässt er von seinem Vorhaben ab.
In den vorherigen Szenarien erfuhr der Benutzer erst nachdem er eine
Aktion angestoÿen hat, dass er keine Berechtigung dafür besitzt. Dem kann
durch eine optische Hervorhebung der betreenden Interaktionsobjekte vorgebeugt werden. Auf diese Weise wird der Benutzer nicht in seinem Arbeitsuss unterbrochen und muss keine unnötigen Dialogfenster schlieÿen.
Op-
tische Hervorhebung können andere Text- oder Hintergrundfarben, Schriftarten und -stile, unter- oder durchgestrichene Texte, andere Symbole, usw.
Teil 2 - Theorie
50
sein. Allerdings muss die Hervorhebung innerhalb der gesamten Anwendung
konsistent gehalten werden. Dadurch fällt es dem Benutzer leichter, die Bedeutung der Kennzeichnung zu erlernen. Sofern Standards vorhanden sind,
ist deren Verwendung ebenfalls sinnvoll. Damit wird die Oberäche für den
Benutzer erwartungskonform. Auf der anderen Seite kann so eine Hervorhebung vieler Interaktionsobjekte zu einer überladenen Benutzungsoberäche
führen. Dies ist z.B. der Fall, wenn innerhalb eines Menüs fast alle Menüpunkte nicht gewährt und somit deutlich rot gekennzeichnet sind.
Bei dieser Vorgehensweise sind die Interaktionsobjekte lediglich gekennzeichnet, bleiben aber aktivierbar. Somit stellt sich die Frage: Was passiert,
wenn der Benutzer nicht wie in dem Szenario beschrieben, von seinem Vorhaben ablässt und die Aktion dennoch anstöÿt? Hierbei kommen die bereits
in 3.1.1 und 3.1.2 genannten Verhaltensweisen mit ihren Konsequenzen in
Frage. Zusätzlich gibt es die Möglichkeit, dass gar nichts passiert. Schlieÿlich
sieht der Benutzer ja anhand der Kennzeichnung, dass er diese Aktion nicht
durchführen darf. Allerdings erwartet der Benutzer, dass etwas passiert. Folgerichtig sollte das Interaktionsobjekt gesperrt werden. Diese Variante wird
im nächsten Abschnitt diskutiert.
3.1.4 Sperren von Interaktionsobjekten
Szenario 4.
Ein Benutzer möchte eine Aktion auslösen.
Die betreende
Schaltäche ist jedoch gesperrt. Der Benutzer erkennt, dass er diese Aktion
nicht ausführen kann. Daraufhin lässt er von seinem Vorhaben ab.
Gesperrte Interaktionsobjekte werden zwar in der Benutzungsoberäche
dargestellt, können aber nicht ausgelöst werden. Die Sperrung von Interaktionsobjekten geht meist einher mit einer optischen Kennzeichnung und einem
anderen Verhalten als freigegebene Interaktionsobjekte:
•
andere optische Darstellung (blasser Text, graues Symbol, . . . )
•
keine Hervorhebung des Objektes, wenn sich der Mauszeiger darüber
bendet
•
keine optische Rückmeldung beim Klicken mit der Maus auf das Objekt
(Button wird nicht eingedrückt, kein Cursor im Textfeld, . . . )
Standardmäÿig wird von gesperrten Interaktionsobjekten Gebrauch gemacht, wenn Aktionen im momentanen Systemzustand keinen Sinn machen.
Z.B. das Sortieren einer Liste mit nur einem Eintrag oder das Speichern eines
unveränderten Dokumentes.
Durch einfache Aktionen, wie das Bearbeiten
Interaktionsobjekte bei der Benutzerautorisierung
(a) freigegeben
51
(b) gesperrt
Abbildung 3.1: Interaktionsobjekte (Windows XP)
(a) freigegeben
(b) gesperrt
Abbildung 3.2: Interaktionsobjekte (Mac OSX)
eines Dokumentes, lassen sich vorher gesperrte Interaktionsobjekte wieder
frei schalten.
Werden nun gesperrte Interaktionsobjekte ebenfalls für Benutzerautorisierung verwendet, kann der Benutzer nicht mehr unterscheiden, weshalb er die
Aktion gerade nicht ausführen kann.
As you implement a role-based lter, be careful not to disable (gray out) user-inappropriate tasks if they are never possible,
because this would only clutter the UI and also be misleading, as
it might prompt users to think they could tweak some settings to
enable the never-needed functions. [Mol01, Part 2]
Um die Konsistenz der Benutzungsoberäche zu erhöhen und dem eben
geschilderten Eekt entgegen zu wirken, können Interaktionsobjekte, die zur
Eingabe, Veränderung und Auswahl von Daten dienen (z.B. Text- und Auswahlfelder), durch rein anzeigende Objekte (z.B. Labels) ausgetauscht werden.
3.1.5 Verstecken von Interaktionsobjekten
Interaktionsobjekte, für deren Verwendung ein Benutzer nicht autorisiert ist,
können versteckt werden und sind somit auf der Benutzungsoberäche nicht
sichtbar. Dies hat den Vorteil, dass der Benutzer nur die Interaktionsobjekte
Teil 2 - Theorie
52
vorndet, die er Verwenden darf und (im Idealfall) zur Erledigung seiner
Aufgaben benötigt. Dadurch ist die GUI auf die nötigen Funktionen reduziert und übersichtlicher. Die Ezienz der Handhabung der Anwendung wird
erhöht. Die Anwendung ist zudem aufgabenangemessen und erwartungskonform in Bezug auf gesperrte Interaktionsobjekte (siehe Abschnitt 3.1.4).
And if a user never needs to do something, his or her UI
will be simplied if it's never shown. Chances for errors are also
reduced. [Mol01, Part 2]
Da nur für gewährte Aktionen Interaktionsobjekte vorhanden sind, weiÿ
der Benutzer bei fehlenden Interaktionsobjekten nicht, ob er diese Aktionen
nicht durchführen darf, ob es sie überhaupt gibt oder ob er sie nur nicht ndet. Aber bei vernünftiger Zuordnung von Rollen zu Aufgaben und Rechten
sollte der Benutzer kein Bedürfnis nach weiteren Funktionen haben. Zumindest wenn die Anwendung über alle Funktionen verfügt, die zur Erledigung
der Aufgabe nötig sind.
Das Verstecken von Interaktionsobjekten führt natürlich zu einem unterschiedlichen Aussehen der Benutzungsoberäche, abhängig von der aktuellen
Rolle. Wenn der Benutzer Kenntnis über das Aussehen der Oberäche unter
einer anderen Rolle besitzt, vermisst der Benutzer unter Umständen Interaktionsobjekte, die nur in jener Rolle verfügbar sind. Auf der anderen Seite
verdeutlicht dies dem Benutzer, in welcher Rolle er gerade agiert.
3.1.6 Fazit
Welche Variante Verwendung ndet, hängt sicherlich von den Anforderungen an das System, den Gewohnheiten der Benutzer und letztendlich den
technischen Gegebenheiten ab. Kombinationen sind ebenfalls denkbar, um
die Nachteile der einzelnen Ansätze zu reduzieren. Allerdings schlieÿen sich
Meldungsfenster und Login-Dialog mit Sperren und Verstecken aus.
Die Entscheidung der gewählten Variante hängt ebenfalls davon ab, wie häug die aktive Rolle im laufenden Betrieb gewechselt werden muss. Bei zu häugen Unterbrechungen, um die Rolle zu wechseln, sollte das Rechte-Konzept
überprüft werden.
Ein Meldungsfenster sollte stets integriert sein, aber nur dann Anwendung
nden, wenn andere Mechanismen nicht korrekt arbeiten. Das Sperren von
Interaktionsobjekten ist ein gängiges Vorgehen und in den meisten Fällen
dem puren Kennzeichnen vorzuziehen. Für eine hohe Gebrauchstauglichkeit
der Software ist das Verstecken von Interaktionsobjekten zu empfehlen.
Mitunter macht es trotzdem Sinn, Interaktionsobjekte, auf die der Benutzer
Interaktionsobjekte bei der Benutzerautorisierung
53
nicht zugreifen darf, anzuzeigen und zu sperren oder mit einem Dialogfenster darauf hinzuweisen. Zum Beispiel in funktionell eingeschränkten Testversionen von Software, die für Vermarktungszwecke eingesetzt werden. Der
potentielle Kunde soll selbst den Funktionsumfang und den Umgang mit der
Software (in der Vollversion) ermitteln können.
Wichtig ist in jedem Fall eine konsistente Oberäche, bzw. eine einheitliche
Darstellungsform der Interaktionsobjekte.
3.2 Allgemeine Diskussion
Sämtliche Bereiche der Sicherheit, ob Verschlüsselung, Virenschutz oder Benutzerautorisierung, werden rege auf verschiedenen Sicherheitskonferenzen
diskutiert. Auch zur Gestaltung der Benutzungsoberäche und dem groÿen
Begri Usability gibt es viele Bücher, Artikel und Berichte.
Doch gibt es
kaum Literatur, die sich mit den Auswirkungen der Benutzerautorisierung
auf die Benutzungsoberäche beschäftigt.
Eine Ausnahme bildet der Artikel Why Johnny Can't Encrypt [WT99].
Diese Arbeit bezieht sich auf die Benutzbarkeit von Verschlüsselungsprogrammen, aber die allgemeinen Aussagen über die Benutzungsoberäche lassen sich auch auf Benutzerautorisierung anwenden.
So wird in dem Text
unter anderem folgendes erörtert:
User errors cause or contribute to most computer security
failures, yet user interfaces for security still tend to be clumsy,
confusing, or near-nonexistent. [WT99, S.1]
Dazu stellen die Autoren des Artikels die Hypothese auf, dass für wirksame
und benutzbare Sicherheit die bisherigen Vorgehensweisen für die Gestaltung
der Benutzungsoberäche nicht ausreichen und fordern daher weitergehende
Usability-Standards. Um die Einhaltung der neuen Design-Regeln für die Benutzungsoberäche festzustellen, werden ebenfalls neue, noch zu erstellende
Evaluierungsmethoden benötigt.
Laut den Untersuchungen, die für Why Johnny Can't Encrypt durchgeführt
wurden, spielt für die Benutzer die Gebrauchstauglichkeit eine deutlich stärkere Rolle als das Verlangen nach Sicherheit. Ist das verwendete Programm
sehr sicher, aber unzureichend in der Handhabung, ndet es bei den Benutzer
wenig Akzeptanz oder es wird nach Wegen gesucht, die Sicherheitsmechanismen zu umgehen.
In Bezug auf die Benutzerautorisierung bedeutet dies, dass Benutzer, die
Kai Meyer
Teil 2 - Theorie
54
aufgrund von unzureichender Darstellung ihrer Berechtigungen von dem Programm frustriert sind, es entweder nicht benutzen oder einen Account verwenden, der möglichst viele Rechte beinhaltet.
Dies kann im schlimmsten
Fall dazu führen, dass ein Account mit allen Rechten erstellt und dieser von
jedem Benutzer verwendet wird. Das macht die gesamte Benutzerautorisierung überüssig.
Bei der Administration der Rechte ist es ähnlich.
Ist die Editierung der
Rechte zu kompliziert oder nur mit viel Aufwand durchzuführen, werden die
Administratoren die Rechte nur sehr selten anpassen und daher u.U. den
Benutzern auch nicht benötigte Rechte geben. Somit würden sie gegen das
Need-to-know-Prinzip (siehe Abschnitt 1.7) verstoÿen.
Entsprechendes gilt auch für Entwickler, die ein Framework für die Benutzerautorisierung verwenden.
Ist das Schützen einer Komponente und die
Anbindung an die Benutzungsoberäche mit hohem Aufwand verbunden, so
werden die Programmierer das Framework nicht verwenden oder versuchen
den Mechanismus zu umgehen.
Dass die Auswirkungen der Autorisierung auf die Benutzungsoberäche
mit verschiedenen Mitteln umgesetzt werden können und dass dabei noch
oene Fragen existieren, wurde bereits im vorherigen Abschnitt (3.1) erörtert. Welche Bemühungen, die Autorisierung mit der Benutzungsoberäche
zu verweben, speziell im Eclipse-Umfeld existieren, ist Gegenstand des nächsten Abschnittes.
[WT99]
3.3 Aktueller Diskussionsstand über Autorisierung in der Eclipse RCP
Torsten Witte
Das Verlangen nach rollenbasierter Autorisierung in Eclipse mit entsprechend
adaptiver GUI ist groÿ. Wer die Eclipse-Newsgroups in den letzten Jahren
verfolgt hat, ndet viele Einträge zu diesem Thema.
In Anhang A.1 sind
einige Einstiegspunkte in die Diskussionen aufgelistet. Aufgrund des wachsenden Interesses wurden auch auf der EclipseCon [Ecld] immer wieder
Vorträge über Authentizierung und Autorisierung gehalten. Die Eclipse-
Con ist die gröÿte Konferenz zu Eclipse und ndet seit 2004 jedes Jahr im
März statt.
Auf der mehrere Tage andauernden Veranstaltung werden die
neuesten Techniken und Ideen in Seminaren und Übungen vorgestellt.
Aktueller Diskussionsstand über Autorisierung in der Eclipse RCP
55
Auf der EclipseCon 2006 diskutieren Jay Rosenthal und Matthew Flaherty im Rahmen ihres Vortrags Eclipse RCP Applications and Enterprise
Security [RF06] darüber, was an der Eclipse RCP getan werden muss, um
die Entwicklung sicherer Unternehmensanwendungen einfacher zu gestalten.
Unter den Anforderungen an sichere Anwendungen, wie Authentizierung,
Netzwerksicherheit, Verschlüsselung und Single Sign-On, wird natürlich auch
Autorisierung genannt.
Während einige Techniken wie digitale Signaturen
bereits von Eclipse 3.2 unterstützt werden, bleibt es bisher den Entwicklern
überlassen, vorhandene Java- und J2EE-Sicherheitstechniken wie Sandboxing und JAAS in die Rich-Client-Platform und die eigene Anwendung zu
integrieren. Rosenthal und Flaherty geben daher an, was die Eclipse RCP in
der Zukunft auf diesem Gebiet leisten könnte. Dazu zählt ein Rahmenwerk,
das basierend auf JAAS ein Plattform-Log-in bereit stellt. Eine bessere und
einfachere Integration von verschiedenen Java-Sicherheitsimplementierungen
über den Plug-In-Mechanismus ist ebenfalls ein Punkt auf ihrer Liste. Zudem ist eine exible und erweiterbare Benutzungsschnittstelle denkbar, die
mit dem zugrundeliegenden Sicherheitssystem in Wechselwirkung steht. Die
Dialoge und das Verhalten der Oberäche werden von den jeweiligen Berechtigungen beeinusst. Funktionen für die Verbreitung von Benutzungsrichtlinien und zur Administration könnten in Zukunft zusätzlich von Eclipse bereit
gestellt werden.
Eine weitere Anforderung von Rosenthal und Flaherty an zukünftige EclipseVersionen ist die Code-Sicherheit auf Basis von J2SE-Berechtigungen. Bisher
besitzt Eclipse keine Einschränkungen auf die Ausführung von Code.
verwendete
Der
FrameworkSecurityManager verletzt das Minimum privilegies-
Prinzip (siehe Abschnitt 1.7), da er standardmäÿig alles zulässt.
Plug-Ins
brauchen nur in das plugins -Verzeichnis kopiert werden und der neue Code
ist lauähig. Dieser Code kann unter Umständen private Daten lesen und verändern. Ein Prototyp, der diese Code-Sicherheit in die Plattform integriert
und mit einem J2SE SecurityManager ausgeführt wird, existiert bereits im
Rahmen des Equinox-Projektes.
Jay Rosenthal ist seit über zehn Jahren Softwaretechniker der IBM Co-
poration.
Sein Team legt den Schwerpunkt auf das Einbinden von Si-
cherheitskonzepten in die Rich-Client-Platform, um die Entwicklung sicherer
Unternehmenssoftware zu ermöglichen. In den letzten drei Jahren hat er am
Workplace Managed Client gearbeitet. Matt Flaherty ist der Sicherheitsleiter
dieses Projektes, das auf der Eclipse RCP basiert.
Kimberly Horne hat auf der vorhergehenden EclipseCon (März 2005)
die Möglichkeiten von Capabilities (Activities) vorgestellt.
Eigentlich für
die Filterung groÿer Benutzungsschnittstellen gedacht, kann dieser Erweite-
Teil 2 - Theorie
56
rungspunkt des Eclipse-UI-Plug-Ins auch für Autorisierungszwecke eingesetzt
werden.
Sie selbst sagt jedoch, dass diese Vorgehensweise keine Sicherheit
bietet: Very poor substitute for real security throw food at me for even
suggesting this [Hor05b, Folie 22]. Weshalb, wird in Abschnitt 6.3 erläutert.
Kimberly Horne arbeitet seit 2003 im IBM Ottawa Team und ist seit dem
3.0 Release Mitglied des Eclipse Platform UI Teams. Dort ist sie u.a. für das
Capabilities-Framework und dynamische Plug-Ins verantwortlich.
Bereits in seinem Buch [Dau05b] aus dem Jahr 2005 stellt Berthold Daum
zur Demonstration des Plug-In-Mechanismus einen starren Ansatz der Benutzerautorisierung vor.
Er verwendet in seiner Beispielanwendung rollen-
abhängige Plug-Ins. Der vorhandene Plug-In-Mechanismus von Eclipse wird
so ausgenutzt, dass jedem Benutzer nur die Plug-Ins zur Verfügung stehen,
die er in seiner Rolle verwenden darf. Die Realisierung dieses Ansatzes wird
in Abschnitt 6.1 ausführlicher vorgestellt.
Die Eclipse-IDE bietet so etwas ähnliches bereits über die Startkonguration
zum Testen von Plug-Ins bzw. Rich-Client-Anwendungen. Dort kann ausgewählt werden, mit welchen Plug-Ins die Rich-Client-Anwendung oder die
Testumgebung gestartet werden soll (siehe Anhang B.2.1).
Berthold Daum hat noch weitere Bücher über Eclipse und die Eclipse RCP
verfasst. Dazu gehören [Dau05a] und [Dau06].
Im September 2005 ist dann Eclipse-JAAS entstanden (siehe Abschnitt 6.2).
Neil Bartlett hat sein Projekt auf Sourceforge (unter [Eclc]) zur Verfügung
gestellt. Dabei handelt es sich um ein Rahmenwerk für die Eclipse RCP, das
den Java Authentication and Authorization Service nutzt, um den Benutzer
beim Starten der Anwendung zu authentizieren. Aufgrund seiner Identität
werden dem Benutzer dann nur bestimmte Plug-Ins angeboten. [Eclb]
Im März 2007 hielt Neil Bartlett den Vortrag Secure Desktop Applications
with Eclipse RCP [Bar07] auf der EclipseCon. Das Abstract dazu lautet
wie folgt:
Eclipse RCP is rapidly gaining popularity as a framework
for corporate desktop applications. These applications are often
developed bespoke or in-house, and are the gateways to critical
business functions. As such they must be secured: we must know
exactly who each user is (i.e. they must be authenticated), and we
must prevent users from performing tasks that they do not have
the authority to perform (i.e. they must have authorization).
Eclipse RCP is an excellent base on which to build secure applications. Through plugins and extensions, we can oer a far cleaner
Aktueller Diskussionsstand über Autorisierung in der Eclipse RCP
57
experience for users by simply hiding the functions for which they
are not authorized, instead of constantly showing Access Denied
errors. Using OSGi we can even dynamically grant or deny access to functionality while the application is running.
Yet, frustratingly, RCP stops short of supplying out-of-the-box
support for authentication and authorization, so this support must
be added on. In this talk we discuss the principle techniques required; what the most common business requirements are for security, and how to achieve them; and how to integrate with existing
technologies such as JAAS or Kerberos. [Bar07]
In dem Vortrag spricht er also an, dass auf dem Gebiet der Authentizierung
und Autorisierung in Eclipse noch einiges getan werden muss, damit allgemeine Sicherheitsanforderungen auf Basis der vorhandenen Techniken erfüllt
werden können. Was heute allerdings schon getan werden kann und was auch
in Zukunft beachtet werden sollte, teilt Bartlett ein drei Lektionen ein:
1. Primary Access Control MUST take place in the server
Eine wichtige Voraussetzung ist, dass die Kontrolle über die Benutzerrechte auf einem (zentralen) Server und somit beim Administrator
bleibt. Denn nur der Administrator weiÿ, wozu welcher Benutzer autorisiert ist.
2. If they can't do it... don't show it to them!
Damit bezieht sich Neil Bartlett auf die Gebrauchstauglichkeit von
Software.
Die Benutzungsoberäche soll nur die Funktionen enthal-
ten, für die der Benutzer autorisiert ist.
3. Control Bundle Installation
Um in einer heutigen Eclipse-Umgebung die Kontrolle über die installierten Erweiterungen zu erhalten, muss überwacht werden, welche
Plug-Ins den Zustand Aufgelöst erreichen dürfen (siehe Abschnitt 2.3.2).
Wenn die benötigte Information zu dieser Überwachung von einem Server stammt, wie in der ersten Lektion verlangt, dann wird durch diese
Vorgehensweise die zweite Lektion ebenfalls erfüllt.
Allerdings bleiben einige Kritikpunkte:
Zum einen muss eine Verbindung zum Server bestehen, was den Netzwerkverkehr erhöht.
larität.
Auf der anderen Seite steht die Problematik der Granu-
Durch Überwachung der aufzulösenden Plug-Ins werden automa-
tisch alle Erweiterungen der einzelnen Plug-Ins kontrolliert.
Ein Benutzer
kann also nicht für einzelne Erweiterungen eines Plug-Ins autorisiert sein.
Einer der Vorschläge von Neil Bartlett zur Verfeinerung dieses Alles oder
Teil 2 - Theorie
58
Nichts-Prinzips ist die Filterung der Ergebnisse aus der Extension-Registry
(registry.getExtension*() und
For*()).
registry.getConfigurationElements-
Auch die deklarative Angabe von Rollen in Erweiterungspunkten
wäre denkbar:
<extension point="..." role="admin">
Zur Autorisierung auf deklarativen Erweiterungen stuft Bartlett den Java
Authentication and Authorization Service als ungeeignet ein, da dieser Dienst
nur Code vor unbefugter Ausführung schützt. Bartlett sieht einen weiteren
Nachteil bei der Verwendung von JAAS. Ob ein Benutzer zu einer Aktion
berechtigt ist oder nicht, entscheidet sich erst, wenn die Aktion durchgeführt
wird (siehe Abschnitt 4.3.3).
Neil Bartlett ist ein Java-Entwickler und Berater, der sich insbesondere auf
die Nutzung von Eclipse RCP und OSGi innerhalb von Unternehmen spezialisiert hat. Er hat bereits einige Kreditinstitute bei der Einführung der RCP
unterstützt und predigt die Verwendung der RCP- und OSGi-Technologie
bei der client- und serverseitigen Entwicklung.
In den eingangs erwähnten Diskussionen in den Eclipse-Newsgroups werden überwiegend Kimberly Hornes Activities und Neil Bartletts EclipseJAAS diskutiert. Es werden sogar Versuche unternommen, die beiden Ansätze miteinander zu verknüpfen.
Je McAer ist Leiter der Eclipse RCP und Equinox Teams und seit Anfang
an in Eclipse einbezogen. Er ist einer der Architekten der Eclipse-Plattform
und Koautor des Buches eclipse Rich Client Platform (siehe Literaturverzeichnis [ML06]).
McAer bevorzugt die Deaktivierung von Plug-Ins vor der Nutzung von Activities und äuÿert sich zu dem Thema wie folgt:
Activities are weak and I don't really see going further with
them. Fundamentally they are a UI ltering mechanism to control
what is on the glass. There are many other aspects to the generic
notion of capabilities than just what the user sees. For example,
there may be some set of services registered that either show up
in the UI (through some third party mechanism) or just do work
in the background (e.g., a builder). If the user is not authorized
for this function, activities are not going to help.
Personally I am a fan of simply disabling plugins that the user is
not authorize to use. The problem is eectively one of granularity.
What if you want the user to be able to use part of a plugin and
you are not the plugin producer? Is this a real usecase? Are there
any simplifying assumptions we can make to help sort out the
Aktueller Diskussionsstand über Autorisierung in der Eclipse RCP
59
presentation?
To answer these, imagine you can change anything in Eclipse.
What would need to be changed (and how) to get the right security
model in place and address these issues? [McA05]
In den folgenden Kapiteln werden vorerst von Eclipse unabhängige, grundlegende und bewährte Konzepte und Lösungen für Benutzerautorisierung
vorgestellt.
Dabei wird untersucht, in wie weit sie in einer Eclipse RCP-
Anwendung verwendet werden können. Um im Anschluss der Auorderung
von McAer nachzukommen, greifen die Autoren dieser Arbeit den einfachen
Ansatz der Plug-In-(De-)Aktivierung auf. Auÿerdem stellen sie ein Konzept
vor, mit dem es möglich ist, dem Benutzer lediglich einzelne Funktionalitäten von Plug-Ins zur Verfügung zu stellen. Auf die hier diskutierten Ansätze
wird in Kapitel 6 ein Blick geworfen.
Kapitel 4
Bestehende Konzepte und
Lösungen
Kai Meyer
Die folgenden Abschnitte stellen einige der bekanntesten Konzepte und Produkte für die Authentizierung und Autorisierung vor:
•
•
•
Role Based Access Control (Abschnitt 4.1, Seite 60)
Lightweight Directory Access Protocol (Abschnitt 4.2, Seite 65)
Java Authentication and Authorization Service (Abschnitt 4.3,
Seite 66)
•
eXtensible Access Control Markup Language
(Abschnitt 4.4,
Seite 73).
Es werden kurz die grundsätzlichen Merkmale beschrieben, bevor ein genauerer Blick auf die Funktionsweise und die einzelnen Komponenten geworfen
wird. Danach werden vorhandene Erweiterungen, Kooperationsmöglichkeiten mit anderen Produkten oder, sofern es sich um ein Konzept handelt,
Umsetzungen aufgezeigt.
Der abschlieÿende Teil Einordnung soll keinesfalls eine Wertung darstellen,
sondern lediglich beschreiben, in wieweit das Konzept oder die Lösung geeignet ist für den Einsatz innerhalb eines Rich-Clients und wie die GUI in der
Spezikation berücksichtigt wurde.
4.1 Role Based Access Control (RBAC)
Kai Meyer
Die Idee, einzelnen Benutzern aufgrund ihrer Rolle Berechtigungen zuzuweisen, gibt es schon seit über 25 Jahren.
60
Doch erst 1992 wurde dieser
Role Based Access Control (RBAC)
61
Gedanke von D.F Farraiolo und D.R. Kuhn zu einem akzeptierten Standard namens
Role Based Access Control
(RBAC) aufbereitet.
RBAC
speziziert ein exibles und einfach zu handhabendes Konzept für die Autorisierung. Die überarbeitete Version von RBAC wurde im November 2001
von dem InterNational Committee for Information Technology
Standards (INCITS) als INCITS BSR 359 veröentlicht.
Wie dem Namen Role Based Access Control, also Rollen-basierte Zugriskon-
trolle, zu entnehmen ist, ndet die Autorisierung aufgrund der Rollen eines
Benutzers und den mit ihnen verbunden Rechten statt. Rollen in einem Betrieb oder einer Organisation bleiben über einen langen Zeitraum konstant,
während die registrierten Benutzer und ihre Verantwortlichkeiten häugen
Änderungen unterliegen. So ist es bei einer Versetzung oder Neueinstellung
nur nötig dieser Person eine andere Rolle zuzuweisen. Dabei kann die Struktur der Rollen und die Zuordnung der Rechte zu den Rollen unangetastet
bleiben.
Das RBAC Referenz Modell deniert vier Komponenten. Dazu gehören
Core RBAC, Hierarchical RBAC, Static Seperation of Duty und
Dynamic Seperation of Duty. In Core RBAC sind die grundlegenden
Elemente enthalten. Somit ist Core RBAC für jedes Role Based Access Control System erforderlich, während die anderen Komponenten unabhängig von
einander sind und einzeln implementiert werden können. In den folgenden
Abschnitten werden die Aufgabenbereiche der einzelnen Komponenten näher
erläutert.
4.1.1 Core RBAC
Im RBAC Modell werden den einzelnen Benutzern verschiedene Rollen zugewiesen und die Berechtigungen mit den Rollen verknüpft. Dafür beinhaltet
Core RBAC fünf Hauptelemente: Benutzer (USER), Rollen (ROLES), Objekte (OBS), Operationen (OPS) und Genehmigungen (PRMS). Zusätzlich
enthält die Spezikation Sitzungen (SESSIONS). Die Beziehungen zwischen
diesen Elementen ist in Abbildung 4.1 dargestellt.
•
Das Grundkonzept von RBAC sieht
Benutzer als natürliche Personen,
was mit der Denition des Begries Benutzer innerhalb dieser Arbeit
übereinstimmt. Dem entgegen gesetzt kann in RBAC das Konzept Be-
nutzer auch um Maschinen, Software-Systeme oder um selbstständige
(Software-)Agenten erweitert werden.
•
Eine
Rolle ist eine Beschreibung für eine Personengruppe,
die inner-
halb eines Unternehmens bestimmte Tätigkeiten ausführt und die dafür
Teil 2 - Theorie
62
Abbildung 4.1: Core RBAC Elemente [Ame03, S.8]
vorgesehenen Rechte und Verpichtungen hat.
•
Eine
Genehmigung ist eine Erlaubnis, Operationen an zu schützen-
den Objekten auszuführen.
•
Eine
Operation wird auf Objekte angewendet und verändert gegebe-
nenfalls deren Zustand.
•
Eine
Sitzung ist eine Abbildung zwischen einem angemeldeten Benut-
zer und einer Menge an aktivierten Rollen, die dem Benutzer zugeordnet sind.
Was genau eine Operation oder ein Objekt ist, hängt von dem zugrunde
liegenden System ab.
Innerhalb einer relationalen Datenbank können die
Operationen delete, insert, append oder update und die Objekte die Zellen,
Spalten oder Zeilen sein.
4.1.2 Hierarchical RBAC
Abbildung 4.2: Hierarchical RBAC Elemente [Ame03, S.10]
Um die Rollen besser zu strukturieren und sie der Firmenstruktur anzupassen, wird in vielen RBAC Anwendungen
wendet.
Hierarchical RBAC
ver-
Die Rollenhierarchie deniert eine Vererbungsbeziehung zwischen
Role Based Access Control (RBAC)
63
Rollen. So vererbt eine Vater-Rolle alle ihre Rechte an ihre Kinder, die
dann eigene Berechtigungen hinzufügen können. Hierarchical RBAC unterstützt Mehrfachvererbung, um eine beliebige partielle Ordnung zu erzeugen.
Wird lediglich Einfachvererbung verwendet, ist die Struktur der Rollen ein
einfacher Baum, in dem jede Rolle zwar mehrere Kinder haben kann, aber
nur eine einzige Vaterrolle.
4.1.3 Static Seperation of Duty (SSD)
Mit
Static Seperation of Duty (SSD) also der statischen
Trennung von
Verpichtungen ist RBAC in der Lage, die Zuordnungen von Benutzern zu
Rollen einzuschränken.
Static Seperation of Duty erlaubt einem Administrator SSD-Richtlinien zu
denieren, so dass sich bestimmte Rollen gegenseitig ausschlieÿen. Auf diese
Weise verhindert SSD, dass ein Benutzer zwei sich gegenseitig ausschlieÿende
Rollen bekommt.
Die Interessenpolitik einer Firma kann es vorsehen, dass ein Benutzer mit
Rolle A nicht der Rolle B angehören darf.
So wird sichergestellt, dass an
wichtigen Entscheidungen mehrere Personen beteiligt sind, um Risiken besser erkennen und abschätzen zu können (Vier-Augen-Prinzip). Zum Beispiel
kann es in einem Betrieb verlangt werden, dass Verträge, die von einer Person erstellt werden, vor der Unterzeichnung von einem anderen Mitarbeiter
überprüft werden.
Wird zusätzlich zu SSD auch Hierarchical RBAC verwendet, kann es zu Inkonsequenzen bezüglich der Vererbungsstruktur kommen. Schlieÿen sich zwei
Rollen gegenseitig aus, muss zusätzlich auf die Rollen geachtet werden, die
von diesen Rollen erben. Um dies zu bewerkstelligen wurde die Rollenhierarchie um die Vererbung der SSD-Bedingungen erweitert (siehe Abbildung
4.3).
Abbildung 4.3: SSD Elemente [Ame03, S.13]
Teil 2 - Theorie
64
4.1.4 Dynamic Seperation of Duty (DSD)
Ebenso wie Static Seperation of Duty reduziert auch
of Duty
Dynamic Seperation
(DSD) die für einen Benutzer verfügbaren Berechtigungen.
Der
Unterschied liegt im Kontext, in dem die einzelnen Regeln greifen. Während
SSD die Menge der zuweisbaren Rechte im gesamten System beschränkt, ist
DSD verantwortlich für die Reduzierung der Rechte zur Laufzeit innerhalb
einer Sitzung (siehe Abbildung 4.4). D.h. ein Benutzer kann mehreren Rol-
Abbildung 4.4: DSD Elemente [Ame03, S.14]
len zugewiesen sein, die einzeln verwendet keine Interessenskonikte verursachen. Nur wenn der Benutzer innerhalb einer Sitzung verschiedenen Rollen
aktiviert, kommt es zu diesen Konikten. Hier greift DSD ein. Versucht ein
Benutzer sich mit einer weiteren Rolle anzumelden, die in Konikt mit einer
bereits aktiven Rolle steht, wird er von RBAC aufgefordert, die aktive Rolle
zu beenden, bevor die neue aktiviert werden kann.
Somit unterstützt DSD das Minimum Privilegies-Prinzip, welches bereits
in Abschnitt 1.7 erklärt wurde.
4.1.5 Einordnung
RBAC beschreibt eine einfaches und leicht zu administrierendes Vorgehen
um Benutzerautorisierung durchzuführen. Durch die Verwendung von Rollen und den dazu denierbaren Bedingungen kann RBAC eine groÿe Bandbreite an Sicherheitsrichtlinien umsetzen. Da beim Anmelden eines Benutzers
seine Berechtigungen ermittelt werden und RBAC keine Annahmen darüber
macht, was geschützt werden soll, kann auch die Benutzungsoberäche entsprechend angepasst werden.
Der Einsatz in einer Rich-Client-Architektur
ist ebenfalls denkbar. Es müssen lediglich die Rollenzuordnungen auf dem
Rich-Client verfügbar sein und bei einer bestehenden Serververbindung aktualisiert werden.
[FK92], [Uni03], [Ame03]
Lightweight Directory Access Protocol (LDAP)
65
4.2 Lightweight Directory Access Protocol
(LDAP)
Für die Speicherung und den Zugri auf Benutzerinformationen bieten sich
Verzeichnisdienste an.
Ein
Verzeichnis ist eine Auistung von Informationen über Objekte in
einer gewissen Ordnung. Zu jedem Objekt können Detailinformationen abgefragt werden.
Beispiel: In einem Telefonbuch sind die Objekte die Personen, die Ordnung
ist alphabetisch und die Detailinformationen sind Adresse und Telefonnummer.
Neben solchen Kontaktdaten kann ein Verzeichnis auch Passwörter, private
Schlüssel, Zertikate, Richtlinien und Zugriskontrolllisten (Access Control
Lists, ACLs) enthalten.
Ein
Verzeichnisdienst wird eingesetzt, um die Daten zentral zu halten
und redundante Informationen an verschiedenen Stellen zu vermeiden. Dabei
liegen die Daten in einem einheitlichen Schema vor und sind unter einer einheitlichen Schnittstelle erreichbar. Eine Zugriskontrolle auf die enthaltenen
Informationen ndet ebenfalls statt.
Verzeichnisdienste sind mehr für das schnelle Aunden und Auslesen auf
Informationen ausgelegt als auf das Schreiben neuer Informationen.
Beispiel: Ein Telefonbuch wird nur jährlich aufgelegt, eine Passwort-Datenbank wird nur selten geändert, aber beide werden ständig abgefragt.
Das Lightweight Directory Access Protocol ist ein Protokoll zum Zugri
auf Verzeichnisdienste. Zusätzlich gibt es eine hierarchische Verzeichnisstruktur vor.
LDAP basiert auf dem X.500-Standard, der 1988 von der ISO
und der International Telecommunication Union (ITU) geschaen
wurde. Die Kommunikation mit der Verzeichnisstruktur ndet über das Directory Access Protocol (DAP) statt. Bei X.500 ist das DAP sehr umfangreich und setzt auf den vollständigen ISO/OSI-Stack auf ([ISO94, S.34],
+
[Z 98, S.346f ]). Dadurch ist das Protokoll schwer zu implementieren. Aus
diesem Grund wurde 1995 an der Universität von Michigan LDAP entwickelt.
LDAP bietet eine leichtgewichtigere Version des Directory Access Protocol
für den Zugri auf X.500 Verzeichnisse über TCP/IP. Aufgrund seiner Einfachheit, Flexibilität und Vielseitigkeit ist LDAP zum de facto Standard für
die Verwaltung von Benutzerinformationen geworden. LDAP ist ein oener
Standard und hersteller- und plattformunabhängig. Die enthaltenen Informationen werden durch Authentizierung, Zugriskontrollen (über ACLs)
und Verschlüsselung geschützt. Eine bekannte OpenSource-Umsetzung von
Torsten Witte
Teil 2 - Theorie
66
LDAP ist OpenLDAP [Ope]. OpenLDAP wird standardmäÿig bei Linux und
BSD-Betriebssystemen verwendet und kann mit den meisten UNIX-Systemen
genutzt werden.
4.2.1 Einordnung
Da in Java über das Java Naming and Directory Interface (JNDI) Kontakt
mit einem LDAP-Server aufgenommen werden kann, ist die Verwendung von
LDAP auch innerhalb eines Eclipse-Rich-Clients möglich. Damit ist ein geeigneter Ort für die Authentizierungs- und Autorisierungsdaten innerhalb
eines Netzwerks gefunden.
[SNL06, S.73 ], [Mit], [BG03]
4.3 Java Authentication and Authorization Service (JAAS)
Torsten Witte
Ursprünglich bietet Java bezugsquellen-basierte Zugriskontrollen an (codesource-based access controls), d.h.
Zugriskontrollen die darauf basieren,
von wo der Code abstammt und wer den Code signiert hat. Der Java
Authentication and Authorization Service (JAAS) erweitert die JavaSicherheitsarchitektur um die Fähigkeit, Zugriskontrollen davon abhängig
zu machen, wer den Code ausführt. Seit Java Version 1.4 ist JAAS fest in das
Java 2 Standard Edition Development Kit (J2SDK) integriert. Es handelt
sich dabei um eine reine Java-Implementierung.
JAAS kann für zwei Anwendungsbereiche eingesetzt werden:
1. für die Authentizierung von Benutzern, um zuverlässig und sicher zu
bestimmen, wer gerade Java-Code ausführt
2. für die Autorisierung von Benutzern, um sicherzustellen, dass Benutzer
die für ihre Handlungen erforderlichen Genehmigungen besitzen
[Jav07c], [Jav07d]
4.3.1 Authentizierung mit JAAS
Da JAAS modular aufgebaut ist, bleiben Anwendungen unabhängig von der
darunterliegenden Authentizierungs-Technologie.
Auf diese Weise können
Java Authentication and Authorization Service (JAAS)
67
stets neue oder verbesserte Technologien verwendet werden, ohne dass die zugehörige Anwendung angepasst werden muss. Es ist sogar möglich, mehrere
Authentizierungs-Module aufzuschichten und ein anwendungsübergreifendes Single Sign-On (siehe Abschnitt 1.4) zu realisieren.
Die Authentizierung eines Benutzers spielt sich bei JAAS in einem
inContext ab.
Log-
Für die korrekte Authentizierung innerhalb dieses Kontextes
ist das Login-Modul, eine Implementierung des Interfaces
auth.spi.LoginModule,
javax.security.-
verantwortlich. Vorgefertigte Login-Module für
Unix, Windows, JNDI (Java Naming and Directory Interface) und Kerberos
sind in Java bereits enthalten.
Login-Module kommunizieren mit Hilfe von
Callbacks und einem Callback-
Handler mit dem Benutzer, um z.B. dessen Namen und Passwort abzufragen.
Dadurch bleiben Login-Module unabhängig von der eingesetzten Benutzerinteraktion. Da Login-Module lediglich in einer Kongurationsdatei angegeben
werden, sind sie leicht austauschbar. Hier ein Beispiel für den Inhalt so einer
Datei:
LoginContextName {
authorizationExample.MyLoginModule required;
};
Ein authentizierter Benutzer oder Dienst wird in JAAS von einem
ject
Sub-
repräsentiert. Bei erfolgreicher Authentizierung eines Benutzers bin-
det das Login-Modul ein oder mehrere Principals an dessen Subject. Jedes
Principal repräsentiert eine Identität des Benutzers. Dabei ist eine einfache
Namens- oder Benutzerkennung (Id) denkbar, wodurch Subjects voneinander unterschieden werden können. Die Zuweisung von Gruppen oder Rollen
ist ebenfalls über
Principals möglich.
Anhand dieser Kennungen kann dann
später ermittelt werden, ob der Benutzer die Erlaubnis besitzt, bestimmte
Code-Abschnitte auszuführen.
Das Sequenzdiagramm in Abbildung 4.5 auf Seite 68 veranschaulicht den
Authentizierungsvorgang grasch. Ein ausführliches Beispiel zur Authentizierung mit JAAS ist [Jav07a] oder der beigefügten CD zu entnehmen.
[Jav07a], [Jav07c], [Jav07d]
4.3.2 Autorisierung mit JAAS
Ob ein Benutzer autorisiert ist, einen bestimmten Code-Block auszuführen,
ist in einer Policy-Datei (engl.
Richtlinie; Regelwerk) festgehalten.
Diese
Richtlinien-Dateien sind einfache ASCII-Dateien und können mit Hilfe des
68
Teil 2 - Theorie
Abbildung 4.5: Authentizierung mit JAAS - Sequenzdiagramm
Java Authentication and Authorization Service (JAAS)
69
Policy-Tools von Java erstellt und bearbeitet werden (siehe Anhang B.3).
Eine Policy-Datei enthält z.B. folgende Einträge:
grant
Principal authorizationExample.principals.MyNamePrincipal "joe"
{
permission java. io .FilePermission "foo.txt", "read, write";
permission java. util .PropertyPermission "java.home", "read";
permission authorizationExample.permissions.MyPermission "permissionForMyAction1";
};
grant
Principal authorizationExample.principals.MyNamePrincipal "bob"
Principal authorizationExample.principals.MyRolePrincipal "role1"
{
//Nur ein Subject, das ALLE o.g. Principals besitzt , darf die jew. Action ausführen
permission authorizationExample.permissions.MyPermission "permissionForMyAction1";
permission authorizationExample.permissions.MyPermission "permissionForMyAction2";
};
Subject, dass das Principal MyNamePrincipal
authorizationExample.principals mit dem Namen joe
In diesem Beispiel hat ein
aus dem Paket
besitzt, folgende Berechtigungen:
•
Lesen und Schreiben der Datei
•
Lesen der Property-Variable
•
Ausführen von
plar der
foo.txt
java.home
MyAction1, d.h. dem Code-Block, der durch ein ExemKlasse MyPermission mit dem Attributwert permissionFor-
MyAction1 geschützt ist (siehe unten)
Permissions zur VerfüPermissions
und Principals angelegt werden. Die Überprüfung der Permissions geschieht im Code über eine der zahlreichen check...-Methoden des SecurityManagers der Java-Anwendung. Besitzt das System nicht die benötigte Berechtigung, wird eine SecurityException geworfen.
Das Beispiel zeigt ebenfalls, dass Java bereits einige
gung stellt und diese auch überprüft. Zusätzlich können eigene
Subjects ausgeführt werden darf, berun()-Methode einer java.security.PrivilegedAction
oder java.security.PrivilegedExceptionAction. Diese Schnittstellen werDer Code, der nur von bestimmten
ndet sich in der
den benötigt, um den Code als geschützte Aktion zu kapseln und vom System im Auftrag eines
Subjects
ausführen zu lassen. Dazu später mehr.
Das folgende Codebeispiel zeigt die Implementierung von
der
MyAction1.
Mit
checkPermission()-Methode des SecurityManagers wird überprüft, ob
Subjects) die benötigte Berechtigung besitzt.
das System (im Auftrag eines
Teil 2 - Theorie
70
package authorizationExample.privilegedActions;
import java.security.PrivilegedAction;
import authorizationExample.permissions.MyPermission;
public class MyAction1 implements PrivilegedAction {
public Object run() {
try {
}
}
SecurityManager securityManager = System.getSecurityManager();
if (securityManager!=null) {
securityManager.checkPermission(new MyPermission("permissionForMyAction1"));
}
System.out.println("MyAction1 −> ok");
Object result = new Object();
//do something
return result;
} catch (SecurityException e) {
System.out.println("MyAction1 −> not ok");
throw e;
}
PrivilegedAction im Auftrag eines Subjects
Subject die statischen Methoden doAs()
und doAsPrivileged(). Diese Methoden nehmen als Parameter ein Subject
und eine PrivilegedAction entgegen. Die Methode doAsPrivileged() erwartet darüber hinaus einen AccessControlContext. Der SecurityManager
ist nach dem Aufruf einer der doAs-Methoden in der Lage, Berechtigungsentscheidungen aufgrund der Principals des Subjects und dem Inhalt der
Policy-Datei zu treen. Die run()-Methode der jeweiligen PrivilegedAction
Damit das System eine
ausführen kann, enthält die Klasse
wird ausgeführt und, sofern alle benötigten Berechtigungen vorhanden sind,
deren Ergebnis von der
SecurityException
doAs-Methode zurückgeliefert.
Andernfalls wird eine
geworfen.
Die komplette Beispielanwendung bendet sich auf der CD zu dieser Arbeit (siehe Anhang C.3). Abbildung 4.6 auf Seite 71 zeigt ein vereinfachtes
Sequenzdiagramm des Autorisierungsvorgangs. In dem Diagramm ist zu erkennen, dass bereits für die Ausführung der
doAs-Methoden
Systemberech-
tigungen notwendig sind.
[Jav07b]
Java Authentication and Authorization Service (JAAS)
Abbildung 4.6: Autorisierung mit JAAS - Sequenzdiagramm
71
Teil 2 - Theorie
72
4.3.3 Einordnung
JAAS ist ein bewährtes, Java-internes Rahmenwerk, das den von vornherein in Java vorhandenen Sicherheitsmechanismus um benutzerabhängige Zugriskontrollen erweitert. Dadurch wird benutzer-, gruppen- und rollenbasierte Autorisierung möglich. Der Bezug zu einer GUI ist im Bereich der Authentizierung einfach herzustellen (z.B. mit einem Log-in-Dialog). Da die
doAs-Methoden im nicht-autorisierten Fall eine SecurityException werfen,
werden diese meist einfach an den Benutzer in Form eines (Fehler-)Dialogs
weitergereicht. Allerdings können über einen kleinen Workaround die Berechtigungen abgefragt werden, ohne die geschützte Aktion durchzuführen. So
ist auch auf dem Gebiet der Autorisierung eine anpassbare Benutzungsoberäche möglich (z.B. durch Weglassen von Menüpunkten, für die der Benutzer
nicht berechtigt ist).
Der Nachteil von JAAS liegt bei den Policy-Dateien. Diese sind standardmäÿig Textdateien auf der Clientseite. Daher können sie ohne groÿe Probleme
von unbefugten Benutzern verändert werden. Auÿerdem sind sie durch keine
Prüfsumme gesichert, um Änderungen gegebenenfalls zu erkennen.
Da je-
doch die Berechtigungen von Benutzern oder Rollen von Zeit zu Zeit gewechselt werden, ist ein weiterer Nachteil die fehlende Aktualisierung im
System. Wurden Policy-Dateien einmal vom System eingelesen, können sie
zwar nachträglich verändert werden, doch das Java-System erkennt diese Änderung nicht. Als Konsequenz muss die Anwendung neu gestartet werden.
Um JAAS innerhalb eines Rich-Clients verwenden zu können, muss also
ein Weg gefunden werden, der diese Probleme sinnvoll löst.
Da sich das
Sicherheitssystem von Java beliebig erweitern lässt, lassen sich z.B. die Standardtextformate durch XML-Dateien ersetzen, die verschlüsselt und mit einer (durch eine digitale Signatur gesicherten) Prüfsumme gespeichert werden.
Solange die Policy-Dateien auf dem Client bleiben, kann der Rich-Client die
Berechtigungsentscheidungen weiterhin auch ohne bestehende Serververbindung treen. Sobald die Verbindung zum Server wieder hergestellt ist, muss
die lokale Policy-Datei mit dem Server synchronisiert werden.
Eine Umsetzung, die den Java Authentication and Authorization Service und
die Eclipse Rich-Client-Platform zusammenführt, ist Eclipse-JAAS (siehe
Abschnitt 6.2).
[Ull06, Kap. 24.3]
eXtensible Access Control Markup Language (XACML)
73
4.4 eXtensible Access Control Markup Language (XACML)
Die von der Organization for the Advancement of Structured In-
eXtensible Access Control Markup Language ist eine bewährte Beschreibungssprache für Sicherformation Standards (OASIS) spezizierte
heitsrichtlinien. Es ist eine XML-basierte Sprache zur Beschreibung sowohl
von Autorisierungsregeln und Policies (siehe Abschnitt 4.4.1) als auch von
Auswertungsregeln, um Entscheidungen für die Autorisierung treen zu können. Zusätzlich beschreibt XACML ein Nachrichtenformat, das für die Erzeugung von Autorisierungsanfragen und -antworten verantwortlich ist. Dabei
ist XACML generisch und exibel genug, um verschiedene Sicherheitsanforderungen sowie groÿe und komplizierte Richtlinienstrukturen zu unterstützen.
Einer der groÿen Vorteile von XACML ist, dass es Zugrisrechte auf
bestimmte Teile von XML-Dokumenten vergeben kann.
Den Kern von XACML bilden der
und der
Policy Enforcement Point (PEP)
Policy Decision Point (PDP). Im Kontext von XACML ist der
Begri Point als Einstiegspunkt zu verstehen. Der PEP schützt die zugrundeliegenden Ressourcen, indem er die Anfragen eines Benutzers zuerst an den
PDP schickt und nur wenn diese Instanz den Zugri gewährt, werden die entsprechenden Aktionen vom PEP veranlasst. Die Nachrichten zwischen PEP
und PDP werden in dem in XACML enthaltenen Nachrichtenformat generiert und versendet. Nachdem der PDP eine Anfrage von PEP erhalten hat,
antwortet er mit:
•
Permit - Zugri gewähren
•
Deny - Zugri verweigern
•
Indeterminate - Die Entscheidung kann nicht getroen werden, da benötigte Daten nicht vorhanden oder Fehler aufgetreten sind
•
Not Applicable - Die Anfrage kann von diesem PDP nicht beantwortet
werden
4.4.1 Policies
Die XACML Beschreibungssprache für Policies ist in der Lage auch sehr exible und komplexe Policies zu denieren. Aufgrund der Gröÿe des zugrundeliegenden Daten-Modells werden hier nur die wichtigsten Komponenten
vorgestellt:
Kai Meyer
Teil 2 - Theorie
74
•
Eine
XACML-Policy (Richtlinie) ist eine Menge von Regeln zusam-
men mit einem Algorithmus, um diese Regeln zu kombinieren. Zusätzlich können mehrere Obligations (Verpichtungen) hinterlegt werden.
Diese spezizieren Operationen, die ausgeführt werden sollen, nachdem
eine Autorisierungsentscheidung getroen wurde. Jede Policy beinhaltet genau einen Policy- oder PolicySet-XML-Tag.
•
Ein
PolicySet ist eine Menge von Policies oder anderen PolicySets und
dient hauptsächlich der Strukturierung von Policies. Ähnlich wie bei
einer Policy, ist in jedem PolicySet ein Algorithmus, der die Policies
verknüpft. Auch hier können wieder Obligations angegeben werden.
•
Eine
Rule (Regel) beschreibt, welche Bedingungen erfüllt sein müssen,
damit erbetene Zugrie auf Ressourcen gewährt werden. Sie beziehen
sich auf genau ein Target. Das Ergebnis bzw. der Eekt einer Regel
(permit oder deny) wird zurückgegeben, sofern das Target und die
optionalen Condition s zutreen.
•
Eine
Condition
(Bedingung) kann auf die Attribute von der Umge-
bung, der Ressource, dem Subject (einem Benutzer oder eine Instanz)
und der Aktion zugreifen.
Die so erhaltenen Informationen können
anschlieÿend zu einem booleschen Ausdruck zusammengefasst werden.
•
Ein
Target
(Ziel) ist eine Menge von Bedingungen für Ressourcen,
Subjects und Aktionen bzw.
deren Attribute.
Die Policy, das Poli-
cySet oder die Rule passt zu einer Anfrage, wenn die in der Anfrage
enthaltenen Attribute den Bedingungen im Target entsprechen.
Die
Information in einem Target können auch dazu verwendet werden, die
Policies zu strukturieren. Dies ist gerade bei einer sehr groÿen Anzahl
von Policies hilfreich.
•
Ein
Attribute
(Attribut) ist ein unter einem Bezeichner bekannter
Wert eines Subject s, einer Ressource, einer Aktion oder der Umgebung.
Der Name des Benutzers, seine Gruppenzugehörigkeit, die aktuelle Uhrzeit oder die Uhrzeit der Anfrage sind solche Attribute.
4.4.2 Datenuss
Die Abbildung 4.7 stellt einen typischen Anfrageablauf in XACML da. Die
einzelnen Schritte sind dabei:
1. Ein Administrator legt am
Policy Administration Point (PAP) Po-
licies und Policies-Sammlungen fest.
eXtensible Access Control Markup Language (XACML)
75
Abbildung 4.7: XACML-Datenuss [SNL06, S.419]
2. Ein Antragsteller (Benutzer oder andere Instanz) stellt eine Anfrage
bzgl. einer Ressource an den PEP. Dazu müssen die Attribute und Policies der Ressource, der Umgebung, der Aktion und des Antragstellers
selbst bekannt sein.
3. Der PEP leitet die in dem domänenspezischen Format verfasste Anfrage an den Context Handler weiter.
4. Der Context Handler kreiert aus der Anfrage einen XACML AnfrageKontext und sendet anschlieÿend eine Auswertungs-Anfrage an den
PDP.
5. Der PDP fragt nun den Context Handler nach Daten, die für die Entscheidung benötigt werden. Dazu gehören Attribute des Benutzers, des
betreenden Subject s, der Ressource, der Aktion sowie der Umgebung.
6. Der Context Handler bezieht die geforderten Attribute entweder aus
dem schon erstellten Anfrage-Kontext oder aus einem
mation Point (PIP).
Policy Infor-
7. Der PIP sammelt die Attribute von den entsprechenden Stellen.
8. Der PIP übergibt die Daten dem Context Handler.
Teil 2 - Theorie
76
9. Optional kann der Context Handler die Ressource dem Kontext anhängen.
10. Der Context Handler sendet die gesammelten Attribute an den PDP
11. Die passenden Policies werden ausgewertet, ein Entscheidungskontext
generiert und dieser Kontext zusammen mit der Entscheidung zurück
an den Context Handler geschickt.
12. Der Context Handler übersetzt die Antwort in das domänenspezische
Format und leitet dies an den PEP weiter.
13. Der PEP führt am Obligations Service alle von der Entscheidung abhängigen Verpichtungen (engl. obligations) aus.
4.4.3 Umsetzungen und Erweiterungen
Sun Microsystems hat auf Sourceforge eine OpenSource Implementierung
von XACML veröentlicht. Das XACML Kit Version 1.2 [Sun] unterstützt
die derzeit aktuelle XACML 2.0 Spezikation. Das Kit bietet verschiedene
Pakete, die einzelne Bereiche der XACML Spezikation umsetzen. Derzeit
wird an der Version 2.0 gearbeitet.
ebXML Registry [ebX] benutzt XACML, um eine Zugriskontrolle für WebServices zu realisieren.
Es regelt unter welchen Umständen ein Benutzer
Zugri auf einen Web-Service hat.
SAML (Security Assertion Markup Language) ermöglicht in der Version 2.0
eine Anbindung von XACML. SAML übernimmt die Authentizierung und
die Aufgaben eines Identity-Management und kann somit ein SSO (siehe
Abschnitt 1.4) bereitstellen.
Allerdings beinhaltet es keinerlei Autorisie-
rungsmechanismen. Diese können dann von XACML übernommen werden.
4.4.4 Einordnung
XACML beschreibt, wie eine Autorisierungsentscheidung zustande kommt.
Dabei werden in der Spezikation keine Annahmen gemacht, wie sich die Entscheidungen auf die Benutzungsoberäche auswirken. Bei entsprechender Implementierung des PEP und des PDP ist es jedoch vorstellbar, aufgrund der
getroenen Entscheidungen einzelne GUI-Komponenten auszublenden bzw.
zu (de-)aktivieren und zwar bevor die zu den Komponenten gehörenden Aktionen ausgeführt werden.
XACML kann auch innerhalb eines Rich-Clients verwendet werden, da die
eXtensible Access Control Markup Language (XACML)
77
Spezikation keine Annahmen darüber macht, wo und wie der PDP zu erreichen ist. Wenn der Policy Enforcement Point bestandteil des Rich-Clients
ist, ist es sogar möglich, dass ein Policy Decision Point ebenfalls lokal vorhanden ist.
So wäre der Rich-Client ohne Serververbindung in der Lage,
Autorisierungsentscheidungen zu treen. Sobald der Server wieder erreichbar ist, können die Policies synchronisiert werden. Es ist ebenfalls denkbar,
dass der Server seinen eigenen PDP besitzt. Dieser kann dann nicht nur die
eingehenden Synchronisationsanfragen überprüfen, sondern auch direkt von
einem Rich-Client angesprochen werden, um ohne weitere Synchronisierung
direkt auf den aktuellen Policies zu arbeiten.
[SNL06, S.411 ], [Sun]
Kapitel 5
Weitergehende Konzepte und
Lösungen
Kai Meyer
Die bisher vorgestellten Autorisierungsmechanismen sind alle bewährt und
vielfach eingesetzt. Jedoch beschreibt keines der Konzepte, wie sich die Auswirkungen der Autorisierung sinnvoll in die Benutzungsoberäche integrieren
lassen.
Die Eclipse RCP bietet über die Plug-In-(De-)Aktivierung (Abschnitt 5.1)
eine einfache Möglichkeit für die Autorisierung. Durch diesen Mechanismus
wird, die in Abschnitt 3.1.5 diskutierte Variante des Verstecken von Interaktionsobjekten realisiert. Unter bestimmten Umständen, die in dem noch
kommenden Abschnitt Auswirkungen unterschiedlicher Systemanforderungen (5.3) näher erläutert werden, ist dieses Vorgehen allerdings nicht ratsam. Für diese Fälle wurde im Zuge dieser Diplomarbeit von den Autoren
das Konzept der Security-Facade (Abschnitt 5.2) erstellt.
Dieses Konzept
erlaubt eine exible Anbindung der Benutzungsoberäche, die sich für jedes
zu schützende Interaktionsobjekt individuell kongurieren lässt.
5.1 Plug-In-(De-)Aktivierung
Torsten Witte
Die Plug-In-Architektur von Eclipse erlaubt die Auswahl der Plug-Ins, die
in eine RCP-Anwendung integriert sein sollen.
Dies ist nicht nur für die
Entwicklung von Produkten interessant, sondern ebenso für die Benutzerautorisierung. Durch die Kontrolle, welche Plug-Ins in einer Anwendung aktiv
sein dürfen, wird automatisch kontrolliert, welche Registerbeiträge in ihr Erweiterungsregister gelangen. Somit werden gleich zwei Ziele erreicht: Zum
einen ist der, vor der Ausführung zu schützende, Code nicht die Anwendung
integriert und zum anderen tauchen nur die Beiträge der bewilligten Plug-Ins
78
Plug-In-(De-)Aktivierung
79
in der Benutzungsoberäche auf.
Bei Verwendung der Plug-In-(De-)Aktivierung bietet sich eine Rechtevergabe auf Plug-In-Ebene an. Dies ist ein Alles oder Nichts-Prinzip, denn
entweder hat eine Rolle Zugri auf ein komplettes Plug-In oder nicht. Dabei
müssen bei der Zuordnung von Rechten die Abhängigkeiten der Plug-Ins untereinander beachtet werden. Es ergibt sich zwangsläug eine hierarchische
Berechtigungsordnung, da keine Rolle die Berechtigung für ein Plug-In haben kann, ohne die Berechtigung auf dessen benötigte Plug-Ins zu besitzen.
Dementsprechend müssen Plug-In- und Rechte-Hierarchie aufeinander abgebildet werden können. Dieser Umstand ist bereits bei der Entwicklung der
Plug-Ins für eine RCP-Anwendung zu berücksichtigen und kann bei Integration fremder Plug-Ins auf Schwierigkeiten stoÿen.
Für die Umsetzung dieses Konzeptes gibt es verschiedene Möglichkeiten.
Drei davon werden im weiteren Verlauf dieser Arbeit vorgestellt: Der Ansatz von Berthold Daum (Abschnitt 6.1), Eclipse-JAAS (in Abschnitt 6.2)
und eine Eigenentwicklung der beiden Autoren (Dienstplaner-Projekt, Kapitel 7). Jede dieser Realisierungen hat ihre Vor- und Nachteile und ist für
einen anderen Einsatzkontext mehr oder weniger sinnvoll. Auch müssen die
Konsequenzen beachtet werden, die sich aus der gewählten Methode ergeben.
Die hier vorgestellten Umsetzungen haben gemeinsam, dass der Benutzer sich beim Starten der Anwendung anmeldet und ihm daraufhin nur die
gewährten Plug-Ins zugesprochen werden. Für einen Wechsel der Rolle ist
stets ein Neustart der Anwendung notwendig. Laut OSGi-Spezikation ist
das Hinzufügen und Entfernen von Bundles zu einer Anwendung während
des laufenden Betriebes möglich. Also auch ein Rollenwechsel ohne Neustart
der Anwendung, da Plug-Ins nachgeladen oder entfernt werden können. Das
wird in den hier vorgestellten Realisierungen jedoch nicht behandelt.
Allerdings liegt genau in dieser Oenheit der Plattform eine Sicherheitslücke. Im Fall der Eclipse RCP können über die OSGi-Konsole (siehe Anhang B.2.2) jederzeit weitere Plug-Ins in die Anwendung integriert werden.
Keine der drei hier genannten Umsetzungen überwacht oder unterbindet die
nach dem Anwendungsstart eingespielten Plug-Ins. Also kann nachdem die
Autorisierung und damit die Deaktivierung einiger Plug-Ins stattgefunden
hat, diese wieder rückgängig gemacht werden.
Um diese Sicherheitslücke
zu schlieÿen, sollte entweder verhindert werden, die jeweilige Eclipse RCPAnwendung mit der OSGi-Konsole zu starten, oder besser, auf Änderungen
an dem Erweiterungsregister gehorcht werden, um entsprechend zu reagieren.
Teil 2 - Theorie
80
5.2 Security-Facade
Kai Meyer
Da die Granularität der Berechtigungen bei der Plug-In-(De-)Aktivierung für
manche Anwendungskontexte zu grob ist, haben die Autoren im Zuge dieser
Diplomarbeit das Konzept der
Security-Facade erstellt.
Das Konzept be-
schreibt einen Autorisierungsmechanismus, der sich direkt auf die grasche
Benutzungsoberäche auswirkt.
Ferner erlaubt es eine sehr feine Struktu-
rierung der Berechtigungen, da es den Schutz einzelner Code-Blöcke unterstützt. Zudem können beliebige Interaktionsobjekte individuell den aktuellen
Berechtigungen des Benutzers angepasst werden. Zusätzlich ermöglicht das
Konzept, die Berechtigungen zur Laufzeit zu editieren, was sich dann ebenfalls umgehend auf die Benutzungsoberäche auswirkt.
Die wichtigsten Komponenten sind in Abbildung 5.1 dargestellt:
Abbildung 5.1: Komponenten der Security-Facade
•
Die
Security-Facade
Kern des Konzeptes.
bildet zusammen mit den
Executables
den
Die Executables beinhalten neben einem Be-
zeichner die zu schützenden Code-Blöcke. Die Bezeichner dienen der
Identizierung eines Executables und für die spätere Ermittlung der benötigten Rechte zu dessen Ausführung. Die erstellten Executables werden jedoch nur dann aufgerufen, wenn es die Security-Facade erlaubt.
Diese Entscheidung wird mit Hilfe des User- und Rights-Managements
getroen.
•
Das
User-Management dient der Anbindung des Authentizierungs-
mechanismus. Darüberhinaus referenziert es den zur Zeit angemeldeten
Benutzer und welche Berechtigungen er besitzt. Das User-Management
ist auch dafür verantwortlich, einen Wechsel des Benutzers sowie Veränderungen seiner Rechte an die Security-Facade und andere registrierte
Security-Facade
81
Stellen zu melden, z.B. durch Verwendung eines Beobachter-Musters
(siehe [GHJV95, 287 ]).
Die Berechtigungen werden in Form von
Right-Sets festgehalten.
•
Das
Rights-Management verwaltet die für die Ausführung jedes Exe-
cutables benötigten Rechte. Diese können aus einem persistenten Speicher (Datenbanken, XML-Dateien, LDAP, . . . ) bezogen werden. Die
Referenzierung der benötigten Rechte für ein Executable erfolgt über
dessen Bezeichner. Auch dieses Management arbeitet auf den RightSets. Des Weiteren benachrichtigt das Rights-Management die SecurityFacade und andere Instanzen über Änderungen der geforderten Rechte
für die Bezeichner.
•
Ein
Right-Set besteht aus
einer Menge von Rechten und einem Be-
zeichner. Der Bezeichner kann entweder der Name eines Benutzers oder
der Bezeichner eines Executables sein. Es ist ebenso möglich, dass die
Bezeichner komplexe Objekte sind. Für einen Benutzer repräsentiert
das Right-Set die ihm gewährten Berechtigungen im System, während
ein Right-Set zu einem Executable den geforderten Rechten entspricht.
Über die eingesetzten Bezeichner kann ein Right-Set eindeutig einem
Benutzer oder einem Executable zugeordnet werden. Die Verwendung
der Right-Sets im User- und Rights-Management vereinfacht die Ermittlung der Berechtigungen in der Security-Facade.
•
Das
Activation-Management und die Activation-Adapter dienen
der Anpassung der Benutzungsoberäche. Eine genauere Beschreibung
dieser Komponenten erfolgt später.
Die Executables werden also nicht direkt mit den Berechtigungen belegt,
sondern lediglich mit einem Bezeichner versehen.
Ein Administrator weist
nur den Bezeichnern die benötigten Berechtigungen zu. Durch Vergabe des
selben Bezeichners an mehrere Executables können Funktionsgruppen erstellt
werden. Somit sind entweder alle Executables einer Gruppe ausführbar oder
keines von ihnen.
Wie aus dem Datenussdiagramm in Abbildung 5.2 zu ersehen, ermittelt
die Security-Facade bei einer eingehenden Anfrage nach einem Executable
zunächst die gewährten Berechtigungen des aktuellen Benutzers vom UserManagement. Anschlieÿend werden die geforderten Rechte für den Bezeichner des Executables vom Rights-Management erfragt. Ergibt sich bei dem
Vergleich der beiden Right-Sets eine Übereinstimmung, erlaubt die SecurityFacade die Ausführung des Executables.
Teil 2 - Theorie
82
Abbildung 5.2: Security-Facade-Datenuss
Die geforderte Anbindung der Benutzungsoberäche wird über das
vation-Management erreicht.
Acti-
Es nutzt die schon vorhandenen Bezeichner
und die Security-Facade. Das Activation-Management erlaubt, beliebige Objekte zusammen mit einem Bezeichner und einem
Activation-Adapter zu
registrieren. Diese Objekte können sowohl existierende oder selbst erstellte
Interaktionsobjekte aber auch Verbindungen zu Datenbanken oder anderen
Diensten sein.
Die registrierten Objekte werden abhängig von den geforderten Rechten für
den Bezeichner und den gewährten Rechten des Benutzers (de-)aktiviert. Das
Wissen, auf welche Weise das Objekt aktiviert bzw. deaktiviert werden soll,
ist im zugehörigen Activation-Adapter gekapselt. Wechselt der Benutzer oder
werden Rechte neu zugewiesen, erfährt dies das Activation-Management auf
die gleiche Weise wie die Security-Facade. Daraufhin kann es alle registrierten Objekte den neuen Bedingungen entsprechend anpassen. Somit besteht
die Möglichkeit, nicht nur die Ausführung eines bestimmten Code-Blocks zu
verhindern, sondern ebenso das zugeordnete Interaktionsobjekt, gemäÿ den
in Abschnitt 3.1 geschilderten Varianten, zu markieren.
Es folgt ein kleines Beispiel, das verdeutlicht, wie die einzelnen Komponenten verwendet werden:
Eine Anwendung beinhaltet eine sensible Funktion, die über eine Schaltäche
auf der graschen Benutzungsoberäche erreichbar ist.
Um diese Funktion zu schützen, wird der betreende Code innerhalb eines
Executables mit dem Bezeichner Exec1 implementiert.
Die Schaltäche
ruft nun bei Betätigung über die Security-Facade das Executable auf. Damit
ist diese Funktion vor unberechtigter Ausführung geschützt.
Soll dem Benutzer eine optische Rückmeldung über die aktuellen Berechtigungen gegeben werden, muss lediglich diese Schaltäche zusammen mit
einem Activation-Adapter und dem Bezeichner Exec1 beim Activation-
Auswirkungen unterschiedlicher Systemanforderungen
83
Management angemeldet werden.
Wird ein Activation-Adapter verwendet, der das Interaktionsobjekt sperrt,
kann die Schaltäche nur dann betätigt werden, wenn auch das Executable
ausgeführt werden kann. Darf die Funktion nicht ausgeführt werden, ist auch
die Schaltäche gesperrt.
Um das Interaktionsobjekt zu verstecken, muss ein Activation-Adapter verwendet werden, der die Sichtbarkeit der Schaltäche steuert.
Die Abbildung 5.3 beschreibt, wann welche Nachrichten verschickt werden, um die beim Activation-Management registrierten Objekte bei einem
Benutzerwechsel oder bei Veränderungen der Berechtigungen den aktuellen
Gegebenheiten anzupassen.
Abbildung 5.3: Security-Facade-Datenuss mit Activation-Management
5.3 Auswirkungen unterschiedlicher Systemanforderungen
Der Kontext, in dem ein Softwaresystem eingesetzt werden soll, stellt bestimmte Bedingungen an die Anwendung. Diese Anforderungen wirken sich
auf die Benutzungsoberäche und die Autorisierungsmechanismen aus.
So
erlaubt die Verwendung eines Rich-Clients zwar eine reichhaltigere Benutzungsoberäche als ein Thin-Client, aber da der Rich-Client ein Arbeiten
ohne Serververbindung fordert, muss auch die Authentizierung und Autorisierung ohne Verbindung zum Server möglich sein.
Ebenso ist die Betriebsart der Software entscheidend.
Wird der Klient je-
desmal neu gestartet, wenn ein Benutzer Aufgaben erledigen möchte, kann
es ausreichen, die Berechtigungen nur beim Starten der Anwendung zu überprüfen. Läuft die Anwendung jedoch im Dauerbetrieb, also 24 Stunden an
7 Tagen die Woche, mit wechselnden Benutzern, reicht dies natürlich nicht
aus. Es muss dann ein Weg gefunden werden, die Berechtigungen jederzeit
Kai Meyer
Teil 2 - Theorie
84
aktuell zu halten oder zumindest bei einem erneuten Log-in zu überprüfen.
D.h. im Dauerbetrieb sind Autorisierungs-Lösungen, die auf dem Plug-In(De-)Aktivierungs-Konzept (Abschnitt 5.1) aufsetzen nicht praktikabel oder
nur mit Zusatzaufwand zu realisieren.
Ist die permanente Aktualisierung gefordert kann auch JAAS (Abschnitt 4.3)
nicht verwendet werden, da JAAS nur beim Starten die Policy-Datei ausliest
und eine nachträgliche Änderung ohne Neustart nicht möglich ist.
Eine weitere wichtige Rahmenbedingung ist die Granularität der Rechte.
Sind die zu schützenden Funktionen groÿ und komplex genug, um sie sinnvoll
auf Plug-Ins abzubilden, können Plug-In-(De-)Aktivierungsstrategien durchaus eingesetzt werden. Bei feiner strukturierten Rechten ist dieses Vorgehen
nicht zu empfehlen. Stattdessen können XACML (Abschnitt 4.4), JAAS oder
die Security-Facade (Abschnitt 5.2) eingesetzt werden.
Selbst Vorgaben für die Gestaltung der Benutzungsoberäche können die
Wahl des Autorisierungsmechanismus beeinussen. Wird für eine möglichst
konstante GUI gefordert, dass sämtliche Funktionen und Optionen stets
sichtbar sind (nur eventuell gesperrt), kann die Autorisierung ebenfalls nicht
über (De-)Aktivierung von Plug-Ins realisiert werden. Auf diese Weise würden die nicht gewährten Elemente in der GUI fehlen. Sind die Geräte der
Benutzer nicht sehr leistungsstark (z.B. PDAs, einfache Workstations, usw.)
bietet sich hingegen die (De-)Aktivierung der Plug-Ins gerade zu an, da so
das laufende Programm möglichst wenig Speicherplatz benötigt. Dies wird
durch den in der Eclipse RCP verwendeten Lazy Loading-Mechanismus
noch unterstützt.
Gerade bei sehr fein strukturierten Rechten kann die Handhabung unübersichtlich und somit auch die Administration erschwert werden. Dem entgegen
wirken kann die Verwendung von RBAC (Abschnitt 4.1) oder LDAP (Abschnitt 4.2).
Aufgrund der verschiedenen Anforderungen an ein Softwaresystem gibt
es keine universell einsetzbare Autorisierungsstrategie. Je nach geforderter
Granularität der Rechte, Darstellungsrichtlinien für die Benutzungsoberäche und Betriebsart der Software bieten sich unterschiedliche AutorisierungsKonzepte an.
Kapitel 6
Bestehende Lösungen für Eclipse
Dieses Kapitel greift die in Abschnitt 3.3 angesprochenen Autorisierungs-
Torsten Witte
methoden für die Eclipse RCP auf. Hier wird ihre Funktionsweise und Realisierung vorgestellt. Des Weiteren werden sie auf ihre Tauglichkeit untersucht
und ihre Eigenschaften ermittelt, um sie miteinander vergleichen zu können.
6.1 Rollenabhängige Plug-Ins
Wie bereits in Abschnitt 3.3 genannt, stellt Berthold Daum in [Dau05b] eine
Variante für die Realisierung von Benutzerautorisierung in Eclipse RCPs vor.
Hauptsächlich macht er dies, um zu demonstrieren wie Plug-Ins programmgesteuert (de-)aktiviert bzw. RCP-Anwendungen nur mit bestimmten Plug-Ins
gestartet werden können.
Die Situation in seiner Beispielanwendung ist folgende: Jeder Benutzer besitzt eine oder mehrere Rollen.
Jeder Rolle kann eine oder mehrere Per-
spektiven zugeordnet sein. Wenn einem Benutzer mehrere Perspektiven zur
Verfügung stehen, soll der Benutzer zwischen den für ihn zugelassenen Perspektiven umschalten können. Für die Auswahl von Perspektiven bietet sich
die Standard-Perspektivenleiste von Eclipse an. Das Problem ist, dass diese
stets alle registrierten Perspektiven verwaltet.
Eine Lösung für dieses Problem ist die programmgesteuerte (De-)Aktivierung
von Plug-Ins, um deren Perspektiven aus der Extension-Registry zu entfernen.
Wird jede Perspektive durch ein eigenes Plug-In implementiert und
werden je nach Benutzerrolle nur die wirklich benötigten (und zugelassenen) Plug-Ins aktiviert, so kann die normale Eclipse-Perspektivenleiste für
die Auswahl der Perspektiven verwendet werden.
85
Torsten Witte
Teil 2 - Theorie
86
Für die Realisierung dieser Problemlösung deniert Berthold Daum in
com.bdaum.planner seines Projektplaners einen
Extension-Point namens com.bdaum.planner.roles. Über diesen Extensiondem Anwendungs-Plug-In
Point wird eine Perspektiven-Rollen-Zuordnung ermöglicht. Gleichzeitig wird
eine Zuordnung zwischen Rolle und Plug-Ins getroen.
Ein Plug-In, das zu diesem Erweiterungspunkt beiträgt, gibt den Namen einer (ggf.
neuen) Rolle an, welche Perspektive erlaubt ist und ggf.
initial geönet werden soll und welche Plug-Ins für diese Rolle zugelassen
sind.
Die folgende
plugin.xml
des Supervisor-Plug-Ins zeigt dies am Bei-
spiel der Supervisor -Rolle. Supervisor verwalten innerhalb des Projektplaners die Projektressourcen. Projektpläne dürfen sie dagegen nicht erstellen.
Das dürfen nur Benutzer in der Planer -Rolle.
Als initiale Perspektive für
Supervisor wird daher die in dem Plug-In denierte Supervisor-Perspektive
gesetzt.
Diese Perspektive enthält die ebenfalls deklarierte ResourceView.
Die zulässigen Plug-Ins sind das Supervisor-Plug-In selbst sowie das passende Hilfe-Plug-In.
<?xml version="1.0" encoding="UTF−8"?>
<?eclipse version="3.0"?>
<plugin>
<extension point="org.eclipse.ui.views">
<category
name="Supervisor"
id="com.bdaum.planner.supervisor">
</category>
<view
name="Resources"
icon="icons/sample.gif"
category="com.bdaum.planner.supervisor"
class ="com.bdaum.planner.supervisor.views.ResourceView"
id="com.bdaum.planner.supervisor.views.ResourceView">
</view>
</extension>
<extension point="org.eclipse.ui. perspectives">
<perspective
class ="com.bdaum.planner.supervisor.Perspective"
xed="true"
id="com.bdaum.planner.supervisor.perspective"
name="Supervisor"/>
</extension>
<extension point="com.bdaum.planner.roles">
<role name="Supervisor">
<perspective
id="com.bdaum.planner.supervisor.perspective"
initial ="true"/>
<plugin id="com.bdaum.planner.supervisor"/>
Rollenabhängige Plug-Ins
87
<plugin id="com.bdaum.planner.supervisor.help"/>
</role>
</extension>
</plugin>
Die
plugin.xml
des TaskPlanner-Plug-Ins ist analog dazu aufgebaut.
Nur wird dort die Planer-Rolle deniert, die TaskPlanner-Perspektive als
initiale Perspektive festgelegt und das TaskPlanner-Plug-In selbst sowie dessen Hilfe-Plug-In der Planer-Rolle zugeordnet.
Alle Plug-Ins, die der Benutzer aufgrund seiner Rollen nicht verwenden
darf, müssen nun von der Anwendung ausgeschlossen werden.
in der
Application-Klasse
Dies wird
des Anwendungs-Plug-Ins erledigt, also direkt
beim Start der Anwendung. Für die Deaktivierung und Deinstallation von
Plug-Ins gibt es die Bundle-Methoden
stop()
und
uninstall()
schnitt 2.3.2).
public class Application implements IPlatformRunnable {
public Object run(Object args) throws Exception {
// Benutzer muss sich anmelden und authentiziert werden
Display display = PlatformUI.createDisplay();
Shell topLevelShell = new Shell(display, SWT.NONE);
LoginDialog dialog = new LoginDialog(topLevelShell);
dialog .open();
topLevelShell. close ();
// Der aktuelle Benutzer wird in der PlannerPlugin−Klasse gehalten
User user = PlannerPlugin.getDefault().getUser();
if (user == null)
// Shutdown
return IPlatformRunnable.EXIT_OK;
// Update durchführen, falls nötig
UpdateAction updateAction = new UpdateAction();
updateAction.run(null);
if (updateAction.isRestart())
// Restart
return IPlatformRunnable.EXIT_RESTART;
// Einmal alle Rollen laden und merken, bevor einige Plugins
// deaktiviert werden. Dies wird für den Administrator benötigt,
// der ALLE Rollen verwalten muss.
PlannerPlugin.getAllRoles();
// Plugins deaktivieren , die nicht zugelassen sind
// (abhängig von den Rollen des Benutzers)
congureSystem(user.roles );
(siehe Ab-
Teil 2 - Theorie
88
try {
int returnCode = PlatformUI.createAndRunWorkbench(display,
new ApplicationWorkbenchAdvisor());
if (returnCode == PlatformUI.RETURN_RESTART) {
return IPlatformRunnable.EXIT_RESTART;
}
}
return IPlatformRunnable.EXIT_OK;
} nally {
display .dispose ();
}
private void congureSystem(Collection roles) {
// Alle Plugins, die Benutzerrollen zugeordnet sind
Set<String> allNegotiableBundles = new HashSet<String>();
// Alle Plugins, die den aktiven Benutzerrollen zugeordnet sind
Set<String> activeBundles = new HashSet<String>();
// Erweiterungsregister
IExtensionRegistry registry = Platform.getExtensionRegistry();
// Rollendenitionen durchlaufen
for (ICongurationElement role : registry .
getCongurationElementsFor("com.bdaum.planner", "roles")) {
// Bestimmen, ob eine gegebene Rolle aktiv ist
boolean active = roles.contains(role .getAttribute("name"));
for (ICongurationElement plugin : role .getChildren("plugin")) {
// zugeordnetes Plugin
allNegotiableBundles.add(plugin.getAttribute("id"));
if (active)
activeBundles.add(plugin.getAttribute("id"));
}
}
// Nicht erlaubte Plugins entfernen
BundleContext context = PlannerPlugin.getDefault().getContext();
for (Bundle bundle : context.getBundles()) {
String id = bundle.getSymbolicName();
if (allNegotiableBundles.contains(id) && !activeBundles.contains(id)) {
try {
// Eigentlich nicht notwendig, da noch kein Plugin läuft
bundle.stop();
} catch (BundleException e) {
}
try {
bundle.uninstall ();
} catch (BundleException e) {
}
}
}
Rollenabhängige Plug-Ins
}
89
}
Beim Start der Anwendung wird der Benutzer aufgefordert, sich mit Benutzernamen und Passwort einzuloggen.
In-Klasse des Anwendungs-Plug-Ins ein
Im Erfolgsfall enthält die Plug-
User-Objekt.
Dieses
User-Objekt
enthält neben dem Benutzernamen auch eine Liste mit den Namen aller bewilligten Rollen. Schlieÿlich werden in der
configureSystem()-Methode alle
Plug-Ins von der Anwendung ausgeschlossen, die mindestens einer Rolle zugeordnet sind, aber keine dieser Rollen vom aktuellen Benutzer eingenommen
werden darf. Somit bleiben nur die Plug-Ins installiert, die entweder gar keiner Rolle oder mindestens einer Rolle des aktiven Benutzers zugeordnet sind.
Plug-Ins von Drittanbietern können also weiterhin in die Anwendung integriert werden, obwohl sie nicht den
role-Erweiterungspunkt erweitern.
Dies
kann abhängig vom Einsatzkontext ein Vor- oder Nachteil sein, widerspricht
jedoch der Erlaubnisregel, da grundsätzlich alle Fremd-Plug-Ins für jeden
Benutzer verfügbar sind (vgl. Abschnitt 1.8).
Die
configureSystem()-Methode ist so implementiert, dass mehrere Plug-
Ins zu der selben Rolle beitragen können. Die Information, welche Plug-Ins
von einer Rolle genutzt werden dürfen, muss also nicht in einem einzigen
Plug-In untergebracht sein.
Somit lassen sich vorhandene Rollen jederzeit
um neue Plug-Ins für zusätzliche Funktionalitäten oder Aufgabenbereiche
erweitern, ohne existierende Plug-Ins anpassen zu müssen.
Allerdings müssen die Zugehörigkeiten von Plug-Ins zu Rollen bereits zur
Entwicklungszeit bekannt sein und können im späteren Betrieb nur über Manipulation der jeweiligen
plugin.xml
verändert werden. Dementsprechend
können die Zugehörigkeiten nicht zur Laufzeit konguriert werden. Zusätzlich muss bei der Zuordnung von Plug-Ins zu Rollen darauf geachtet werden,
dass die von einem Plug-In vorausgesetzten Plug-Ins generell oder zumindest
für dieselbe Rolle verfügbar sind. Ansonsten kann das Plug-In nicht aufgelöst
werden.
Damit ein Benutzer von einem neuen Recht Gebrauch machen kann, ist ein
Neustart und ein Update der Anwendung nötig (wie in der
der
Application-Klasse zu sehen ist).
run()-Methode
Dies reicht in einigen Einsatzgebieten
aus. Beim Entzug von Rechten fällt dieser Umstand allerdings schwerer ins
Gewicht. Solange ein Benutzer seine Anwendung nicht neu startet, kann er
mit Plug-Ins arbeiten, für die er keine Berechtigung mehr besitzt.
Ein Neustart der Anwendung ist auch für einen einfachen Rollenwechsel erforderlich. Plug-Ins, die für die neue Rolle erlaubt sind, könnten beim vorherigen Log-in deinstalliert worden sein und sind über die Extension-Registry
nicht mehr verfügbar.
Teil 2 - Theorie
90
Berthold Daum erkennt diese Probleme und schreibt:
[. . . ] Allerdings wird die Verwaltung der Konguration durch
ein solches Vorgehen erschwert.
Ändern sich die Zuordnungs-
regeln, so müssen Plugins aktualisiert werden.
Auÿerdem ist,
wenn bestimmte Features deaktiviert sind, nicht mehr alle Kongurationsinformationen sichtbar. Eine exiblere Möglichkeit ist
die Denition einer eigenen Kongurationsdatei (z.B. im XMLFormat). Eine solche Datei kann leicht zwischen Server und Client ausgetauscht werden. Sie muss natürlich lokal auf dem Klienten gespeichert werden, um auch im Oine-Fall verfügbar zu
sein. Die Auswertung kann dann über einen Kongurationsmanager erfolgen, der vom Anwendungs-Plugin aus erreichbar sein
sollte. Hier können bei kommerziellen Projekten auch Lizenzen
geprüft werden, wenn bestimmte Funktionen abhängig von der jeweiligen Lizenz sind.
Es versteht sich, dass auch die Kongu-
rationsdateien digital signiert sein sollten, um Manipulationen
vorzubeugen. [Dau05b, S.456]
Auf genauere Anfrage zu seinem vorgestellten Ansatz antwortet Daum:
[. . . ] Dass diese Art der Rollenzuordnung für die Praxis zu
starr ist, versteht sich. In der Regel wird man eher mit einer separaten Kongurationsdatei arbeiten, und zur Laufzeit statt der
ExtensionRegistry diese Kongurationsdatei auswerten. So arbeitet z.B. der IBM Workplace Managed Client [. . . ], eine kommerzielle Erweiterung der Eclipse Rich Client Platform.
Sie sorgt
insbesondere dafür, dass rollenbasierte Desktops im Zusammenspiel mit den IBM Workplace Collaboration Services zentral verwaltet und konguriert werden können. [E-Mail von B. Daum an
T. Witte]
Die komplette Beispiel-Anwendung ist in [Dau05b] beschrieben und kann
unter [Dau] heruntergeladen werden.
Zusammenfassung
Dieser Ansatz eignet sich für Anwendungen, in denen die Anforderungen
folgendes zulassen:
Eclipse-JAAS
91
Kriterium
Eigenschaft
Autorisierungs-Ebene
Plug-Ins
Filterregel
Verbotsregel
GUI-Anpassung
verstecken, über Plug-In-Mechanismus
Rollen-/Rechtezuordnung
sehr starr, zur Entwicklungszeit, nicht
durch Anwender
Anpassung an veränderte Rechte
erst nach Neustart des Clients, Update
notwendig
[Dau05b, S.15, S.22, S.74, S.260, S.453 ]
6.2 Eclipse-JAAS
Eclipse-JAAS macht sich ebenfalls das Plug-In-Konzept von Eclipse zu Nutze.
Das Framework erweitert die Eclipse RCP so, dass der Java Authentication
and Authorization Service zur Authentizierung und Autorisierung von Benutzern verwendet wird.
LoginModule
und
CallbackHandler
können über
Erweiterungspunkte kombiniert und konguriert werden. Dies erlaubt einen
hohen Freiheitsgrad bei der Auswahl der Authentizierungs-Technologie, z.B.
von einem einfachen Log-in-Dialog über Smartcards bis zu FingerabdruckScannern.
Die Autorisierung ndet auf Plug-In-Ebene statt. Ob ein Benutzer (in seiner Rolle) für ein Plug-In autorisiert ist, wird über das eingeloggte
Subject
und die jeweilige Plug-In-Id entschieden. Das geschieht in einem oder mehreren Exemplaren des Types
IPluginAuthorization.
Der Benutzer erhält
Zugri auf ein Plug-In, falls ihm eines dieser Exemplare die Erlaubnis erteilt.
Die Grundlage, auf der das jeweilige
IPluginAuthorization-Exemplar seine
Entscheidung trit, ist freigestellt. Sie kann hart codiert sein oder eine externe Datei, ähnlich der Policy-Datei bei JAAS, zu Rate ziehen. Auch die
Anfrage bei einer Datenbank oder einem Verzeichnisdienst ist denkbar. Die
IPluginAuthorization-Exemplare werden über einen Erweiterungspunkt in
die Anwendung eingebunden. Welche Plug-In-Ids auf Benutzerberechtigung
abgefragt werden, wird ebenfalls über Erweiterungen angegeben.
Eclipse-JAAS sieht eine strikte Trennung von Kern- und rollenspezischen Plug-Ins vor, um die Autorisierung und die Verteilung der Plug-Ins zu
vereinfachen. Zu den Kern-Plug-Ins zählen:
•
Das Plug-In, das die RCP-Anwendung deniert
•
Das Plug-In, das den Code für die Authentizierung über JAAS enthält, die Orte der rollenspezischen Plug-Ins auistet (siehe unten) und
die Autorisierung für diese Plug-Ins übernimmt
Torsten Witte
Teil 2 - Theorie
92
•
Alle allgemein verwendeten Library-Plug-Ins
•
Alles, was von allen Benutzern verwendet werden darf, unabhängig von
deren Rolle
Die rollenspezischen Plug-Ins enthalten die Geschäftslogik, die nur von bestimmten Benutzerrollen verwendet werden darf. Diese Plug-Ins werden separat aufgeboten (deployed), z.B. auf einem HTTP-Server. Von ihnen werden bei jedem Start der RCP-Anwendung nur die Plug-Ins installiert und
gestartet, für die der Benutzer berechtigt ist. Die übrigen Plug-Ins bleiben
lediglich (auf dem Server) aufgeboten. Wo sich die rollenspezischen Plug-Ins
genau benden, wird als URL über Erweiterungen bzw. System-Properties
angegeben.
An dieser Stelle werden bereits einige Schwächen dieser Vorgehensweise
deutlich.
Wenn die rollenspezischen Plug-Ins auf einem separaten Server
liegen, zu dem zum Startzeitpunkt der Rich-Client-Anwendung keine Verbindung besteht, stürzt die Anwendung zwar nicht zwangsläug ab, sondern
wird ohne die rollenspezischen Plug-Ins ausgeführt.
Dies behindert aber
dennoch den Benutzer bei seiner Arbeit, falls ihm genau diese Plug-Ins fehlen.
Ein gröÿeres, sicherheitsrelevantes Problem ist, dass bei der Autorisierung
die Erlaubnisregel nicht umgesetzt ist.
Alle Plug-Ins, die sich im lokalen
plugin -Verzeichnis der RCP-Anwendung benden, sind unweigerlich in die
Anwendung eingebunden.
Da es zusätzlich ausreicht, dass nur eines der
IPluginAuthorization-Exemplare
die Erlaubnis für die Verwendung eines
Plug-Ins gibt, kann nachträglich mühelos ein Plug-In integriert werden, das
grundsätzlich den Zugri auf alle Plug-Ins erlaubt. Die Oenheit der Eclipse
RCP für Erweiterungen birgt also eine Sicherheitslücke in sich.
Wie bei JAAS auch, fehlt hier die Benachrichtigung und die automatische
Anpassung an wechselnde Berechtigungen zur Laufzeit. Sobald ein Benutzer ein weiteres Plug-In verwenden darf oder ihm die Berechtigung für die
Verwendung eines Plug-Ins entzogen wird, muss die RCP-Anwendung neu gestartet werden. Ansonsten sind die neuen Plug-Ins nicht in die Anwendung
eingebunden und die alten Plug-Ins immer noch für den Benutzer verfügbar.
Dennoch ist die Verbindung des in Java vorhandenen Java Authentication
and Authorization Service und der Eclipse RCP eine gute Idee. Besonders
für die Benutzerauthentizierung lohnt sich der Einsatz. Auf Seiten der Autorisierung besteht allerdings noch Entwicklungsbedarf.
Die Verwendung in einer eigenen RCP-Anwendung ist sehr einfach, da EclipseJAAS nur an einer Stelle direkt im Code zwischen die Eclipse RCP und die
Capabilities (Activities) in Eclipse
93
eigene RCP-Anwendung integriert wird. Anstatt im RCP-Plug-In das Interface
IPlatformRunnable
direkt zu implementieren, braucht nur von deren
JaasApplication geerbt werden. Das Starten
der Workbench geschieht von da an über Subject.doAs(...). Alles weitere
(LoginModule, CallbackHandler usw.) wird deklarativ über Erweiterungen
abstrakten Implementierung
eingebunden und beeinusst nicht den Code der eigenen Anwendung.
Das hier vorgestellte Konzept beruht auf der Version 1.0.0 von EclipseJAAS, das unter [Eclc] verfügbar ist. In Anhang C.4 bendet sich eine Beispielanwendung, der auch ein Plug-In zur Umgehung der Benutzerautorisierung beigefügt ist. Des Weiteren ist dort beschrieben, wie die Autorisierung
mit Hilfe der OSGi-Konsole (Anhang B.2.2) umgangen werden kann.
Zusammenfassung
Eclipse-JAAS besitzt folgende Eigenschaften:
Kriterium
Eigenschaft
Autorisierungs-Ebene
Plug-Ins
Filterregel
Verbotsregel
GUI-Anpassung
verstecken, über Plug-In-Mechanismus
Rollen-/Rechtezuordnung
Fest codiert oder exibel über XMLDateien, Datenbank oder Verzeichnisdienst. Dadurch auch durch Anwender
kongurierbar.
Anpassung an veränderte Rechte
erst nach Neustart des Clients
[Eclb], [Bar05], [Bar07]
6.3 Capabilities (Activities) in Eclipse
Seit Eclipse 3.0 wird eine Skalierung der Benutzungsoberäche unterstützt.
D.h.
die Benutzungsoberäche kann an die jeweilige Arbeitsaufgabe an-
gepasst werden.
gabe relevant.
Nicht jede Funktionalität ist für die aktuelle ArbeitsaufGroÿe, unübersichtliche Menüs werden somit klein gehal-
ten und dadurch übersichtlicher. Für die Skalierung lassen sich Menüs und
Menüeinträge, Werkzeugleisten und deren Einträge, Views, Editoren, Perspektiven, Preference- und Property-Pages sowie Wizards logisch in Gruppen zusammenfassen. Diese Gruppierung kann nach Funktionalität (JavaEntwicklung, Plug-In-Entwicklung) oder Benutzererfahrungen (Einfach,
Torsten Witte
Teil 2 - Theorie
94
Erfahren, Experte) stattnden.
Die einzelnen Gruppen können manu-
ell vom Benutzer oder auch programmgesteuert in der Benutzungsoberäche
ein- und ausgeblendet werden.
Zur Realisierung dieser Filterung der Benutzungsoberäche werden
pabilities
verwendet.
Ca-
Ursprünglich wurde jedoch die Bezeichnung Activi-
ties gewählt. Der Begri Capability wurde erst eingeführt, nachdem bei der
Entwicklung von Eclipse 3.0 erkannt wurde, dass Activity bereits an anderer Stelle verwendet wird.
Um Verwirrung zu vermeiden, wurden also
in der Dokumentation und in der Benutzungsoberäche Activities in Capabilities umbenannt, aber aus Kompatibilitätsgründen der Extension-Point
org.eclipse.ui.activities
und die bestehende API beibehalten.
Sowohl Perspektiven als auch Capabilities unterstützen das aktuelle Interessengebiet eines Benutzers und beziehen sich auf seine jeweilige Arbeitsaufgabe. Während Perspektiven das Layout der Oberäche, d.h. die Anordnung
von Views, Editoren usw., bestimmen und den einfachen Zugri auf häug
benötigte Funktionalitäten ermöglichen, sind Capabilities für die Filterung
nicht relevanter Funktionalität zuständig.
Und zwar solange, bis der Be-
nutzer ausdrücklich ein Interesse an der Verwendung dieser Funktionalitäten
äuÿert.
Die Aufgabe der Erstellung von Capabilities ist für Produkt-Entwickler
vorgesehen.
Sie sind dafür verantwortlich, Plug-Ins so zusammenzustellen,
dass sie sinnvoll miteinander arbeiten. Daher verstehen sie, wie die Plug-Ins
zusammen verwendet werden, und können am besten deren Funktionalitäten
in Gruppen fassen.
Plug-In-Entwickler dagegen haben meist nur ihr eige-
nes Plug-In im Fokus. Die Erstellung und Verwaltung von Capabilities wird
durch ein Entwickler-Werkzeug erleichtert, welches bei [Khe04] zu nden ist.
Die Eclipse-IDE besitzt z.B. die Capability Java Development. Sie beinhaltet sämtliche Funktionen für die Java-Entwicklung. Wenn diese Capability
abgeschaltet ist, ist die Mehrheit dieser Funktionalitäten vor dem Benutzer
versteckt.
Java-Views tauchen nicht mehr in dem Show View-Menü auf,
Java-Präferenzen sind nicht mehr in den Präferenzen sichtbar usw.
Alle Capabilities können von dem Benutzer über Preference Pages konguriert sowie ein- und ausgeschaltet werden. Damit die Benutzer sich nicht
merken müssen, wann sie welche Capability (de-)aktivieren müssen, um an
die gewünschten Funktionen zu kommen, können
tet werden.
Trigger Points eingerich-
Trigger Points sind z.B. Aktionen, die als Einstiegspunkt in
einen neuen/anderen Aufgabenbereich dienen.
Wird so ein Trigger Point
ausgelöst, wird die zugehörige Capability aktiviert und deren Beiträge in der
Benutzungsoberäche angezeigt.
Auch die Capability Java Development besitzt solche Trigger Points. Dabei
Capabilities (Activities) in Eclipse
95
handelt es sich um die kleine Menge der Funktionen, die für die Entwicklung
von Java-Anwendungen nötig sind und stets in der GUI sichtbar bleiben,
selbst wenn die Capability Java Development abgeschaltet ist.
Über diese
Trigger Points bekundet der Benutzer ausdrücklich sein Interesse an den
zusätzlichen Funktionalitäten der Java Development -Capability. Der New
Java Project-Eintrag in dem New-Wizard ist so ein Trigger Point. Sollte der
Benutzer ein neues Java-Projekt anlegen, werden die übrigen Java Funktionalitäten sofort sichtbar und für den Benutzer verfügbar. Schlieÿlich wird er
sie zur weiteren Entwicklung seines Projektes benötigen.
Des Weiteren können einzelne Capabilities untereinander in Beziehung
stehen. So werden bei Aktivierung einer Capability ebenfalls alle Capabilities aktiviert, von denen die aktuelle Capability abhängig ist. Beispielsweise
macht die Capability Plug-In Development ohne Java Development keinen
Sinn, da Plug-Ins in Java geschrieben werden.
Das Konzept der Skalierung der Benutzungsoberäche über Capabilities
lässt sich auch auf Benutzerrollen übertragen.
In den Eclipse-Newsgroups
wird dies häug vorgeschlagen. Anstatt eine Capability Java Development
oder Plug-In Development anzulegen, ist eine Capability Administrator, Gast,
Rolle A oder Rolle B denkbar. Auf diese Weise können in der Benutzungsoberäche bestimmte Erweiterungen nur bestimmten Benutzern mit der jeweiligen Rolle angezeigt werden. Da Capabilities für die Produktentwicklung
gedacht sind, brauchen die einzelnen Rollen bei der Entwicklung der Plug-Ins
noch nicht bekannt sein und berücksichtigt werden.
Allerdings ist zu beachten, dass diese Vorgehensweise ohne weitere Mechanismen keine Sicherheit bietet. Die einzelnen Funktionen sind lediglich aus
der Benutzungsoberäche ausgeblendet, der Code bleibt in der Anwendung
enthalten und kann potenziell jederzeit ausgeführt werden. Ein Plug-In, dass
Preference Pages zum Umschalten von Capabilities zu der Anwendung hinzufügt, ist schnell geschrieben. Eclipse bietet diese Präferenz-Seiten bereits
an, d.h.
sie können ohne viel Aufwand eingebunden werden (siehe Quell-
code 6.1).
Die Ids der einzelnen Capabilities sind leicht zu ermitteln, um
alle Capabilities in einer Kategorie zusammenzufassen und in den PräferenzSeiten anzuzeigen. Die Integration des neuen Plug-Ins in die Anwendung ist
ebenfalls kein Problem, da es nur in das plugins -Verzeichnis eingefügt werden
braucht.
Teil 2 - Theorie
96
Quellcode 6.1: plugin.xml eines Plug-Ins, das Preference Pages für Capabilities einbindet
<?xml version="1.0" encoding="UTF−8"?>
<?eclipse version="3.2"?>
<plugin>
...
<extension point="org.eclipse.ui.preferencePages">
<page
class ="org.eclipse . ui . activities .ActivityCategoryPreferencePage"
id="MyPlugin.capabilitiesPreferencePage"
name="Capabilities">
</page>
<page
class ="org.eclipse . ui . activities .ActivitiesPreferencePage"
id="MyPlugin.advancedCapabilitiesPreferencePage"
name="Advanced Capabilities Settings">
</page>
</extension>
</plugin>
Die CD zu dieser Arbeit enthält eine Beispiel-Anwendung, die Kimberly
Horne auf der EclipseCon 2005 zur Demonstration von Benutzerautorisierung über Capabilities vorgestellt hat (siehe Anhang C.5).
Das Projekt
beinhaltet ein Anwendungs-Plug-In, das die beiden Benutzerrollen Employee
und Manager über Capabilities umsetzt. Ein Employee verfügt über weniger
Views als ein Manager. Dabei setzt die Manager-Capability die EmployeeCapability voraus, d.h. alles was ein Employee darf, darf auch ein Manager.
Das Beispiel veranschaulicht, wie die einzelnen Views über Id-Muster von
den beiden Capabilities geltert werden. Diese Muster werden in der Form
<Plug-In-Id>/<Contribution-Id> angegeben. So gehören alle Views, deren
Id dem Muster
.*/man\..*
entsprechen, zu der Manager-Rolle.
Eine ge-
nauere Erläuterung zu diesen Patterns ist in [Hor06] enthalten.
Zusätzlich enthält das Beispiel ein von dem Autor dieses Abschnittes geschriebenes Plug-In, mit dem der Autorisierungsmechanismus umgangen werden kann. Dieses Plug-In wurde ohne Einblick in den Quellcode der RCPAnwendung von Kimberly Horne entwickelt.
Zusammenfassung
Capabilities sind aus folgenden Gründen für die Benutzerautorisierung interessant:
•
Einzelne Teile von Plug-Ins sind vor dem Benutzer verborgen oder für
ihn sichtbar (nicht entweder das gesamte Plug-In oder gar nichts)
Capabilities (Activities) in Eclipse
•
97
Geltert werden: Neu-, Import-, Export-Wizards; die Show ViewsListe; die Open Perspective-Liste; Werkzeugleisten-, Menü-Beiträge;
Präferenz-, Eigenschafts-Seiten; Editoren; Suche; Hilfe
•
Abhängigkeiten bzw. Hierarchien zwischen Capabilities sind denierbar (activityRequirementBinding)
•
Die Gruppierung von Capabilities in Kategorien ist möglich (categoryActivityBinding)
•
Standardmäÿig sind alle Capabilities deaktiviert (defaultEnablement)
•
Erstellungszeitpunkt erst bei der Produkt-Entwicklung
Der reine Capability-Ansatz eignet sich ohne weitere Mechanismen aus
folgenden Gründen nicht für Benutzerautorisierung:
•
Bietet kaum Sicherheit, da lediglich eine Ausblendung der jeweiligen
(Menü-)Einträge stattndet
•
Capabilities sind jederzeit wieder freischaltbar, z.B. durch ein neues
Plug-In oder Preference Pages
•
Einmal aktive Capabilities können nicht zurückgenommen werden
•
Aktueller Zustand der Capabilities bleibt nach dem Ausschalten der
Anwendung erhalten
•
Rollen stehen nach der (Produkt-)Entwicklung fest, d.h.
sie können
ohne in den Quellcode einzugreifen nicht verändert werden
•
Nicht auf einzelne Interaktionsobjekte wie Buttons oder Textfelder anwendbar
Kriterium
Eigenschaft
Autorisierungs-Ebene
Actions,
Views,
Editoren,
Wizards,
usw.
Filterregel
Verbotsregel
GUI-Anpassung
verstecken,
über
Capability-
Mechanismus
Rollen-/Rechtezuordnung
sehr
starr,
zur
(Produkt-)Entwick-
lungszeit, nicht durch Anwender
Anpassung an veränderte Rechte
erst nach Neustart des Clients, Update
notwendig
[Hor05a], [Hor05b], [Hor06], [HM04], [Cre04]
Teil 2 - Theorie
98
6.4 Fazit
Torsten Witte
Bei Verwendung der Plug-In-(De-)Aktivierung ist eine Trennung von Kernund rollenspezischen Plug-Ins, wie sie in Abschnitt 6.2 beschrieben ist,
durchaus sinnvoll. Ebenso ist es wichtig, dass die Erlaubnisregel umgesetzt
wird, da sonst eine Umgehung der Autorisierung durch Fremd-Plug-Ins auf
einfache Weise möglich ist.
Der Capability-Ansatz bietet ohne weitere Si-
cherheitsmechanismen keine ausreichende Sicherheit für die Benutzerautorisierung.
Abschlieÿend darf nicht vergessen werden, dass die Autorisierung
hier nur auf dem Client stattndet. Der Server muss ebenso stets vor unberechtigtem Zugri geschützt sein, so dass alle vertraulichen und sicherheitsrelevanten Funktionen nur von autorisierten Benutzern ausgeführt werden
können.
Die Umsetzung der Benutzerautorisierung auf der Serverseite ist
besonders wichtig, wenn die Schnittstelle (API) des Servers veröentlicht
wird und beliebig viele Clients entwickelt werden können.
Teil III
Praktischer Teil
99
Teil 3 - Praxis
100
Kai Meyer und
Torsten Witte
Der dritte Teil dieser Arbeit widmet sich der Umsetzung konkreter Projekte, in denen Benutzerautorisierung eine Rolle spielt. Dabei werden die in
den vorherigen Kapiteln diskutierten Aspekte berücksichtigt. Bereits vorgestellte Konzepte und Methoden werden verwendet, verbessert oder an das
jeweilige Projekt angepasst. Konsequenzen, die sich durch die Umsetzung in
den jeweiligen Projekten ergeben, werden angesprochen und diskutiert.
Alle Projekte setzen auf der Eclipse Rich-Client-Platform auf und zeigen, dass die erstellten Konzepte realisierbar sind. Begonnen wird mit dem
Dienstplaner-Projekt, welches das Konzept der Plug-In-(De-)Aktivierung verfolgt und die Erkenntnisse aus den Ansätzen von Berthold Daum und Neil
Bartlett aufgreift.
Anschlieÿend wird ein Taschenrechner vorgestellt, bei dem die Benutzer nur
bestimmte Operationen durchführen dürfen. Dazu wird die Security-Facade
implementiert. Der Taschenrechner dient als Vorlage für das Control System
Studio (CSS), welches das darauf folgende Kapitel füllt. Das Besondere am
CSS-Projekt ist, dass dort eine einheitliche Infrastruktur für verschiedene
Anwendungen im CSS-Rahmen entwickelt wird.
Zu diesen Anwendungen
zählt das Synoptic Display Studio, welches für Entwickler und Benutzer sogenannter synoptischer Displays gedacht ist. Für die eigens erstellten Interaktionsobjekte innerhalb der Displays können zur Laufzeit Berechtigungen
vergeben werden.
Als Abschluss dieser Arbeit wird am Ende dieses Teils nochmals auf die
Kernfrage eingegangen und die erzielten Ergebnisse zusammengefasst.
Kapitel 7
Dienstplaner
Der Dienstplaner ist eine Eigenentwicklung der beiden Autoren. Das Projekt
befasst sich mit der Entwicklung eines Softwaresystems für ein Alten- und
Pegeheim. Die Anwendung soll bei der Erstellung der monatlichen Dienstpläne für die Bereiche Pege, Küche und Reinigung unterstützen. Dazu gehört auch die Verwaltung der einzelnen Mitarbeiter, Bewohnerzahlen, Dienstzeiten, Ferien, Feiertage, Freistellungsanträge und nicht zuletzt der Dienstpläne selbst. Das Personal soll an seinem jeweiligen Arbeitsplatz, z.B. dem
Stationszimmer, jederzeit die Dienstpläne einsehen, Freistellungsanträge stellen und Notizen hinterlegen können. Der Dienstplanersteller muss u.a. die
Anzahl der Heimbewohner, die Notizen des Personals und die von der Heimleitung genehmigten Freistellungsanträge berücksichtigen.
Die Benutzer der Anwendung schauen aus unterschiedlichen Sichten auf die
einzelnen Dokumente wie Dienstpläne und Freistellungsanträge und dürfen
jeweils nur bestimmte Teile dieser Materialien bearbeiten.
Daher müssen
die Benutzer für die einzelnen Aufgaben wie das Anlegen und Erstellen von
Dienstplänen oder dem Genehmigen von Freistellungsanträgen autorisiert
werden. Diese Berechtigungen müssen nicht zwingend statisch sein. Es kann
vorkommen, dass einem Benutzer Rechte entzogen werden oder er kurzfristig
ein zusätzliches Recht erhält, z.B. weil ein Kollege krank geworden ist und
dessen Aufgaben trotzdem erledigt werden müssen.
Das Projekt verfügt derzeit über einen weit fortgeschrittenen Prototypen,
+
der als Pilotsystem (siehe [Z 98, 637 ]) eingesetzt werden kann. Dieser
Prototyp setzt den hier beschriebenen Entwurf für die Benutzerautorisierung
vollständig um.
101
Torsten Witte
Teil 3 - Praxis
102
7.1 Konzept
Torsten Witte
Der Dienstplaner wurde auf Basis der Eclipse RCP entwickelt und setzt
für die Benutzerautorisierung das Konzept der Plug-In-(De-)Aktivierung um
(siehe Abschnitt 5.1). Rechte werden also auf Plug-In-Ebene vergeben und
beziehen sich auf den Zugri auf Plug-Ins, d.h. ein Benutzer kann sämtliche
oder gar keine Funktionen eines Plug-Ins verwenden. Bei der Entwicklung
dieses Systems sind die Ansichten von Berthold Daum und Neil Bartlett mit
eingeossen. Die Eigenschaften ihrer Ansätze wurden wie in den Abschnitten 6.1 und 6.2 herausgearbeitet, um sie zu nutzen oder zu verbessern. Das
so entstandene Ergebnis wird in den folgenden Abschnitten vorgestellt.
7.1.1 Plug-In-Struktur
Bereits bei der Erstellung der Architektur zu dieser RCP-Anwendung wurde
das Konzept der Plug-In-(De-)Aktivierung für die Benutzerautorisierung berücksichtigt. So gibt es neben dem Anwendungs-Plug-In Hilfs- und LibraryPlug-Ins, die von allen Benutzern verwendet werden dürfen.
Ins bilden die Gruppe der Kern-Plug-Ins.
Diese Plug-
Alle übrigen Plug-Ins repräsen-
tieren eine Funktionalität bzw. ein Werkzeug zur Erledigung einer (Teil-)Arbeitsaufgabe und lassen sich in weitere Gruppen einteilen:
Für die Erstellung neuer Dokumente gibt es die Erzeuger-Plug-Ins.
Jedes
dieser Plug-Ins ist für die Erzeugung neuer Exemplare eines Dokumenttypes verantwortlich.
Da es vorkommt, dass verschiedene Benutzer(-rollen)
die selbe Ansicht auf ein Dokument besitzen, doch der eine Benutzer das
Dokument bearbeiten darf und der andere nicht, sind weitere Plug-Ins in
Betrachtungs- und Bearbeitungs-Plug-Ins eingeteilt. Um Logik nur einmal zu
implementieren und vorhandenen Code wiederverwenden zu können, bauen
die Bearbeitungs-Plug-Ins auf den Betrachtungs-Plug-Ins auf. Dadurch sind
sie eng miteinander gekoppelt. Betrachtungs-Plug-Ins können ohne entsprechendes Bearbeitungs-Plug-In verwendet werden. Bearbeitungs-Plug-Ins verwenden oder erweitern jedoch einige Java-Klassen eines Betrachtungs-PlugIns, nämlich genau um die Editier-Funktionen. Daher können BearbeitungsPlug-Ins nicht ohne ihr Betrachtungs-Plug-In ausgeführt werden. In Abbildung 7.1 sind diese Plug-In-Abhängigkeiten am Beispiel von Dienstplänen
grasch dargestellt.
In Bezug auf die Autorisierung tauchen an dieser Stelle keine Konikte auf.
Wenn ein Benutzer das Recht besitzt, einen Dokumenttyp (z.B. Dienstpläne)
zu bearbeiten, dann darf er die Dokumente auch ansehen und lesen (zumindest den Ausschnitt, den ihm das Betrachtungs-Plug-In bietet).
Durch diese Zuweisung der Plug-In-Verantwortlichkeiten kann Benutzern mit-
Dienstplaner
103
Abbildung 7.1: Dienstplaner: Plug-In-Struktur
tels der Plug-In-(De-)Aktivierung das Werkzeug für die Erzeugung, die Betrachtung und die Bearbeitung von Dokumenten gegeben oder entzogen werden.
Alle Plug-Ins, die von mindestens einem Benutzer verwendet werden dürfen, sind auf einer Update-Site (siehe Abschnitt 2.5) innerhalb des lokalen
Netzwerkes aufgeboten. Dabei sind alle Plug-Ins, die für die Ausführung der
RCP-Anwendung unabdingbar sind und von jedem Benutzer verwendet werden dürfen, in einem Kern-Feature zusammengefasst. Dieses Feature deckt
sich mit der Gruppe der Kern-Plug-Ins. Weitere, rollenspezische Plug-Ins
sind dagegen in separaten Features untergebracht. Diese Art der Einteilung
der Plug-Ins in Features ist zwar nicht zwingend notwendig, erleichtert dem
Administrator jedoch die Arbeit, wie später in Abschnitt 7.1.3 gezeigt wird.
7.1.2 Funktionsweise
Direkt nach dem Start des Clients wird auf der Update-Site (sofern erreichbar) nach verfügbaren Updates für bereits lokal installierte Plug-Ins sowie
nach neuen Plug-Ins gesucht und ggf. installiert (siehe Abschnitt 2.5). Anschlieÿend muss der Benutzer sich über einen Log-in-Dialog authentizieren.
Nach erfolgreicher Anmeldung werden die Ids aller erlaubten Plug-Ins für diesen Benutzer ermittelt. Dies geschieht über eine Anfrage bei einer Datenbank
auf dem zentralem Server. Nun werden alle Plug-Ins gestoppt und deinstalliert, für die der Benutzer nicht berechtigt ist und die nicht von gewährten
Plug-Ins vorausgesetzt werden. Somit verbleiben auf der Plattform nur die
Plug-Ins für die der Benutzer berechtigt ist und die er zu deren Ausführung
benötigt. Erst dann wird die Workbench gestartet und der Benutzer kann
Teil 3 - Praxis
104
mit seiner Arbeit beginnen.
Die Abbildungen 7.2 und 7.3 zeigen Auszüge
von der Benutzungsoberäche mit vollen und eingeschränkten Zugrisrechten. Es ist deutlich zu erkennen, dass Benutzer nur die Funktionen zu sehen
bekommen, die sie auch durchführen dürfen.
(a) Vollzugri
(b) Eingeschränkter Zugri
Abbildung 7.2: Dienstplaner: Menüleiste
Für einen Benutzer(-rollen)wechsel ist jeweils ein Neustart der Clientanwendung nötig. Dadurch werden die einzelnen Plug-Ins und Berechtigungen
aktuell gehalten. Der Benutzer verfügt immer nur über die Plug-Ins, für die
er beim Start der Anwendung autorisiert ist.
7.1.3 Benutzerverwaltung und Rechtevergabe
Abbildung 7.4 zeigt die Benutzungsoberäche für die Verwaltung von Benutzern und deren Berechtigungen. Im Gegensatz zu RBAC (Abschnitt 4.1) sind
die Benutzer(-objekte) intern nicht über Rollen mit ihren Rechten verknüpft,
obwohl die Benutzer natürlich innerhalb des Systems unterschiedliche Rollen einnehmen.
Stattdessen sind die Zugrisrechte auf die Plug-Ins direkt
an die Benutzer(-objekte) gebunden.
Auf diese Weise ist der Administra-
tor in der Lage, einem einzelnen Benutzer direkt das Zugrisrecht auf ein
Plug-In zu entziehen oder zu gewähren. Dadurch ist die Autorisierung auch
für Krankheits- oder Urlaubsfälle exibel, bei denen ein Benutzer kurzzeitig
Dienstplaner
105
(a) Vollzugri
(b) Eingeschränkter Zugri
Abbildung 7.3: Dienstplaner: Kontextmenü
(Teil-)Aufgaben eines anderen Benutzers erledigen muss. Ein weiterer Grund
für die direkte Anbindung ist, dass in diesem Anwendungskontext die Anzahl
der Benutzer überschaubar und jeder Benutzer persönlich bekannt ist.
Welche Plug-Ins ein Benutzer letztendlich verwenden darf, wird in einer zentralen Datenbank auf dem Server in Form der gewährten Plug-In-Ids festgehalten.
Die einfache und exible Unterstützung der Rechtevergabe ist durch die
Bildung von Rechtemustern und Benutzergruppen gegeben.
Rechtemuster
dienen als vorgefertigte Schablonen für die Rechtevergabe und können in
Anlehnung an RBAC auch als Rollen verstanden werden. Ihre Verwendung
ist vorteilhaft für das Anlegen mehrerer (Einzel-)Benutzer, die ähnliche Berechtigungen benötigen, oder für den einfachen Wechsel von Rollen unter
den Mitarbeitern des Heimes. Rechtemuster enthalten eine Menge von gewährten Plug-Ins und können individuell erstellt und unter einem Namen
abgespeichert werden.
Bei der Zuweisung von Rechten an einen Benutzer
können diese Muster aufgerufen werden, so dass der Benutzer nur die Rechte
aus dem Muster zugewiesen bekommt. Anschlieÿend können die Rechte des
Benutzers unabhängig von dem verwendeten Muster jederzeit erweitert oder
eingeschränkt werden. Dies erleichtert dem Administrator die Arbeit, denn
er muss sich nicht merken, welche Rechte ein Mitarbeiter in einer Rolle erhalten muss und braucht ihm nicht die Berechtigung für jedes Plug-In einzeln
zu geben. Die Auswahl des betreenden Musters reicht aus. Darüber hinaus
vergisst der Administrator nicht, einem Benutzer den Zugri auf Plug-Ins
Teil 3 - Praxis
106
Abbildung 7.4: Rechtevergabe im Dienstplaner
zu entziehen, wenn er dessen Berechtigungen mit Hilfe von Rechtemustern
an eine andere Rolle anpasst. In Abbildung 7.4 ist für den Benutzer Donald
Duck das Rechtemuster Pegepersonal mit den entsprechenden Berechtigungen ausgewählt.
Neben Einzelbenutzern unterstützt das System auch Benutzergruppen.
So können mehrere Benutzer gleichzeitig unter einem Gruppenbezeichner angemeldet sein. Zwar geht dadurch die genaue Information verloren, welcher
Benutzer aus dieser Gruppe ein Dokument bearbeitet hat, aber da es sich
hier nur um kleine Gruppen handelt und das jeweilige Bearbeitungsdatum
mit Uhrzeit im Dokument gespeichert wird, lässt sich der Bearbeiter anhand seiner Dienstzeiten in den meisten Fällen zurückverfolgen. Dies reicht
Dienstplaner
107
innerhalb dieses Projektes aus. Am sinnvollsten ist der Einsatz von Benutzergruppen für Benutzer, die keine Bearbeitungsrechte besitzen. Der Vorteil
von Benutzergruppen ist, dass der Administrator nicht jeden Benutzer einzeln
verwalten muss. Für jedes Gruppenmitglied gelten die selben Berechtigungen.
Wie bei allen rollenspezischen Funktionalitäten ist auch die Benutzerverwaltung in eigene Plug-Ins aufgeteilt. So hat nur ein Administrator, bzw.
ein Benutzer, der autorisiert ist, Berechtigungen zu vergeben, Zugri auf
diese Plug-Ins. Dieses Zugrisrecht kann ein Administrator auch an andere
Benutzer weitergeben oder von ihnen entziehen. Dabei ist sichergestellt, dass
mindestens ein Benutzer den Zugri auf diese Plug-Ins besitzt und Rechte
vergeben kann.
bzgl.
Innerhalb dieses Projektes ist die Frage aus Abschnitt 1.7
der Vorgehensweise beim Entzug von weitergereichten Rechten auf-
grund der überschaubaren Anzahl von Benutzern so beantwortet worden,
dass die weitergereichten Rechte bestehen bleiben. D.h. wenn Administrator
A Benutzer B das Zugrisrecht auf das Rechtevergabe-Plug-In erteilt und B
daraufhin anderen Benutzern weitere Rechte gibt, dann bleiben diese Berechtigungen bestehen, auch wenn A das Recht der Rechtevergabe von B wieder
entzieht.
Damit der Administrator stets den Überblick über alle verfügbaren PlugIns besitzt und er selbst nicht für alle Plug-Ins autorisiert sein muss, arbeiten
die Plug-Ins für die Rechte- und Rechtemusterverwaltung auf der Update-Site
für das System. Von dort werden die einzelnen Features und deren enthaltenen Plug-Ins ausgelesen und auf der Benutzungsoberäche in Form einer
Baumstruktur dargestellt. Die sinnvolle Einteilung der Plug-Ins in einzelne
Features sorgt also für einen besseren Überblick und unterstützt den Administrator bei der Benutzerautorisierung. So kann er z.B. ohne Bedenken allen
Benutzern alle Plug-Ins aus dem Kern-Feature erlauben.
Veränderungen an den Berechtigungen eines eingeloggten Benutzers werden zur Laufzeit des Clients nicht berücksichtigt. So kann der Benutzer seine
begonnene Arbeit zu Ende führen und bekommt erst nach erneuter Anmeldung die neuen Berechtigungen zugewiesen. Nachdem der Administrator die
Berechtigungen eines Benutzers an neue Gegebenheiten angepasst hat, ist
er jedoch in der Lage, einzelne oder alle aktiven Clientanwendungen zu benachrichtigen und ggf. herunterzufahren. Dadurch erzwingt er eine sofortige
Aktualisierung der Plug-Ins und Berechtigungen auf Clientseite. Somit kann
der Administrator verhindern, dass Benutzer mit Plug-Ins arbeiten, zu denen
sie keine Berechtigung mehr besitzen.
Teil 3 - Praxis
108
7.2 Fazit
Torsten Witte
Die vorgestellte Architektur nutzt das vorhandene Plug-In-Konzept dazu, die
Anforderungen an die Benutzerautorisierung exibel zu erfüllen.
Dadurch
kann jeder Benutzer nur die ihm zugeteilten Plug-Ins an jedem Rechner in
+
seiner Arbeitsumgebung (siehe [Z 98, S.86 ]) verwenden, denn auf jedem
Clientrechner sind immer alle Plug-Ins installiert, die auf der Update-Site
verfügbar sind. Ein Administrator ist in der Lage, die Zugrisrechte sowohl
für bereits vorhandene als auch für neu verfügbare Plug-Ins zu vergeben und
anzupassen.
Da die RCP-Anwendung oen für Erweiterungen ist, muss sichergestellt
sein, dass keine unerwünschten Fremd-Plug-Ins in die Anwendung gelangen.
Durch die Umsetzung der Erlaubnisregel ist grundsätzlich die Verwendung
aller (Fremd-)Plug-Ins verboten. Nutzer können zwar auf ihren Arbeitsrechnern neue Plug-Ins in die Anwendung integrieren, z.B. durch Hineinkopieren in das plugins -Verzeichnis. Diese werden jedoch während des Autorisierungsvorgangs wieder aus der Anwendung entfernt. Ein Administrator muss
explizit die Erlaubnis für die Nutzung der Plug-Ins erteilen und sie auf der
Update-Site bereitstellen. Durch die nötigen Neustarts der Clientanwendung
beim Benutzerwechsel und dem Zusammenspiel zwischen der Benutzerautorisierung und der Update-Site bleibt stets eine aktuelle Autorisierung auf den
Clients gewährleistet.
Theoretisch ist ein Umgehen des Autorisierungsmechanismus zwar möglich, nämlich durch Austauschen eines bereits gewährten Plug-Ins durch eines mit gleicher Id. Dies kann jedoch durch Signieren der einzelnen Plug-Ins
verhindert werden. Wenn sichergestellt wird, dass in der Clientanwendung
nur Plug-Ins gestartet werden, die von bestimmten Personen oder Instanzen signiert sind, können keine Fremd-Plug-Ins unter falscher Id ausgeführt
werden. Auch das Einbinden von Plug-Ins nach dem Autorisierungsvorgang,
z.B. über die OSGi-Konsole, muss überwacht und verhindert werden.
Die Intergration eines einzelnen Plug-Ins des Dienstplaners in eine andere
RCP-Anwendung wird durch die starke Abhängigkeit zu dem
DienstplanRCP-
Plug-In erschwert.
Die Information, welcher Benutzer welches Plug-In ausführen darf, kann
zusätzlich auf Clientseite in einer signierten, verschlüsselten und durch eine
Prüfsumme gesicherten Datei festgehalten werden. So ist ein Start der Anwendung ausschlieÿlich mit den gewährten Plug-Ins auch ohne Serververbindung möglich. Diese Datei muss bei erneuter bestehender Serververbindung
stets aktualisiert werden.
Da Eclipse standardmäÿig die letzte Konguration der Clientanwendung
vor deren Beendigung speichert, um sie beim erneuten Start wieder herzustel-
Dienstplaner
109
len, tauchen bei einem Rollenwechsel ggf. Probleme auf. Grundsätzlich ist
aus gebrauchstauglicher Sicht der Software nichts gegen die Wiederherstellung der zuletzt verwendeten Ansicht, d.h. der zuletzt aktiven Perspektive
mit allen zuletzt geöneten Views und Editoren, einzuwenden. So ndet der
Benutzer die Anwendung stets so vor, wie er sie verlassen hat. Doch da hier
mehrere Benutzer die selbe Anwendung nutzen und es nun vorkommen kann,
dass ein Plug-In, das genau diese Perspektive, eine der Views oder den Editor
bereitstellt, für die neu angemeldete Benutzerrolle nicht verfügbar ist, kann
Eclipse die Konguration nicht reproduzieren. So erscheint ein Hinweisfenster mit der Meldung, dass das zuletzt verwendete Layout der Workbench
nicht wieder hergestellt werden konnte.
Um dies zu umgehen, gibt es die
einfache Möglichkeit, die letzte Konguration stets zu löschen und immer
mit der Willkommensseite oder einer Standard-Perspektive zu starten. Aus
gebrauchstauglicher Sicht ist die Variante, die zuletzt verwendete Konguration benutzerabhängig zu speichern und wieder herzustellen allerdings die
bessere Wahl.
Wenn Benutzergruppen eingesetzt und deren Berechtigungen nur sehr
selten verändert werden, wird die Anzahl der wechselnden Log-ins und der
damit verbundenen Neustarts des Clients gering gehalten. So kann z.B. im
Stationszimmer den ganzen Tag lang ein Benutzer unter der Benutzergruppe
Pege eingeloggt sein und das gesamte Pegepersonal darunter arbeiten.
Die Entwicklung neuer Plug-Ins für den Dienstplaner ist technisch gesehen unabhängig von dem hier verwendeten Autorisierungsmechanismus. Es
müssen bei der Entwicklung der Plug-Ins keine speziellen Java-Klassen oder
Erweiterungspunkte verwendet werden. Wichtig ist lediglich die Abbildung
der einzelnen Arbeitsaufgaben und -abläufe auf Plug-Ins. Die Erlaubnis für
den Einsatz der Plug-Ins kann später aus der Anwendung heraus individuell
vergeben werden, wenn die Plug-Ins auf der Update-Site aufgeboten werden.
Die beschriebene Plug-In-Struktur verhindert darüber hinaus die Duplizierung von Code.
Zur weiteren Unterstützung des Administrators fehlt zum Erstellungszeitpunkt dieser Arbeit eine automatische Ermittlung bzw. Überprüfung der
jeweils benötigten Plug-Ins bei der Rechtevergabe, wie sie aus der Startkonguration oder dem Update-Manager in der Eclipse-IDE bekannt ist (siehe
Anhang B.2.1).
Darüber wäre der Administrator in der Lage, bereits bei
der Vergabe von Rechten die Konguration der Plug-Ins zu überprüfen und
herauszunden, ob der Benutzer für alle benötigten Plug-Ins eines gewährten
Plug-Ins ebenfalls autorisiert ist.
Teil 3 - Praxis
110
7.3 Zusammenfassung
Torsten Witte
Mit Hilfe der von der Eclipse RCP gelieferten Möglichkeiten wie dynamische
(De-)Aktivierung von Plug-Ins, automatischen Updates bereits installierter
Plug-Ins und Installation neuer Plug-Ins sowie Verwendung einer UpdateSite, gelingt es, Benutzerautorisierung sinnvoll zu realisieren. Der hier umgesetzte Ansatz greift zuvor diskutierte Aspekte von Berthold Daum und
Neil Bartlett auf, vereint sie miteinander und nutzt deren Eigenschaften und
Vorteile. Damit wurde folgendes Ergebnis erreicht:
Kriterium
Eigenschaft
Autorisierungs-Ebene
Plug-Ins
Filterregel
Erlaubnisregel
GUI-Anpassung
verstecken, über Plug-In-Mechanismus
Rollen-/Rechtezuordnung
exibel, durch Anwender kongurierbar
Anpassung an veränderte Rechte
erst nach Neustart des Clients, Update
notwendig; Neustart des Clients kann
erzwungen werden
Da die gesamte Dienstplaner-Anwendung sehr umfangreich ist, haben die
Autoren darauf verzichtet, das Projekt auf der beiliegenden CD zur Verfügung zu stellen.
Kapitel 8
Taschenrechner
Der in diesem Kapitel beschriebene
Taschenrechner dient als Beispielim-
plementierung des in Abschnitt 5.2 vorgestellten Konzepts zur Benutzerautorisierung (Security-Facade). Er wurde auch als funktioneller Prototyp (siehe
+
[Z 98, 637 ]) bei der Entwicklung des DESY -Projektes Control System Studio (CSS) verwendet. Das Programm wurde auf Grundlage der Eclipse RCP
erstellt, doch ist die Implementierung des Konzeptes unabhängig von Eclipse.
Somit ist die reine Java-Implementierung auch auÿerhalb der Eclipse RCP
verwendbar.
Für die im Taschenrechner umgesetzte Benutzerautorisierung lässt sich
folgender Einsatzkontext zugrunde legen:
Die Schüler einer Schule dürfen einen Taschenrechner für die in ihrer Klassenstufe (Klasse 1-4) bereits behandelten Rechenarten benutzen. Die Lehrer
dürfen alle Operationen durchführen, unabhängig von der von ihnen betreuten Klassen. Der Administrator des Taschenrechners ist darüber hinaus in
der Lage, Rechte zu vergeben bzw. zu entziehen.
Der Taschenrechner bietet diverse mathematische Funktionen an.
Diese
Funktionen dürfen allerdings nur ausgeführt werden, wenn der aktuelle Benutzer die geforderten Rechte besitzt. Meldet sich ein Benutzer an, werden
die Schaltächen für die Rechenoperationen seinen Berechtigungen entsprechend freigegeben.
Zudem kann der Taschenrechner auftretende Ereignisse in einer eigenen View
anzeigen. Zu diesen Ereignissen gehören Benutzerwechsel oder die Ausführung einer geschützten Funktion.
Der Funktionsumfang des Taschenrechners ist erweiterbar, so können PlugIns von Drittanbietern zusätzliche mathematische Operationen hinzufügen.
111
Kai Meyer
Teil 3 - Praxis
112
8.1 Konzept
Kai Meyer
Die im Konzept der Security-Facade (Abschnitt 5.2) beschriebenen Komponenten und deren Zusammenspiel werden im Taschenrechner 1:1 umgesetzt.
Der Taschenrechner an sich benutzt diese Klassen, deniert allerdings ein
eigenes, domänenspezisches Executable (OperationExecutable), das das
AbstractTypedExecutable erweitert. Die angebotenen matheOperationExecutables realisiert und von
SecurityFacade geschützt.
allgemeine
matischen Operationen werden als
der
Wie in Abbildung 8.1(a) zu erkennen ist, erscheinen auf der Benutzungso-
(a) vor Log-In
(b) nach Log-In
Abbildung 8.1: Benutzungsoberäche des Taschenrechners
beräche links die Schaltächen für die Ziern, das Komma und eine Schaltäche, um die letzte Stelle der Eingabe zu löschen. Rechts bendet sich das
Feld für die Rechenoperationen. Sofern kein Benutzer angemeldet ist, sind
die Operationen nicht ausführbar und somit auch die Schaltächen für diese
Operationen gesperrt.
Benutzerwechsel sind über bereitgestellte Menüein-
träge ohne Neustart der Anwendung möglich. Wird ein Benutzer mit Hilfe
UserManagements durch Eingabe seines Benutzernamens und Passwortes
authentiziert, benachrichtigt es das ActivationManagement. Wie im Konzept beschrieben, konguriert das ActivationManagement bei einem Benutdes
zerwechsel alle registrierten Objekte gemäÿ den Rechten des Benutzers. Zu
den angemeldeten Objekten gehören auch die Schaltächen der Operationen.
Auf diese Weise werden die aktuellen Berechtigungen auf der Benutzungsoberäche dargestellt (Abbildung 8.1(b)).
Die Abbildung 8.1 zeigt, dass im Taschenrechner die Strategie Sperren von
Interaktionsobjekten (Abschnitt 3.1.4) realisiert ist.
Dies kann für andere
Taschenrechner
113
Projekte leicht durch den Austausch des verwendeten
IActivationAdapters
verändert werden. Die Sperrung der Interaktionsobjekte dient hier nur dem
besseren Überblick des Benutzers, damit er auf einen Blick erkennt, welche
Rechenarten er durchführen darf und welche der Taschenrechner noch unterstützt. Ob die hinter den freigegebenen Schaltächen liegenden Executables
wirklich ausgeführt werden dürfen (oder nicht), wird zur Sicherheit jedesmal
beim Aufrufen der Funktion entschieden.
Die im Taschenrechner verwendeten Rechte werden durch den Namen
einer Gruppe und eine Rolle repräsentiert. Ein Benutzer mit dem Bezeichner
User ist z.B. in den Gruppen Class1 und Class3 in der Rolle Teacher tätig.
In Class4 übernimmt er die Rolle des Administrator s. So entsteht für einen
Benutzer eine Rechtematrix, wie sie in Abbildung 8.2 dargestellt ist.
Die einzelnen Paare von Gruppen und Rollen werden auf
Rights abgebildet,
die zusammen mit dem Namen des Benutzers oder dem Bezeichner eines
Executables ein
RightSet
ergeben.
Abbildung 8.2: Rechtematrix für einen Benutzer im Taschenrechner
8.2 Realisierung
Bei der Implementierung der Security-Facade wurde darauf geachtet, dass
die Kern-Klassen (SecurityFacade,
RightsManagement, UserManagement,
ActivationManagement, ActivationAdapter, AbstractExecutable und
AbstractTypedExecutable) allgemein bleiben und so mit nur wenigen Änderungen auch in anderen Projekten verwendet werden können.
Aus die-
sem Grund sind die Plug-Ins des Taschenrechner-Projektes gemäÿ der Abbildung 8.3 strukturiert. Die Aufgaben der einzelnen Plug-Ins sind dabei:
•
Das Anwendungs-Plug-In (RCP) enthält sämtliche Klassen, die für den
Autorisierungsmechanismus zuständig sind.
Somit ist die Security-
Facade getrennt vom eigentlichen Taschenrechner.
Kai Meyer
Teil 3 - Praxis
114
Abbildung 8.3: Plug-In-Struktur des Taschenrechners
•
Das
Calculator-Plug-In baut direkt auf dem RCP-Plug-In auf und ent-
hält die Kernfunktionalität des Taschenrechners. Zu diesen Funktionen
gehört die Bereitstellung der View, der Logik für die Auswertung der
Operationen sowie des
rechenarten.
OperationExecutables
und der vier Grund-
Zudem bietet es einen Erweiterungspunkt an, der die
Anbindung weiterer mathematischer Operationen regelt.
•
Über den vom
Calculator-Plug-In
angebotenen Extension-Point in-
tegrieren Extending-Plug-Ins weitere konkrete Implementierungen des
OperationExecutables,
um Rechenoperationen zu dem Taschenrech-
ner beizutragen.
•
Admin-Plug-In regelt die Administration und Überwachung der
SecurityFacade. Dafür stellt es eine Message- und eine Rights-View
zur Verfügung. Die Message-View stellt die von der SecurityFacade,
vom RightsManagement und vom UserManagement verschickten Nachrichten dar. Die Rights-View erlaubt die Editierung der benötigten
Das
Rechte für die einzelnen Bezeichner und die Editierung der gewährten
Rechte der Benutzer. Dies allerdings nur, wenn der aktuelle Benutzer
dazu berechtigt ist.
Die Abbildung 8.4 zeigt die verwendeten Klassen im Überblick. Die hellgrau hinterlegten Klassen realisieren die Security-Facade und benden sich
somit im
RCP-Plug-In.
Dabei bilden die Klassen im schwarzen Rahmen die
Kern-Klassen der Security-Facade.
grund sind im
Calculator
Die Klassen mit dunkelgrauem Hinter-
oder einem Extending-Plug-In enthalten.
SecurityFacade arbeitet auf den Schnittstellen IRightsManagement
IUserManagement. Dies dient dem leichteren Austausch der konkreten
Die
und
Implementierung. Werden andere oder speziellere Implementierungen als die
im Taschenrechner angebotenen benötigt, brauchen nur die Klassen bzw. deren Objekte ausgetauscht werden.
Um die Arbeit des Administrators zu erleichtern, legen das hier verwendete
Taschenrechner
115
Abbildung 8.4: Klassenübersicht des Taschenerechners
Rights-
und
UserManagement
neue
RightSets
im persistenten Speicher an,
sobald die Rechte zu einem bisher unbekannten Bezeichner erfragt werden.
Dadurch muss der Administrator die verwendeten Bezeichner nicht genau
kennen und für jeden einzelnen ein
tor über die neu erstellten
RightSet
anlegen. Um den Administra-
RightSets zu informieren, verschicken das Rights-
UserManagement Nachrichten.
RightSets enthalten allerdings keine Rechte. Was leere
RightSets für die Benutzerautorisierung bedeuten, hängt von der verwendeten IEvaluationStrategy (Strategie-Muster, siehe [GHJV95, S.373 ]) ab.
In der IEvaluationStrategy wird aufgrund der zum Benutzer und zum
Bezeichner gehörenden RightSets die Entscheidung getroen, ob der Beund das
Die so entstandenen
nutzer die Erlaubnis für den angeforderten Bezeichner besitzt.
krete
IEvaluationStrategy-Exemplar
ten und dort verwendet. Mit Hilfe der
Das kon-
SecurityFacade gehalIEvaluationStrategy können, wie
wird in der
bei XACML (Abschnitt 4.4) oder JAAS (Abschnitt 4.3), nicht nur die Rechte,
sondern auch Daten des Benutzers oder des Systems in die Auswertung einbezogen werden. So lässt sich auch der in XACML spezizierte Policy Decision
Point realisieren.
Die im Taschenrechner verwendete
IEvaluationStrategy
erlaubt den Zu-
gri, wenn der Benutzer mindestens ein Recht besitzt, welches von dem
betreenden Bezeichner erwartet wird. Es ist aber ebenso vorstellbar, dass
der Benutzer alle benötigten Rechte haben muss. In beiden Fällen würden
leere
RightSets
dazu führen, dass keine Übereinstimmung gefunden wer-
den kann. Dadurch wird die Erlaubnisregel (siehe Abschnitt 1.8) umgesetzt.
Ist dies nicht erwünscht, muss eine Unterscheidung gemacht werden.
Ent-
Teil 3 - Praxis
116
hält das
RightSet
zu einer Id, z.B. eines Executables, keine Rechte, kann
dieser Bezeichner für jeden Benutzer freigegeben werden. Ist allerdings das
RightSet
zu einem Benutzer leer, muss entschieden werden, ob er damit al-
les ausführen darf oder ob er keine Rechte hat, wie es eigentlich angegeben ist.
Für die Persistierung der gewährten bzw. der geforderten Rechte sorgt
RightSetIO. Sowohl das Rights- als auch das UserManagement
verwenden das RightSetIO, wenn RightSets gelesen oder geschrieben wer-
die Klasse
den sollen. Der Einfachheit halber werden hier die Daten lediglich in unverschlüsselter Form in Textdateien auf der lokalen Festplatte gespeichert. Dies
oenbart Sicherheitslücken, die hier aber nicht weiter berücksichtigt werden
sollen, da der Fokus auf der Benutzerautorisierung liegt.
Da Editierungen der Textdateien durchgeführt werden können, ohne dass es
der Taschenrechner bemerkt, kann es passieren, dass die Benutzungsoberäche nicht mehr zu 100% den tatsächlichen Berechtigungen entspricht.
Die
Ausführung der Executables ist davon allerdings unbetroen, da die benötigten und gewährten Rechte bei Anfragen stets neu ausgelesen werden.
Die Executables
AbstractExecutable
und
AbstractTypedExecutable
können zum Schutz von Code-Blöcken eingesetzt werden. Beide implemen-
IExecutable, wobei das AbstractExecutable im Gegensatz zum AbstractTypedExecutable keinerlei Eingabe- oder Ausgabewerte hat und z.B. in der SecurityFacade bei der Persistierung der Rechte
tieren das Interface
verwendet wird.
public static void saveRights(nal RightSet[] rightSets ) {
if (_rightsManagement != null) {new AbstractExecutable() {
protected void doWork() {
}
_rightsManagement.saveRights(rightSets);
public String getExecutableId() {
return SAVE_RIGHTS_EXEC_ID;
}
}
}
}.execute();
Wie in dem Beispiel zu erkennen ist, entspricht die Erstellung eines Executa-
Runnable. Die Ausführung
SecurityFacade erfolgen.
bles dem aus Java bekannten
kann direkt oder über die
des Executables
Für die Fälle, wo Eingabe- und Ausgabewerte benötigt werden, wurde das
AbstractTypedExecutable erstellt, von der auch das OperationExecutable
erbt. Diese Executables werden auf die gleiche Weise angesprochen, nur müssen, sofern vorhanden, beim Aufruf von
execute()
auch die Eingabewerte
Taschenrechner
117
übergeben werden. Der Ausgabewert mit dem im
angegebenen Typ wird direkt von
execute()
AbstractTypedExecutable
geliefert.
AbstractTypedExecutable<Float, Float> additionExec =
new AbstractTypedExecutable<Float, Float>() {
protected Float doWork(Float... args) {
return args[0].oatValue() + args [1]. oatValue ();
}
public String getExecutableId() {
return "Calculator.ADDITION";
}
};
Float result = additionExec.execute(5.0F, 6.0F);
Die Schaltächen der
OperationExecutables
werden während des Auf-
baus der View für den eigentlichen Taschenrechner auf folgende Weise bei
dem
ActivationManagement
angemeldet:
ActivationManagement.getInstance()
.registerStandardActivationAdapter(Button.class,
ActivationManagement.ENABLE_CONTROL_ADAPTER);
for (OperationExecutable operationExec : operations) {
Button button = this.createButton(parentComposite, operationExec);
ActivationManagement.getInstance()
. register (operationExec.getExecutableId(), button);
}
Der vom
ActivationManagement
zur Verfügung gestellte ENABLE_CON-
TROL_ADAPTER wird für alle Objekte des Typs
Button
registriert und
übernimmt das Sperren der Schaltächen. Wird hier z.B. der ebenfalls bereitgestellte VISIBLE_CONTROL_ADAPTER verwendet, würde die Sichtbarkeit der Schaltächen angepasst. Da es sich in diesem Fall um normale
SWT-Buttons handelt, sind die Adapter recht einfach aufgebaut.
fen an dem Button lediglich
ActivationManagement
setEnabled
bzw.
setVisible
Sie ru-
auf. Damit das
korrekt arbeiten kann, ist es wichtig, dass nach der
Registrierung die im Adapter verwendete Methode nicht von anderern Stellen
aus aufgerufen wird.
Die Verwendung der Standard-ActivationAdapter ist nicht zwingend erforderlich. Es gibt ebenso die Möglichkeit, die Objekte zusammen mit einem
eigenen
IActivationAdapter
anzumelden, der dann statt dem Standard-
Adapter verwendet wird. So lässt sich die (De-)Aktivierung gezielt für einzelne Objekte steuern.
Menü- und Toolbareinträge werden in vielen Programmen nicht nur abhängig
von den Benutzerberechtigungen gesperrt, sondern auch, wenn deren Ausführung im momentanen Systemzustand keinen Sinn macht (z.B. Sortierung
einer Liste mit nur einem Eintrag). Daher wurde für die aus Eclipse stam-
Teil 3 - Praxis
118
mende
Action
eine neue Unterklasse (AbstractUserDependentAction) er-
stellt, die speziell für die Verwendung in der Security-Facade ausgelegt ist.
Mit ihrer Hilfe können Menü- und Toolbareinträge erstellt werden, die vom
Kontext abhängen können, aber nur dann verfügbar werden, wenn der Be-
AbstractUserDependentAction
wird im Taschenrechner z.B. innerhalb der Rights-View eingesetzt. Mit ihr
werden Aktionen realisiert, die dem selektierten RightSet ein Recht hinzufügen, entfernen oder alle RightSets speichern. Daher hängen die Actions
nicht nur von den Rechten ab, sondern auch davon, ob ein RightSet in der
nutzer die geforderten Rechte besitzt. Die
Liste selektiert ist (siehe Abbildung 8.5). Diese Aktionen fügen dem selek-
(a) ohne Selektion
(b) mit Selektion
Abbildung 8.5: Verhalten einer gewährten
RightSet
RightSets.
tierten
AbstractUserDependentAction
ein Recht hinzu, entfernen ein Recht oder speichern alle
8.3 Zusammenfassung
Kai Meyer
Über die Security-Facade ist eine exible und individuell kongurierbare Benutzerautorisierung mit Anbindung an die Benutzungsoberäche möglich.
Durch die Activation-Adapter und den Auswertungsstrategien können viele
verschiedene Rahmenbedingungen umgesetzt werden. Aus Sicherheitsgründen sollte allerdings verhindert werden, dass zur Laufzeit oder durch ein
Plug-In eines Drittanbieters die
IEvaluationStrategy
beliebig verändert
werden kann. Ansonsten kann die korrekte Strategie durch eine ersetzt werden, die jedem Benutzer vollen Zugri gewährt.
Ein Schwachpunkt bei der Realisierung des Taschenrechners sind die Bezeichner der Executables. Gerade bei groÿen Anwendungen mit vielen zu schützenden Code-Blöcken kann die Administration mangels Überblick schwierig
sein.
Dies ist allgemein ein Problem bei einer feinen Struktur der Rechte.
Um dem entgegen zu wirken, bestehen die Bezeichner im Taschenrechner
aus dem Plug-In-Namen und dem Namen der dazugehörigen Operation (z.B.
Calculator.ADDITION). So wird auch gewährleistet, dass ein Bezeichner aus
Taschenrechner
119
einem Plug-In nicht mit einem Bezeichner aus einem anderen Plug-In verwechselt wird.
In dieser Beispielanwendung taucht eine bisher unberücksichtigte Schwierigkeit bei der Rechtevergabe auf:
Es gibt (mathematische) Funktionen, die durch andere ausgedrückt werden
können. So gilt für alle x, y ∈ R: x + y = x − (−y) = x − ((−1) · y) und
x : y = x· y1 . Ein Benutzer braucht also nicht unbedingt das Recht Addition
oder Division zu besitzen, sofern er berechtigt ist, zu subtrahieren und negative Zahlen zu bilden bzw. zu multiplizieren und den Kehrwert einer Zahl
zu bilden. Je mehr Rechenoperationen zu dem Taschenrechner hinzu kommen, desto schwieriger wird die Verwaltung der Berechtigungen, um solche
Hintertüren zu vermeiden. Dies kann in groÿen Anwendungen ebenso ein
Problem werden.
Mit Hilfe der Security-Facade kann nicht verhindert werden, dass
in Menüs sichtbar sind.
Actions
Dies kann aber durch den Einsatz der in Ab-
schnitt 6.3 beschriebenen Capabilities behoben werden. Die Aktionen werden als
AbstractUserDependentAction realisiert, über die SecurityFacade
geschützt und mit Hilfe der Capabilities versteckt.
Deren Trigger Points
ActivationManagement zusammen mit dem Bezeichner der
AbstractUserDependentAction registriert werden. Auf diese Weise wären
die Actions nur sichtbar, wenn der Benutzer sie ausführen darf. Selbst wenn
können bei dem
durch andere Instanzen, z.B. durch die im Abschnitt 6.3 vorgestellte Preference Page, die Capabilities aktiviert werden, können die sichtbar gewordenen
Aktionen nicht ausgeführt werden, da sie weiterhin durch die Security-Facade
geschützt sind.
Mit der konkreten Implementierung der Security-Facade im Taschenrechner
wurden folgende Eigenschaften erzielt:
Kriterium
Eigenschaft
Autorisierungs-Ebene
Code-Blöcke
Filterregel
exibel (hier: Erlaubnisregel)
GUI-Anpassung
exibel (hier: sperren)
Rollen-/Rechtezuordnung
exibel, durch Anwender kongurierbar
Anpassung an veränderte Rechte
unmittelbar
Das komplette Taschenrechner-Projekt bendet sich auf der beiliegenden
CD. Dazu sei auch auf den Abschnitt C.6 im Anhang verwiesen.
Kapitel 9
Control System Studio
Kai Meyer
Ebenso wie der Taschenrechner (Kapitel 8) wird auch im Projekt
System Studio
(CSS) [CSS] die Security-Facade eingesetzt.
Control
Das CSS-
Projekt wird gemeinsam vom Deutsches Elektronen-Synchrotron
(DESY ), der C1-WPS und der Universität Hamburg entwickelt. Es schat
eine generische Infrastruktur für verschiedene Kontrollsysteme zur Überwachung und Steuerung der unterschiedlichen Anlagen und Geräte von Teilchenbeschleunigern. Das CSS setzt auf der Eclipse RCP auf und bietet eine
Plattform für verschiedene Programme an, zu denen auch das
play Studio (SDS) gehört.
Synoptic Dis-
Das SDS ist für die Erstellung und Verwaltung von synoptischen Displays
verantwortlich und wird im Rahmen des CoEUD-Projektes (Componentbased End User Development) [CoE] entwickelt.
Unter synoptischen Dis-
plays werden Anlagenschaubilder verstanden, die dazu dienen, Anlagen bzw.
Prozesse zu überwachen.
Die dargestellten Instrumente zeigen Messdaten
von bestimmten Geräten an und geben somit einen Überblick über den aktuellen Zustand der betrachteten Anlage bzw.
des betrachteten Prozesses.
Die Abbildung 9.1 zeigt so ein synoptisches Display. Über die verschiedenen
Schieberegler, Schaltächen und Eingabefelder können Einstellungen an den
realen Geräten vorgenommen werden.
Die Koordinatensysteme im oberen
Bereich und die diversen Textfelder zeigen die aktuellen Messdaten dieser
Geräte an.
Für eine genauere Beschreibung des CSS-Projektes lohnt sich ein Blick in
[HWWZ07].
Die Operateure der einzelnen Bereiche vom DESY überwachen mit Hilfe
der erstellten Displays die technischen Anlagen. Dabei ist es nicht zwingend
erforderlich, dass sie alle Bereiche sehen bzw. Eingabewerte verändern dürfen. Sollte dies doch erforderlich sein, können sich andere Benutzer mit mehr
120
Control System Studio
121
Abbildung 9.1: SDS-Display
Rechten kurzfristig im System anmelden, die Einstellungen vornehmen und
sich anschlieÿend wieder abmelden. Da das CSS rund um die Uhr in Betrieb
ist, kann kein Neustart für den Benutzerwechsel durchgeführt werden. Die
Geräte vom DESY werden bereits durch eine zusätzlich Hardware-Schicht
vor unzulässigen Einstellungen geschützt. Auf diese Wiese werden fehlerhafte
Eingaben verhindert. Daher liegt der Fokus bei der Verwendung eines Autorisierungsmechanismus im CSS/SDS auf der Anpassung der Benutzungsoberäche. So beziehen sich die Rechte der Benutzer auf einzelne Widgets in
den synoptischen Displays oder auf die Ausführung einzelner Aktionen. D.h.
den Benutzern sollen nur die Widgets in einem Display zur Verfügung stehen,
die sie auch benötigen. Da die für das DESY erstellten Programme auch bei
anderen Teilchenbeschleunigern eingesetzt werden sollen, ist das CSS und
ebenso das SDS gegenüber Anpassungen und Erweiterungen oen. Auf diese
Weise können Entwickler beim DESY oder anderen Teilchenbeschleunigern
eigene SDS-Widgets oder (Teil-)Programme in das CSS/SDS integrieren. Somit muss der Autorisierungsmechanismus sehr exibel und für die Entwickler
einfach zu benutzen sein.
Alle diese Anforderungen werden von der Security-Facade erfüllt.
Während der Erstellung dieser Arbeit befand sich das CSS/SDS in der
Entwicklung. Somit waren einige Fragen, die die Sicherheit betreen, noch
nicht vollständig geklärt. Weil die im CSS implementierte Security-Facade
auf den für den Taschenrechner (Kapitel 8) erstellten Klassen aufbaut, wird
hier die Security-Facade nur in Auszügen behandelt.
Teil 3 - Praxis
122
9.1 Konzept
Kai Meyer
Im CSS wird für die Authentizierung JAAS (Abschnitt 4.3) verwendet. Die
Autorisierung erfolgt allerdings ausschlieÿlich über die Security-Facade.
Die Elemente in einem synoptischen Display sind keine SWT-Widgets,
sondern eigens erstellte Interaktionsobjekte, die für diese Anwendung ausgerichtet sind. Diese Interaktionsobjekte setzen auf dem Graphical Editing
Framework (GEF) auf. Somit bestehen die SDS-Widgets gemäÿ dem
Model-
View-Controller-Ansatz (siehe [SM02] oder [LR06] ab Kapitel 8) aus drei
Komponenten:
•
Das
Model
hält die Attribute des Widgets, speichert die Werte und
überwacht Veränderungen dieser Werte.
•
•
View ist für die grasche Repräsentation verantwortlich
Der Controller übernimmt die Vermittlung zwischen dem Model und
Die
der View
Allerdings wurde der allgemeine MVC-Ansatz für den Einsatz im SDS angepasst.
Wie in Abbildung 9.2(b) zu erkennen ist, haben das Model und
die grasche Repräsentation im Gegensatz zum reinen MVC-Ansatz keinerlei Bezug zueinander. Dafür beobachtet der Controller ebenfalls das Model
und leitet vom Model versendete Ereignisse an die View weiter. Diese Modikation des MVC-Ansatzes schat klarere Aufgabenbereiche der einzelnen
Komponenten.
(a) Standard-MVC [SM02]
(b) SDS-MVC
Abbildung 9.2: Model-View-Controller
Die Displays benden sich entweder im Edit - oder im Run -Modus. Im
Edit -Modus werden Displays erstellt und konguriert. Dazu können Widgets
Control System Studio
123
in das Display integriert bzw. aus ihm entfernt werden oder sämtliche Attribute der Widgets konguriert werden. Zu diesen Attributen gehören z.B.
die Position, Breite, Höhe aber auch die Permission ID. Diese Id wird für
die Registrierung beim Activation-Management verwendet.
Wird ein Display in den Run -Modus versetzt, werden die Widgets bei dem
Activation-Management mit ihrer Permission ID angemeldet und gemäÿ
ihrer Konguration, mit den realen Geräten verbunden. So können die Daten der Geräte angezeigt bzw. Einstellungen an ihnen vorgenommen werden,
sofern die Operateure die entsprechenden Rechte besitzen.
Die Rechte innerhalb der CSS-Anwendung werden, wie beim Taschenrechner
im Abschnitt 8.1 beschrieben, durch eine Rechtematrix realisiert.
Die ge-
währten Rechte der Benutzer werden in einem LDAP-Verzeichnis (siehe Abschnitt 4.2) gespeichert. Für die geforderten Rechte wird derzeit noch eine
ungeschützte Textdatei verwendet.
Dies soll jedoch ebenso in eine LDAP-
Struktur umgesetzt werden.
9.2 Realisierung
Die Funktion des User-Managements wurde im CSS stark abgewandelt. Es
gibt nicht ein Exemplar, das den aktuellen Benutzer hält, sondern meh-
LoginContexte, die zu einem Benutzer noch weitere Informationen und
Funktionen bereitstellen. Dieser LoginContext ist nicht der in JAAS verwendete, sondern wird nur innerhalb der SecurityFacade benutzt und verwaltet.
Unter anderem können so Executables unter einem anderen LoginContext
rere
ausgeführt werden. Auf diese Weise wird die geforderte kurzfristige Anmeldung eines Benutzers realisiert.
Das Rights-Management wird im CSS durch den
RightsManagementService
umgesetzt. Aufgrund der Umstellungen des User-Managements liest im CSS
RightsManagementService die Rechte eines Benutzers aus. Da der
RightsManagementService sowohl die benötigten als auch die gewährten
das
Rechte kennt, trit der Service direkt die Entscheidung, ob der Benutzer
den Zugri auf die hinter einem Bezeichner stehenden Objekte erhält. Eine
IEvaluationStrategy wurde bisher nicht umgesetzt. Die aktuelle Implementierung des RightsManagementServices setzt die Verbotsregel (siehe
Abschnitt 1.8) um, da sie bei einem leeren RightSet jedem Benutzer den
Zugri erlaubt, auch wenn er selbst keine Rechte besitzt.
Das Activation-Management wird im CSS durch den
realisiert. Bei der Registrierung von Objekten bei dem
ActivationService
ActivationService
werden die Adapter nicht übergeben, sondern über den aus Eclipse stammen-
Kai Meyer
Teil 3 - Praxis
124
AdapterManager ermittelt. Falls das übergebene Objekt das Interface
IAdaptable implementiert, kann auch darüber der IActivationAdapter bezogen werden. Der Quellcode 9.1 zeigt, wie der ActivationService den
IActivationAdapter für das registrierte Objekt ermittelt.
den
ActivationService
private IActivationAdapter getActivationAdapter(nal Object object) {
IActivationAdapter adapter = null;
if (object instanceof IAdaptable) {
Quellcode 9.1: Auszug aus dem
}
adapter = (IActivationAdapter)
((IAdaptable)object).getAdapter(IActivationAdapter.class);
if (adapter==null) {
}
}
adapter = (IActivationAdapter) Platform.getAdapterManager()
.getAdapter(object, IActivationAdapter.class);
Für die SDS-Widgets wird ein
ActivationAdapter bei dem AdapterManager
über einen Extension-Point registriert. Dieser verändert am Model des SDSWidgets den Enabled -Wert, was vom betreenden Controller an die grasche Repräsentation des Widgets gemeldet wird.
Daraufhin wird das Er-
scheinungsbild des Widgets angepasst. Was genau passiert, ist von der Implementierung der View und des Controllers abhängig. Theoretisch können
sämtliche Attribute des Widgets manipuliert werden. Praktisch wird es aber
meist beim Sperren oder bei der Veränderungen der Sichtbarkeit bleiben.
Die Executables und deren Verwendung entspricht der Beschreibung im Taschenrechner (Kapitel 8).
Ebenso werden bisher die Rechte des Benutzers
und die geforderten Rechte zu dem Bezeichner des Executables bei jeder Anfrage neu ausgelesen. Dadurch wird stets auf Grundlage der aktuellen Daten
gearbeitet, kann aber zu erheblichem Netzwerkverkehr führen. Bisher wurde
beim DESY noch nicht ermittelt, ob der entstehende Netzwerkverkehr vertretbar ist, oder ob die Rechte-Matrizen in einem lokalen Speicher gehalten
werden sollen.
9.3 Oene Probleme und Zusammenfassung
Kai Meyer
Im CSS gibt es noch groÿe Unstimmigkeiten über den Aufbau und die Handhabung der Permission ID s.
Ein Display kann für mehrere verschiedene
aber identisch aufgebaute Bereiche der Anlagen verwendet werden.
Über
die Angabe einer Prozessvariablen können die auszulesenden Datenströme
bestimmt werden.
Nun kann es vorkommen, dass Operateure aus unter-
schiedlichen Bereichen verschiedene Instanzen des gleichen Displays verwen-
Control System Studio
125
den, um einen Teil ihrer Anlagen zu überwachen.
Das Display wird über
spezische Prozessvariablen auf die Bereiche eingestellt. Ob ein bestimmtes
Widget aus dem Display einem Operateur zur Verfügung steht, hängt jetzt
nicht mehr nur von der Permission ID und den dazu hinterlegten Rechten,
sondern ebenso von der verwendeten Prozessvariablen ab. Zudem wird im
laufenden System durch die hohe Anzahl an Displays, die teilweise hunderte
Widgets enthalten können, die Administration sehr schwer.
Die Security-Facade bietet eine einfach zu verwendende Möglichkeit, die Benutzungsoberäche entsprechend der Berechtigungen des Benutzers anzupassen.
Dies ist gerade für die Entwickler beim DESY interessant.
Executables ähnlich wie die
Runnables
Da die
verwendet werden, bedarf es bei den
Entwicklern nur einer kleinen Umstellung. Entsprechendes gilt auch für die
AbstractUserDependentAction,
die anstelle der
Actions
Verwendung n-
det.
Zurzeit werden im CSS/SDS allerdings nur die Interaktionsobjekte vor unberechtigtem Zugri geschützt. Die eigentlichen Aktion (sowohl das Auslesen
als auch Verändern von Werten der Geräte) werden nicht geschützt.
Dies
verdeutlicht, dass die eigentlichen Aktionen unbedingt serverseitig geschützt
werden müssen, was beim DESY zumindest zum Teil durch die zusätzliche
Hardware-Schicht gegeben ist.
Mit der bisherigen Implementierung wurden folgende Merkmale erzielt:
Kriterium
Eigenschaft
Autorisierungs-Ebene
Code-Blöcke, Widgets
Filterregel
exibel (hier: Verbotsregel)
GUI-Anpassung
exibel
Rollen-/Rechtezuordnung
exibel, durch Anwender kongurierbar
Anpassung an veränderte Rechte
unmittelbar
Aufgrund von Lizenzbedingungen und der Komplexität des Control System Studios wurde davon abgesehen, eine CSS-Version auf der beiliegenden
CD anzubieten.
[BRZ07, S.131 ], [CW07]
Kapitel 10
Zusammenfassung und Ausblick
Kai Meyer und
Im Rahmen dieser Arbeit wurde untersucht, ob und wie die Brücke zwischen
Torsten Witte
Zugriskontrolle und Benutzungsoberäche unter Berücksichtigung der benutzergerechten Softwaregestaltung geschlagen werden kann. Dabei sind die
Autoren zunächst in der Diskussion um die korrekte Verwendung von Interaktionsobjekten bei Benutzerautorisierung (Abschnitt 3.1) zu dem Ergebnis gekommen, dass das Verstecken der betreenden Interaktionsobjekte die
Gebrauchstauglichkeit der Software am stärksten fördert. Allerdings fehlen
zu diesem Thema allgemeine Standards, die auch eingehalten werden. Mit
diesen Standards wäre eine weitere Grundlage für anwendungsübergreifend
konsistente Benutzungsoberächen geschaen.
Die in Kapitel 4 untersuchten Autorisierungs-Konzepte legen ihren Fokus
auf Sicherheit, nehmen aber kaum Bezug zu der Benutzungsoberäche des
umfassenden Softwaresystems. Im Gegensatz dazu wird im Eclipse-Umfeld
die Wichtigkeit der Anbindung der Benutzungsoberäche an die Autorisierung berücksichtigt. Die geführten Diskussionen und entstandenen Ansätze
zeigen, dass diese Anbindung möglich ist.
Dabei wird ausschlieÿlich das
Verstecken von Interaktionsobjekten für nicht-gewährten Funktionen angewendet.
Allerdings besitzen die hier vorgestellten Realisierungen noch ei-
nige Schwachpunkte bzgl. der Sicherheit und der Rechtevergabe im realen
Einsatz. Der von den Autoren erstellte Dienstplaner, der diese Ansätze aufgreift und weiterentwickelt, demonstriert, dass mit dem zugrunde liegenden
Konzept der Plug-In-(De-)Aktivierung ein exibler, sicherer und einfach zu
handhabender Weg für die Anbindung existiert.
Da die Plug-In-(De-)Aktivierung allerdings für manche Einsatzkontexte
eine zu grobe Granularität der zu vergebenden Berechtigungen mit sich bringt
oder das alleinige Verstecken von Interaktionsobjekten nicht ausreicht, entwickelten die Autoren die Security-Facade. Damit bewegen sich die einzelnen Berechtigungen nicht auf Plug-In-Ebene, sondern auf Ebene von Code-
126
Zusammenfassung und Ausblick
Blöcken.
127
Zudem können gezielt einzelne Interaktionsobjekte entsprechend
den Berechtigungen des Benutzers angepasst werden.
Dabei kommen das
Verstecken, das Sperren und andere Vorgehensweisen oder Kombinationen in
Betracht. Die Security-Facade wurde anhand eines Prototypen erprobt und
wird in dem Projekt Control System Studio erfolgreich eingesetzt.
Die Anforderungen an das zu realisierende System wirken sich natürlich
auf die gewählte Methode aus.
Generell ist zu sagen, dass Sicherheit auf
allen Systemebenen gewährleistet sein muss. Somit sollte die Rechteverwaltung von Beginn der Entwicklung an mit in die Architektur der Anwendung
einbezogen werden. Die Authentizierungs- und Autorisierungsdaten sollten
immer in verschlüsselter, signierter und durch Prüfsummen gesicherten Form
vorliegen (sowohl auf dem Server als auch auf dem Client, falls nötig).
Die Oenheit der Eclipse RCP für Erweiterungen bildet in Bezug auf Benutzerautorisierung eine Sicherheitslücke, die beachtet werden muss. Wenn
der eingesetzte Autorisierungsmechanismus über das Erweiterungsregister
kongurierbar ist und keine weiteren Sicherheitsmechanismen (z.B. signierte
Plug-Ins) verwendet werden, bendet sich voraussichtlich eine Hintertür in
dem System.
Daher muss das Einbinden von (Fremd-)Plug-Ins nach dem
Anwendungsstart, bzw.
nachdem die Authentizierung und Autorisierung
vollzogen wurde, überwacht und ggf.
verhindert werden.
An dieser Stelle
besteht noch Entwicklungsbedarf, auch im Eclipse RCP-Umfeld.
128
Teil IV
Anhang
129
Anhang A
Verweise
A.1 Eclipse-Newsgroups
Torsten Witte
Einstiegspunkte in die Diskussionen zu den Themen Sicherheit, Rollen-Konzept,
benutzer-/rollenabhängige Benutzungsoberäche in der Eclipse Rich-ClientPlatform:
•
security concerns (11.06.2003)
http://dev.eclipse.org/newslists/news.eclipse.technology.
equinox/msg00438.html
•
Hide/show wizards based on developer roles? (09.09.2003)
http://dev.eclipse.org/newslists/news.eclipse.platform/
msg06453.html
•
Security (23.12.2003)
http://dev.eclipse.org/newslists/news.eclipse.technology.
equinox/msg00568.html
•
Role Concept? (16.01.2004)
http://dev.eclipse.org/newslists/news.eclipse.platform/
msg12572.html
•
Hiding functionality using platform-dened actions? (09.04.2004)
http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/
msg01778.html
•
RCP and user roles (or how to make non-ui plugin to provide a
selection?) (30.06.2004)
http://dev.eclipse.org/newslists/news.eclipse.platform/
msg24036.html
130
Eclipse-Newsgroups
•
131
Hook for action set for applying user level access control (12.08.2004)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=71857
•
How Implement a role based system (05.10.2004)
http://dev.eclipse.org/newslists/news.eclipse.platform/
msg30366.html
•
Action enablement based on security policy (21.12.2004)
http://dev.eclipse.org/newslists/news.eclipse.platform.
rcp/msg02180.html
•
User/role
management
(enabling/disabling
menu/sub-menu/items
based on events) (29.01.2005)
http://dev.eclipse.org/newslists/news.eclipse.platform.
rcp/msg02801.html
•
Role Based Updates (19.02.2005)
http://dev.eclipse.org/mhonarc/lists/platform-update-dev/
msg00585.html
•
Changing perspective views based on user authorization (01.06.2005)
http://dev.eclipse.org/newslists/news.eclipse.platform.
rcp/msg05071.html
•
RCP App and role based, dynamic policy (03.06.2005)
http://dev.eclipse.org/newslists/news.eclipse.technology.
equinox/msg01097.html
•
Eclipse-JAAS: RCP security framework kind-of available (01.09.2005)
http://dev.eclipse.org/newslists/news.eclipse.technology.
equinox/msg01132.html
•
Perspective ltering via acitvities (show all problem) (29.11.2005)
http://dev.eclipse.org/newslists/news.eclipse.platform/
msg48240.html
•
how to add management on rcp (13.01.2006)
http://dev.eclipse.org/newslists/news.eclipse.platform.
rcp/msg09927.html
•
Questions on rbac (role based access control) in an RCP (26.07.2006)
http://dev.eclipse.org/newslists/news.eclipse.technology.
equinox/msg01995.html
•
Limiting Access to Plugins (11.01.2007)
http://dev.eclipse.org/newslists/news.eclipse.technology.
equinox/msg02590.html
Anhang B
Eingesetzte Werkzeuge
B.1 Java
Torsten Witte
Die Programmiersprache Java wurde 1995 von Sun Microsystems (http:
//java.sun.com/)
freigegeben.
Die objektorientierte Sprache wurde ur-
sprünglich für den Einsatz im World Wide Web optimiert.
Daher lautet
die Java-Philosophie Write Once, Run Anywhere. Java-Programme werden
in Bytecode übersetzt und auf einer virtuellen Maschine, der JVM (Java Virtual Machine), ausgeführt, indem der Bytecode interpretiert wird. Deswegen
sind Java-Programme plattformunabhängig. Das zur Ausführung von JavaProgrammen benötigte Java Runtime Environment ist heute für nahezu alle
Plattformen kostenlos erhältlich.
Zur Entwicklung von Java-Programmen
bietet Sun u.a. das J2SDK und das J2EE an.
B.2 Eclipse
Torsten Witte
Während in Kapitel 2 Eclipse als Grundlage für RCP-Anwendungen vorgestellt wurde, soll hier Eclipse als Entwicklungswerkzeug genauer betrachtet
werden.
Die Eclipse-IDE bietet viele nützliche Funktionen zur Unterstützung des Programmierers von Java-Anwendungen. Dazu zählen z.B. Vervollständigungsund Refactoring-Funktionen, mit denen Code schnell und fehlerfrei von starken Gerüchen befreit werden kann (siehe [Fow00]).
Ein komfortabler De-
bugger ist ebenfalls vorhanden, der sogar Codeänderungen im laufenden Programm zulässt.
Da die Eclipse-IDE selbst auf der Eclipse RCP aufsetzt, ist die Entwicklungsumgebung über Plug-Ins erweiterbar.
Die Entwicklung von Plug-Ins
wird u.a. durch das Plug-In Development Environment (PDE) unterstützt.
132
Startkongurationen für RCP-Anwendungen
133
Auf diese Weise kann jeder seine eigenen Funktionalitäten für die Eclipse-IDE
entwickeln und nahtlos einbinden. So sind in der Community auch Plug-Ins
für die Entwicklung in anderen Programmiersprachen entstanden.
Eclipse
ist also keineswegs an Java gebunden. Die ozielle Plug-In-Website Eclipse
Plugin Central (www.eclipseplugincentral.com) bietet mittlerweile fast
1000 verschiedene Eclipse-Plug-Ins an.
B.2.1 Startkongurationen für RCP-Anwendungen
Der Screenshot in Abbildung B.1 zeigt, wie in der Eclipse-IDE ausgewählt
werden kann, mit welchen Plug-Ins eine (zu testende) RCP-Anwendung aus-
Calculator
Zusätzlich wird das Admin-Plug-
geführt werden soll. In diesem Beispiel wird der Taschenrechner
auf dem Anwendungs-Plug-In
RCP gestartet.
In eingebunden. Im Eclipse-Workspace bendet sich noch das ErweiterungsPlug-In
CalculatorExtension,
rechner hinzufügt.
das weitere Rechenarten zu dem Taschen-
Dieses ist allerdings nicht ausgewählt, so dass die hier
ausgeführte Anwendung nur die Grundrechenarten beinhaltet.
Alle weiteren benötigten Plug-Ins lassen sich leicht über einen Klick auf
Required Plug-ins
hinzufügen.
Add
Dazu gehören z.B. einige Kern-Plug-Ins
der Eclipse RCP, die sich auf der Zielplattform benden. Ebenso kann über
Validate Plug-ins
geprüft werden, ob alle Plug-In-Abhängigkeiten erfüllt
sind.
B.2.2 OSGi-Konsole
Ein nützliches Werkzeug zur Überwachung und Steuerung einer Eclipse RichClient-Platform zur Laufzeit ist die OSGi-Konsole.
kann mit dem Kommandozeilenparameter
aufhin erscheint in der Konsole das
Jede RCP-Anwendung
-console
osgi>-Prompt,
gestartet werden. Dar-
über das Befehle an die
OSGi-Plattform gegeben werden können. Am dienlichsten ist hier das Kommando
ss
für Short Status. Darüber werden alle in der RCP vorhandenen
Plug-Ins inklusive ihrer zugewiesenen Bundle-Id und ihrem aktuellen Zustand aufgelistet. Abbildung B.2 zeigt dies am Beispiel des Dienstplaners.
Zu erkennen sind auch die Bundle-Ids der Fragmente, die zu einem Plug-In
gehören (z.B. Fragments = 25) und umgekehrt (z.B. Master = 26). Weitere,
im Kontext dieser Arbeit wichtige Kommandos sind
start, stop
und
update.
install, uninstall,
Diese Kommandos erwarten als Parameter eine
URL oder die Id des in der Plattform eingebundenen Bundles. Alle übrigen
zulässigen Kommandos werden über die Eingabe von
help
angezeigt.
[ML06, S.455]
Anhang
134
Abbildung B.1: Eclipse Startkonguration von RCP-Anwendungen
Abbildung B.2: OSGi-Konsole
Java Policy-Tool
135
B.3 Java Policy-Tool
Mit dem Java Policy-Tool lassen sich Richtlinien-Dateien für den Java Authentication and Authorization Service erstellen und bearbeiten. Das Tool
ist standardmäÿig in der Installation des Java Development Kits und des
Java Runtime Environments im folgenden Verzeichnis enthalten:
<JDK- oder JRE-Verzeichnis>\bin\policytool.exe
Torsten Witte
Anhang C
CD-Inhalt
C.1 Java
Torsten Witte
Das Java -Verzeichnis enthält das JRE und das J2SDK in Version 6 (Update 1) für Windows. Die jeweils aktuellste Version, auch für andere Plattformen, ist unter
http://www.java.com/de/
bzw.
http://java.sun.com/
erhältlich.
C.2 Eclipse
Torsten Witte
Im Eclipse -Verzeichnis der CD ist Eclipse in der Version 3.2.2 zu nden.
Die jeweils aktuellste Version steht unter
www.eclipse.org
zum Download
bereit.
C.3 Ausführbare Beispiele zu JAAS
Torsten Witte
Die CD enthält ein Verzeichnis JAAS-Examples. Dabei handelt es sich um ein
Eclipse-Projekt, das in den Eclipse-Workspace importiert werden kann. Das
Projekt umfasst zwei Beispiele. Eines, das lediglich einen Benutzer authentiziert, und eines, das nach einer erfolgreichen Authentizierung benutzerabhängige Aktionen durchführt. Um die beiden Beispiele auszuführen, braucht
lediglich die MainClass aus dem jew. Paket (authenticationExample oder
authorizationExample) als Java-Application gestartet werden. Anschlieÿend werden in der Konsole die Log-in-Daten abgefragt.
Zulässige Benut-
zernamen sind bob, joe, foo und bar, jeweils mit gleichnamigen Passwort.
136
Ausführbares Beispiel zu Eclipse-JAAS
137
C.4 Ausführbares Beispiel zu Eclipse-JAAS
Im Verzeichnis EclipseJAAS-Example benden sich die beiden Kern-Plug-Ins
net.sourceforge.eclipsejaas und net.sourceforge.eclipsejaas.util
des Eclipse-JAAS-Frameworks von Neil Bartlett [Eclc].
Zusätzlich ist eine
Beispiel-Anwendung vorhanden, die aus den Plug-Ins
• net.sourceforge.eclipsejaas.sample,
• net.sourceforge.eclipsejaas.samplelogin,
• net.sourceforge.eclipsejaas.sampleauth1
und
• net.sourceforge.eclipsejaas.sampleauth2
sample-Plug-In ist das RCP-Plug-In und deniert das fertige
Produkt, während das samplelogin-Plug-In das JAAS LoginModule hinzufügt und die Benutzerautorisierung übernimmt. Die beiden sampleauthXPlug-Ins deklarieren lediglich jeweils eine View, Test View 1 und Test View
2. Zu beachten ist dabei, dass Test View 2 von Test View 1 erbt, also
auch das sampleauth2-Plug-In von sampleauth1 abhängig ist. Beide Plugbesteht. Das
Ins sind nur in einer bestimmten Rolle verfügbar.
Um das Beispiel ausführen zu können, müssen alle sechs Plug-In-Projekte
in den Eclipse-Workspace importiert werden. Anschlieÿend müssen die bei-
net.sourceforge.eclipsejaas.sampleauthX-Plug-Ins über Export...
→ Deployable plug-ins and fragments in ein separates Verzeichnis, z.B.
C:\EclipseJAAS-Test, exportiert werden. Nach dem Export liegt in dem
den
angegebenen Verzeichnis ein weiteres Unterverzeichnis plugins, welches wiederum die beiden Dateien
• net.sourceforge.eclipsejaas.sampleauth1_1.0.0.jar
und
• net.sourceforge.eclipsejaas.sampleauth2_1.0.0.jar
enthält.
Nun muss in Eclipse noch eine Startkonguration (siehe Anhang B.2.1) für
net.sourceforge.eclipsejaas.sample angelegt werden.
Wichtig ist dabei, dass auf dem Reiter Main unter Program to run die Option Run a product mit dem Wert net.sourceforge.eclipsejaas.sample.sampleProduct ausgewählt ist.
Bei den VM Arguments auf dem Reiter Arguments muss der Pfad zu den
das Produkt aus
beiden exportierten Plug-Ins (als URL und mit abschlieÿendem Slash) angegeben sein:
-Declipsejaas.util.pluginLocation=le:/C:/EclipseJAAS-Test/plugins/
In der Startliste auf dem Reiter
Plug-ins
dürfen nur die Plug-Ins
Torsten Witte
Anhang
138
• net.sourceforge.eclipsejaas,
• net.sourceforge.eclipsejaas.util,
• net.sourceforge.eclipsejaas.sample
und
• net.sourceforge.eclipsejaas.samplelogin
sowie alle dafür benötigten Plug-Ins vorhanden sein. Die beiden
forge.eclipsejaas.sampleauthX-Plug-Ins
net.source-
werden ggf. zur Laufzeit nach-
geladen.
Zuletzt muss noch auf dem Configuration-Reiter die Option clear the
configuration area before launching angewählt sein. Ansonsten behält
Eclipse einige Registereinträge im Zwischenspeicher, die nur für bestimmte
Benutzer sichtbar sein sollen.
Beim Starten der Anwendung erscheint ein einfacher Log-in-Dialog, der
lediglich einen Benutzernamen abfragt. Hier kann grundsätzlich alles eingegeben werden.
Namen, die mit Evil beginnen, erhalten keinen Zugang
in das System.
Namen, die als Teilwort Bob enthalten, verfügen über
beide
sampleauthX-Plug-Ins
und somit auch über beide Views.
Alle wei-
teren Namen haben Zugang in die Anwendung, verfügen aber nicht über die
sampleauthX-Plug-Ins.
Darüber hinaus bendet sich in dem selben CD-Verzeichnis das vom Autor dieses Abschnittes entwickelte
eclipsejaas.evil.authorization-Plug-
In. Wird die Beispielanwendung zusätzlich mit diesem Plug-In ausgeführt,
erhält jeder authentizierte Benutzer Zugri auf die beiden
sampleauthX-
Plug-Ins.
Eine weitere Variante, die Benutzerautorisierung zu umgehen, bietet die
OSGi-Konsole (siehe Anhang B.2.2).
Kommandozeilenparameter
Dazu muss die Anwendung mit dem
-console ausgeführt werden.
Nach dem Einlog-
gen mit einem beliebigen Namen, braucht in der Konsole nur das Kommando
install file:/C:/EclipseJAAS-Test/plugins/net.sourceforge.eclipsejaas.sampleauth1_1.0.0.jar angegeben werden. Daraufhin erscheint
eine Bundle-Id, unter der das Plug-In in der OSGi-Plattform erreichbar ist.
start <Bundle-Id> mit dieser Bundle-Id ist das PlugAnwendung aktiv und die Test View 1 kann geönet wer-
Nach der Eingabe von
In innerhalb der
den. Dieser Ablauf ist für jedes weitere Plug-In analog.
Ausführbares Beispiel zu Capabilities
139
C.5 Ausführbares Beispiel zu Capabilities
Das Verzeichnis Kim Horne Activity Demo auf der CD enthält das Eclip-
Torsten Witte
seCon2005.KCH.AuthDemo -Projekt, das Kimberly Horne auf der Eclipse-
Con 2005 zur Demonstration von Benutzerautorisierung über Capabilities
vorgestellt hat.
Dieses Projekt braucht lediglich in den Eclipse-Workspace
importiert und kann anschlieÿend als RCP-Anwendung ausgeführt werden.
Das Einloggen als Manager ist mit dem Benutzernamen khorne und gleich
lautendem Passwort möglich. Für die Rolle als Employee kann der Benutzername und das Passwort you gewählt werden. Weitere Log-in-Daten benden
sich in der
authtable-Datei
des Projektes.
Zusätzlich bendet sich in dem selben Verzeichnis das Projekt EvilPlugin.
Wird die Demo-Anwendung von Kimberly Horne mit diesem Plug-In gestartet, bendet sich in der Menüleiste ein weiteres Menü, mit dem es möglich
ist, die Authentizierung und Autorisierung zu umgehen.
C.6 Taschenrechner
Auf der CD bendet sich im Verzeichnis Taschenrechner der in Kapitel 8
beschriebene Taschenrechner.
können, müssen die Plug-Ins
Admin
Um die vollständige Anwendung starten zu
RCP, Calculator, CalculatorExtension
in den Eclipse-Workspace importiert werden.
und
In der Startkongu-
RCP-Plug-In und Calculator
CalculatorExtension
und Admin sind optional. CalculatorExtension fügt dem Taschenrechner
weitere Rechenoperationen hinzu, während das Admin-Plug-In die Überwa-
ration des Taschenrechners muss mindestens
ausgewählt sein (siehe Anhang B.2.1). Die Plug-Ins
chung der Security-Facade und die Editierung von Rechten ermöglicht.
Die Dateien
user.txt, roles.txt
und
rights.txt
enthalten die Daten für
die Authentizierung und Autorisierung. Sie benden sich im
RCP-Plug-In
unter les.
Direkt nach dem Start der Anwendung ist kein Benutzer angemeldet und
daher auch keine Operation verfügbar. Für die An- bzw. Abmeldung eines
Benutzers existieren im Menü
in der
user.txt
File
die Einträge
Log-In
und
Log-Out.
Wie
festgehalten, können sich die Benutzer Tick, Trick, Track,
Daisy und Donald anmelden. Das Passwort entspricht dabei dem Namen des
jeweiligen Benutzers. Donald und Daisy gehören der Teacher -Rolle an, wobei
Daisy zusätzlich als Admin tätig ist. Tick, Trick und Track sind in der Pupil Rolle.
Je nach angemeldetem Benutzer werden verschiedene Operationen
verfügbar.
Kai Meyer
140
Abbildungsverzeichnis
2.1
Erweiterbare Anwendung vs. Plattform [ME05, S.4] . . . . . .
24
2.2
Eclipse-Plattform [Dau05a, S.347] . . . . . . . . . . . . . . . .
25
2.3
Lebenszyklus von Bundles [ML06, S.460]
. . . . . . . . . . . .
28
2.4
Plug-In-Abhängigkeiten
. . . . . . . . . . . . . . . . . . . . .
30
2.5
Erweiterungen [ML06, S.21]
3.1
Interaktionsobjekte (Windows XP)
3.2
Interaktionsobjekte (Mac OSX)
. . . . . . . . . . . . . . . . . . .
39
. . . . . . . . . . . . . . .
51
. . . . . . . . . . . . . . . . .
51
4.1
Core RBAC Elemente [Ame03, S.8] . . . . . . . . . . . . . . .
62
4.2
Hierarchical RBAC Elemente [Ame03, S.10]
. . . . . . . . . .
62
4.3
SSD Elemente [Ame03, S.13] . . . . . . . . . . . . . . . . . . .
63
4.4
DSD Elemente [Ame03, S.14]
. . . . . . . . . . . . . . . . . .
64
4.5
Authentizierung mit JAAS - Sequenzdiagramm . . . . . . . .
68
4.6
Autorisierung mit JAAS - Sequenzdiagramm . . . . . . . . . .
71
4.7
XACML-Datenuss [SNL06, S.419]
. . . . . . . . . . . . . . .
75
5.1
Komponenten der Security-Facade . . . . . . . . . . . . . . . .
80
5.2
Security-Facade-Datenuss . . . . . . . . . . . . . . . . . . . .
82
5.3
Security-Facade-Datenuss mit Activation-Management . . . .
83
7.1
Dienstplaner: Plug-In-Struktur
7.2
Dienstplaner: Menüleiste . . . . . . . . . . . . . . . . . . . . . 104
7.3
Dienstplaner: Kontextmenü
7.4
Rechtevergabe im Dienstplaner
8.1
Benutzungsoberäche des Taschenrechners
8.2
Rechtematrix für einen Benutzer im Taschenrechner . . . . . . 113
8.3
Plug-In-Struktur des Taschenrechners . . . . . . . . . . . . . . 114
8.4
Klassenübersicht des Taschenerechners
8.5
Verhalten einer gewährten
9.1
SDS-Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
. . . . . . . . . . . . . . . . . 103
. . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . 106
. . . . . . . . . . . 112
. . . . . . . . . . . . . 115
AbstractUserDependentAction
141
. . 118
Abbildungsverzeichnis
142
9.2
Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . 122
B.1
Eclipse Startkonguration von RCP-Anwendungen . . . . . . . 134
B.2
OSGi-Konsole . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Literaturverzeichnis
[Ame03] American National Standards Institute, Inc.:
can
National
Based
Standard
Access
for
Control.
rbac-std-ncits.pdf.
Information
Technology
Ameri
Role
http://csrc.nist.gov/rbac/
Version: April 2003. Letzter Zu-
gri: 24.09.2007
[Bar05] Bartlett,
Neil:
Eintrag
in
den
Eclipse-Newsgroups
http://dev.eclipse.org/newslists/
news.eclipse.technology.equinox/msg01132.html.
am
01.09.2005.
Version: September 2005. Letzter Zugri: 24.09.2007
[Bar07] Bartlett, Neil:
Secure Desktop Applications with Eclipse
http://www.eclipsecon.org/2007/index.php?page=
sub/&id=3889.
Version: März 2007. Letzter Zugri:
RCP.
24.09.2007
What is a Rich Client? http://wbeaton.
blogspot.com/2005/12/what-is-rich-client.html.
[Bea05] Beaton, Wayne:
Version: Dezember 2005. Letzter Zugri: 24.09.2007
[BG03] Birnthaler, Thomas ; Gottschalk, Hermann: OpenLDAP
Lightweight Directory Access Protocol.
LDAP-12.pdf.
http://www.ostc.de/
Version: Juli 2003. Letzter Zugri: 24.09.2007
[Bol03] Bolour, Azad:
Notes on the Eclipse Plug-in Architecture.
http://www.eclipse.
org/articles/Article-Plug-in-architecture/plugin_
architecture.html. Letzter Zugri: 24.09.2007
In: Eclipse Corner Article (2003), Juli.
[Bru04] Brunnstein, Klaus (Hrsg.) ; Universität Hamburg, Fachbereich Informatik (Veranst.): Gestaltbarkeit und Beherrschbarkeit
von Informatiksystemen (GBI). 2004
143
Literaturverzeichnis
144
[BRZ07] Bleek, Wolf-Gideon (Hrsg.) ; Raasch, Jörg (Hrsg.) ; Züllig-
hoven, Heinz (Hrsg.): Software Engineering 2007 - Fachtagung
des GI-Fachbereichs Softwaretechnik. Gesellschaft für Informatik, 2007
Ed:
What is a Rich Client?
http:
//www.eclipsezone.com/eclipse/forums/t59350.html.
[Bur05] Burnette,
Version: Dezember 2005. Letzter Zugri: 24.09.2007
[CoE] Component based End User Development (CoEUD) - Homepage.
http://www.coeud.org.
[Cre04] Creasey,
Letzter Zugri: 24.09.2007
Scaling
Tod:
Large
Eclipse
Applications
www.eclipsecon.org/2004/EclipseCon_
2004_TechnicalTrackPresentations/05_Creasey.pdf.
Progressively.
Version: Februar 2004. Letzter Zugri: 24.09.2007
[CSS] Control System Studio (CSS) - Homepage.
de.
http://css.desy.
Letzter Zugri: 24.09.2007
[CW07] C1-WPS: Synoptic Display Studio Developers Guide. Juni 2007
[Dau] Berthold Daum - Homepage.
http://www.bdaum.de.
Letzter
Zugri: 24.09.2007
[Dau05a] Daum, Berthold:
Java-Entwicklung mit Eclipse 3.1 - Anwen-
dungen, Plugins und Rich Clients. 3. dpunkt.verlag, 2005
[Dau05b] Daum, Berthold:
Rich-Client-Entwicklung mit Eclipse 3.1 -
Anwendungen entwickeln mit der Rich Client Platform.
1.
dpunkt.verlag, 2005. (auch für Eclipse 3.2 erhältlich)
[Dau06] Daum, Berthold: Das Eclipse-Codebuch - 182 Tipps, Tricks und
Lösungen für Eclipse-spezische Probleme.
1.
dpunkt.verlag,
2006
[Dud02] Dudenredaktion:
Duden - Die deutsche Rechtschreibung.
Weltbild Verlag GmbH, 2002
[ebX] ebXML auf Sourceforge.
ebxmlrr/.
[Ecla] Eclipse - Homepage.
24.09.2007
http://sourceforge.net/projects/
Letzter Zugri: 24.09.2007
www.eclipse.org.
Letzter Zugri:
Literaturverzeichnis
145
[Eclb] Eclipse-JAAS
eclipse_jaas.
[Eclc] Eclipse-JAAS
- Homepage.
http://www.integility.com/
Letzter Zugri: 02.07.2007
auf
Sourceforge.
projects/eclipse-jaas.
[Ecld] EclipseCon - Homepage.
http://sourceforge.net/
Letzter Zugri: 24.09.2007
http://www.eclipsecon.org. Letz-
ter Zugri: 24.09.2007
http:
//www.eclipse.org/articles/Whitepaper-Platform-3.
1/eclipse-platform-whitepaper.pdf.
Version: 2006. [Ecl06] Eclipse:
Eclipse-Platform-Whitepaper.
Letzter Zugri: 24.09.2007
[Eng93] Engusser, Hermann: Duden Informatik - Ein Fachlexikon für
Studium und Praxis. Duden Verlag, 1993
http://www.eclipse.org/equinox/.
[Equ] Equinox - Homepage.
Letzter Zugri: 24.09.2007
[ER05] Edgar,
Nick ;
Rapicault, Pascal:
Developing for the
http://www.eclipsecon.org/2005/
presentations/EclipseCon2005_Tutorial26Final.pdf.
Rich Client Platform.
Version: März
2005.
IBM
Rational
Software
Ottawa,
EclipseCon 2005
[Eva] EvansData - Homepage.
www.evansdata.com. Letzter Zugri:
24.09.2007
[FK92] Ferraiolo, David ; Kuhn, Richard: Role-Based Access Con-
trol.
http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf.
Version: 1992. Letzter Zugri: 24.09.2007
[Fow00] Fowler, Martin:
Refactoring - Oder:
Wie Sie das Design
vorhandener Software verbessern. 1. Addison-Wesley, 2000
[GHJV95] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlis-
sides, John:
Entwurfsmuster - Elemente wiederverwendbarer
objektorientierter Software. Addison-Wesley, 1995
[HM04] Horne, Kimberly ; McLaren, Chris:
Activities Support in
http://dev.eclipse.org/viewcvs/index.cgi/
platform-ui-home/activities/activities.html?view=co.
Eclipse 3.0.
Version: Mai 2004. Letzter Zugri: 24.09.2007
Literaturverzeichnis
146
[Hor05a] Horne,
A Context, a Capability, and a Per-
Kimberly:
http://eclipse.pookzilla.
net/2005/12/context-capability-and-perspective.php.
spective
Walk
Into
a
Bar.
Version: Dezember 2005. Letzter Zugri: 24.09.2007
[Hor05b] Horne,
-
Kimberly:
What
to
Do
When
Addressing UI Scalability in Eclipse
Your
Application
is
Too
Compli-
http://www.eclipsecon.org/2005/presentations/
EclipseCon2005_7.1Scalability.pdf. Version: März 2005. cated.
Letzter Zugri: 24.09.2007
[Hor06] Horne, Kimberly: A Context, a Capability, and a Perspective
http://eclipse.pookzilla.
net/2006/10/context-capability-and-perspective.php.
Walk Into a Bar: Capabilities.
Version: Oktober 2006. Letzter Zugri: 24.09.2007
[HWWZ07] Hofer, Stefan ; Wende, Sven ; Will, Alexander ; Zülligho-
ven, Heinz: End User Development für Leitstand-Arbeitsplätze:
Beschreibung einer Systemarchitektur. In: [BRZ07], S. 131143
[ISO] ISO - Homepage.
[ISO94] ISO:
www.iso.org.
Letzter Zugri: 24.09.2007
Information technology - Open Systems Interconnec-
http:
//standards.iso.org/ittf/PubliclyAvailableStandards/
s020269_ISO_IEC_7498-1_1994(E).zip. Version: 2, Novemtion - Basic Reference Model:
ber 1994. Reference Number:
The Basic Model.
ISO/IEC 7498-1:1994(E) -
Letzter Zugri: 24.09.2007
Identikation.
http://www.itwissen.info/
definition/lexikon//__identification_identifikation.
html. Version: 2007. Letzter Zugri: 24.09.2007
[ITW07] ITWissen:
JAAS Authentication Tutorial. http://java.sun.
com/javase/6/docs/technotes/guides/security/jaas/
tutorials/GeneralAcnOnly.html.
Version: Mai 2007. [Jav07a] JavaSun:
Letzter Zugri: 24.09.2007
[Jav07b] JavaSun:
JAAS
Authorization
Tutorial.
//java.sun.com/javase/6/docs/technotes/guides/
security/jaas/tutorials/GeneralAcnAndAzn.html.
Version: Mai 2007. Letzter Zugri: 24.09.2007
http:
Literaturverzeichnis
147
JAAS Reference Documentation. http://java.
sun.com/products/jaas/reference/docs/index.html.
[Jav07c] JavaSun:
Version: Mai 2007. Letzter Zugri: 24.09.2007
[Jav07d] JavaSun:
Java
Authentication
and
Authorization
Ser-
vice (JAAS) Reference Guide for the Java SE Development
http://java.sun.com/javase/6/docs/technotes/
guides/security/jaas/JAASRefGuide.html.
Version: Mai
Kit
6.
2007. Letzter Zugri: 24.09.2007
[KB06] Klinkert, Thomas ; Bertschler, Mario:
Client-Platform (RCP).
com/mb/document.pdf.
Die Eclipse Rich-
http://www.saboracaferestaurant.
Version: Mai 2006. Letzter Zugri:
24.09.2007
[Khe04] Khelifi,
How
Ines:
to
Use
the
Activities
Edi-
http://dev.eclipse.org/viewcvs/index.cgi/
platform-ui-home/activities/tools/activityTool.html?
view=co. Version: Juni 2004. Letzter Zugri: 24.09.2007
tor.
[LR06] Lahres, Bernhard ; Raýman, Gregor:
Praxisbuch Objektori-
entierung - Von den Grundlagen zur Umsetzung.
1.
Galileo
Second
Annual
Computing, 2006
[MA06] Moran,
John
;
Ackerman,
Laura:
Eclipse Global Enterprise Survey Points To Rapid Adoption
Of Eclipse Rich Client Platform.
In:
EclipsePress (2006),
http://www.eclipse.org/org/press-release/
20060905rcp.php. Letzter Zugri: 24.09.2007
September.
[McA05] McAffer,
Eintrag
Je:
in
den
Eclipse-Newsgroups
11.09.2005.
http://dev.eclipse.org/newslists/
news.eclipse.technology.equinox/msg01141.html.
am
Version: September 2005. Letzter Zugri: 24.09.2007
[ME05] Mätzel, Kai-Uwe ; Eicher, Tom:
Contributing to Eclipse:
http://www.eclipsecon.
org/2005/presentations/EclipseCon2005_Tutorial1.pdf.
Understanding and Writing Plug-ins.
Version: März 2005. Letzter Zugri: 24.09.2007
[MG03] Melhem,
Wassim
;
Glozic,
Dejan:
PDE
Does
Plug-
http:
//www.eclipse.org/articles/Article-PDE-does-plugins/
PDE-intro.html. Letzter Zugri: 24.09.2007
ins.
In:
Eclipse Corner Article (2003), September.
Literaturverzeichnis
148
[Mit] Mitlinx LDAP - Homepage.
http://www.mitlinx.de/ldap/.
Letzter Zugri: 24.09.2007
[ML06] McAffer, Je ; Lemieux, Jean-Michel:
eclipse Rich Client
Platform - Designing, Coding, and Packaging Java Applications.
Addison-Wesley, 2006
[Mol01] Molander,
Reducing
Mark:
the
user
interface.
http://www-128.ibm.com/developerworks/web/library/
us-reduce/. Version: Juni 2001. Letzter Zugri: 24.09.2007
[Ope] OpenLDAP - Homepage.
http://www.openldap.org. Letzter
Zugri: 24.09.2007
www.osgi.org. [OSG] OSGi - Homepage.
Letzter Zugri: 24.09.2007
[RF06] Rosenthal, Jay ; Flaherty, Matthew:
plications and Enterprise Security.
org/2006/Sub.do?id=451.
Eclipse RCP Ap-
http://www.eclipsecon.
Version: März 2006. IBM Lotus,
EclipseCon 2006 - Letzter Zugri: 24.09.2007
[Sch05] Schmidt, Rolf: BGB Allgemeiner Teil - Grundlagen des Zivil-
rechts Aufbau des zivilrechtlichen Gutachtens. 2. Verlag Dr. Rolf
Schmidt, 2005
[Sch06] Schneider, Wolfgang:
Grundsätze der Dialoggestaltung DIN
http://www.ergo-online.de/site.aspx?
url=html/software/grundlagen_der_software_ergon/
grundsaetze_der_dialoggestalt.htm.
Version: Oktober
EN ISO 9241-110.
2006. Letzter Zugri: 24.09.2007
[Shn82] Shneiderman, Ben: The Future of Interactive Systems and the
Emergence of Direct Manipulation. Behaviour and Information
Technology. 1982
[Shn83] Shneiderman, Ben: Direct Manipulation: A Step beyond Programming Languages. In: IEEE Computer (1983), August
[Shn87] Shneiderman, Ben:
Designing the User Interface: Strategies
for Eective Human-Computer Interaction.
Addison-Wesley,
1987
http://www.networks.
siemens.de/solutionprovider/_online_lexikon/5/
f009705.htm. Version: 2006. Letzter Zugri: 24.09.2007
[Sie06] Siemens,
AG:
Authentizierung.
Literaturverzeichnis
149
[SM02] Sun Microsystems, Inc:
Java BluePrints:
Model-View-
http://java.sun.com/blueprints/patterns/
MVC-detailed.html.
Version: 2002. Letzter Zugri:
Controller.
24.09.2007
[SNL06] Steel, Christopher ; Nagappan, Ramesh ; Lai, Ray:
core
Security Patterns - Best Practices and Strategies for J2EE, Web
Services, and Identity Management. PRENTICE HALL PTR,
2006
[Sun] XACML Kit auf Sourceforge.
net/.
http://sunxacml.sourceforge.
Letzter Zugri: 24.09.2007
[Ull06] Ullenboom, Christian:
Java ist auch eine Insel - Program-
mieren mit der Java Standard Edition Version 6.
6.
Galileo
Computing, 2006
[Unb06] Unbekannt: Eclipse RCP weiter auf dem Vormarsch. In: Ja-
http://javamagazin.de/itr/
news/psecom,id,30709,nodeid,367.html. Letzter Zugri:
vaMagazin (2006), September.
24.09.2007
[Uni03] University
of
California,
Role
Berkeley:
Based
http://groups.sims.berkeley.edu/
doc-eng/projects/ROLES/research/RBAC_review.doc.
Access
Control.
Version: Januar 2003. Letzter Zugri: 24.09.2007
[WT99] Whitten, Alma ; Tygar, J. D.:
Why Johnny Can't En-
crypt: A Usability Evaluation of PGP 5.0. (1999).
gaudior.net/alma/johnny.pdf.
+
[Z 98] Züllighoven, Heinz u. a.:
http://www.
Letzter Zugri: 24.09.2007
Das objektorientierte Konstruk-
tionshandbuch nach dem Werkzeug & Material-Ansatz.
1.
dpunkt.verlag, 1998
[ZI93] Ziegler,
Jürgen ;
Ilg, Rolf:
Benutzergerechte Software-
Gestaltung. R.Oldenbourg Verlag, 1993
150
Abkürzungsverzeichnis
ACL
Access Control List
API
Application Programming Interface
ASCII
American Standard Code for Information Interchange
CoEUD
Component-based End User Development
CSS
Control System Studio
DAC
Discretionary Access Control
DAP
Directory Access Protocol
DESY
Deutsches Elektronen-Synchrotron
DSD
Dynamic Seperation of Duty
GEF
Graphical Editing Framework
GUI
Graphical User Interface
HAL
Hardware Abstraction Layer
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
IDE
Integrated Development Environment
INCITS
InterNational Committee for Information Technology Standards
IP
Internet Protocol
ISO
International Organization for Standardization
IT
Information Technology
ITU
International Telecommunication Union
J2EE
Java 2 Enterprise Edition
J2SDK
Java 2 Standard Edition Development Kit
J2SE
Java 2 Standard Edition
JAAS
Java Authentication and Authorization Service
JDK
Java Development Kit
JNDI
Java Naming and Directory Interface
JRE
Java Runtime Environment
JVM
Java Virtual Machine
LDAP
Lightweight Directory Access Protocol
MAC
Mandatory Access Control
MVC
Model-View-Controller
151
Abkürzungsverzeichnis
152
OASIS
Organization for the Advancement of Structured Information
Standards
OSGi
Open Service Gateway Initiative
OSI
Open Systems Interconnection
PAP
Policy Administration Point
PDE
Plug-In Development Environment
PDP
Policy Decision Point
PEP
Policy Enforcement Point
PIN
Persönliche Identikationsnummer
PIP
Policy Information Point
RBAC
Role Based Access Control
RCP
Rich-Client-Platform
SAML
Security Assertion Markup Language
SDS
Synoptic Display Studio
SSD
Static Seperation of Duty
SSO
Single Sign-On
SWT
Standard Widget Toolkit
TCP
Transmission Control Protocol
UI
User Interface
URL
Uniform Resource Locator
WAM
Werkzeug- und Material-Ansatz
XACML
eXtensible Access Control Markup Language
XML
eXtensible Markup Language
Index
Dateien
113, 119, 121, 122, 125127,
.exsd . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
actionSets.exsd . . . . . . . . . . . . . . . 37
feature.xml . . . . . . . . . . . . . . . . . . . . 40
fragment.xml . . . . . . . . . . . . . . . 39, 40
manifest.mf . . . . . . . . . . . . . 32, 33, 37
plugin.xml 32, 33, 3739, 86, 87, 89
site.xml . . . . . . . . . . . . . . . . . . . . . . . . 41
139
B
Bediener . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Benutzer . . . . . . . . . . . . . . . . . . . . . . 9, 61
Benutzerauthentizierung . . . . . 1, 92
Benutzerautorisierung . . . . . . . i, 1, 3,
A
5, 18, 46, 47, 51, 53, 54, 56,
Access Control List . . . . . . siehe ACL
102, 107, 108, 110, 111, 115,
ACL . . . . . . . . . . . . . . . . . . . . . . . . . 14, 65
116, 118, 126, 127, 137139
59, 64, 78, 85, 93, 9698, 100
Activation-Adapter . . . . . . 8183, 118
Benutzungsmodell . . . . . . . . . . . . . . . 10
Activation-Management . 8183, 123
Benutzungsoberäche . . . . . . . . . . . . 10
American Standard Code for Infor-
Bundle-Activator . . . . . . . . . 27, 3234
mation Interchange . . . . siehe
ASCII
Anwender . . . . . . . . . . . . . . . . . . . . . . . . 9
Anwendungs-Plug-In . 26, 34, 86, 87,
89, 96, 102, 113, 133
API . . . . . . . . . . . . . . . . . . . . . . 20, 94, 98
Application Programming Interface
C
Capability . 4, 36, 55, 56, 9398, 119,
139
CoEUD . . . . . . . . . . . . . . . . . . . . . . . . 120
Component-based End User Development . . . . . . . . . . . . . . . . . . siehe
siehe API
ASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Attribute . . . . . . . . . . . . . . . . . . . . . . . . 74
aufgabenangemessen . . . . . . . . . . . . . 12
Authentizierung . . . 2, 4, 13, 14, 54,
55, 57, 60, 6568, 72, 76, 80,
83, 91, 122, 127, 136, 139
Autorisierung . . . . . . . . . i, 24, 12, 14,
CoEUD
Condition . . . . . . . . . . . . . . . . . . . . . . . 74
Control System Studio . . . siehe CSS
Core RBAC . . . . . . . . . . . . . . . . . . 61, 62
CSS . . . . . . 4, 100, 111, 120125, 127
D
18, 46, 47, 5458, 60, 61, 66,
DAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
67, 7074, 7680, 8385, 91
DAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
93, 9698, 102, 104, 108110,
DESY . . . . . . . 111, 120, 121, 124, 125
153
Index
154
Deutsches
Elektronen-Synchrotron
siehe DESY
Extension-Point Schema . . . . . . . . . 37
Extension-Point . . . . . . 2830, 33, 34,
Directory Access Protocol . . . . . siehe
3639, 56, 58, 86, 89, 91, 94,
DAP
109, 114, 124
Discretionary Access Control . . siehe
Extension-Registry . . . 2629, 37, 38,
DAC
58, 78, 79, 85, 89, 127
DSD . . . . . . . . . . . . . . . . . . . . . . . . . 61, 64
Extension . 28, 29, 31, 3739, 57, 58,
Dynamic Seperation of Duty . . siehe
DSD
91, 92, 95, 127
F
E
Eclipse-IDE 23, 25, 56, 94, 109, 132,
Fassade . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Fat-Client . . . . . . . . . . . . . . . . . . . 19, 20
133
Eclipse-JAAS . . . . . . 4, 56, 58, 72, 79,
9193, 137
Feature . . . . . . . . . . . . . . . . . . . . . . 26, 40
Fragment . . . . . . . . . . . . . . . . . . . . 26, 39
Eclipse-Newsgroups . . 54, 58, 95, 130
EclipseCon . . . . . . . . . . 5456, 96, 139
G
Eclipse RCP . . . . . . . . . . . . . . i, 24, 8,
18, 19, 2229, 38, 43, 46, 47,
Gebrauchstauglichkeit 11, 12, 47, 48,
52, 53, 57, 126
5456, 58, 59, 72, 78, 79, 84,
85, 91, 92, 100, 102, 110, 111,
GEF . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
120, 127, 130, 132, 133
Genehmigung . . . . . . . . . . . . . . . . . . . . 62
Eclipse 35, 19, 2328, 3133, 3537,
grasche Benutzungsschnittstellen 10
39, 40, 42, 5459, 66, 78, 85,
Graphical Editing Framework . siehe
GEF
91, 9395, 108, 109, 111, 117,
123, 126, 132134, 136139
Endbenutzer . . . . . . . . . . . . . . . . . . . . . . 9
Graphical User Interface . siehe GUI
GUI 2, 10, 22, 52, 54, 60, 72, 76, 84,
Equinox . . . . . . . . . . . . . . . . . . 23, 55, 58
Erlaubnisregel . . . . . . . . . . . . . . . . . . . 18
erwartungskonform . . . . . . . . . . . . . . 12
95
H
Erweiterung . . . . . . . . siehe Extension
Erweiterungspunkt . . . . . . . . . . . . siehe
Hardware Abstraction Layer . . siehe
Extension-Point
Erweiterungsregister . . . . . . . . . . siehe
Executable . . . . 8083, 112, 113, 116,
Control
Markup
Language . . . . siehe XACML
eXtensible Markup Language . siehe
XML
HTML . . . . . . . . . . . . . . . . . . . . . . . 19, 20
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
118, 123125
Access
HAL
Hierarchical RBAC . . . . . . . . . . . 6163
Extension-Registry
eXtensible
HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Hypertext Markup Language . . siehe
HTML
Hypertext Transfer Protocol . . siehe
HTTP
Index
155
I
Java Authentication and Authorization Service . . . . . . . . . . . siehe
IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
JAAS
Identizierung . . . . . . . . . . . . . . . . 1214
Java Development Kit . . . siehe JDK
Identity-Management . . . . . 12, 13, 76
Java Naming and Directory Interface
INCITS . . . . . . . . . . . . . . . . . . . . . . . . . 61
individualisierbar . . . . . . . . . . . . . . . . 12
siehe JNDI
Java Runtime Environment . . . siehe
Information Technology . . . . siehe IT
JRE
Environ-
Java Virtual Machine . . . siehe JVM
ment . . . . . . . . . . . . . . . . . . siehe
JDK . . . . . . . . . . . . . . . . . . . . . . . . . 2, 135
IDE
JNDI . . . . . . . . . . . . . . . . . . . . . . . . 66, 67
Integrated
Development
Interaktionsobjekte . . . . . . . . . . . . . . 10
JRE . . . . . . . . . . . . . . . . . . 132, 135, 136
InterNational
JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Committee
for
In-
formation Technology Standards . . . . . . . . . . . . . . . . . siehe
INCITS
International Organization for Standardization . . . . . . . . . . . . siehe
L
LDAP . . . . . 4, 60, 65, 66, 81, 84, 123
Lightweight Directory Access Protocol . . . . . . . . . . . . . . . . . . . . siehe
ISO
International
Telecommunication
Union . . . . . . . . . . . . siehe ITU
Internet Protocol . . . . . . . . . . siehe IP
IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
ISO . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 65
LDAP
Log-in . 1214, 48, 49, 55, 72, 84, 89,
91, 103, 109, 136, 138, 139
M
IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
ITU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Mandatory Access Control . . . . siehe
J
Model-View-Controller . . siehe MVC
MAC
MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
J2EE . . . . . . . . . . . . . . . . . . . . . . . 55, 132
J2SDK . . . . . . . . . . . . . . . . . 66, 132, 136
J2SE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
JAAS 2, 4, 55, 56, 58, 60, 6668, 71,
72, 84, 91, 92, 115, 122, 123,
135137
Java 2 Enterprise Edition . . . . . siehe
J2EE
Java 2 Standard Edition
Nutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
O
OASIS . . . . . . . . . . . . . . . . . . . . . . . . 2, 73
Open
siehe J2SE
Java 2 Standard Edition Development Kit . . . . . . . . . . . . . . siehe
J2SDK
N
Service
Gateway
Initiative
siehe OSGi
OpenSource . . . . . . . . . . . . . . . 4, 65, 76
Open Systems Interconnection
OSI
siehe
Index
156
Operation . . . . . . . . . . . . . . . . . . . . . . . 62
R
Organization for the Advancement of
Structured Information Stan-
RBAC . 2, 4, 13, 6064, 84, 104, 105
dards . . . . . . . . . . . . . . . . . siehe
RCP-Anwendung . . . . . . . . . . . . . . . 26,
34, 36, 78, 79, 85, 9193, 96,
OASIS
102, 103, 108, 132134, 139
OSGi . . 22, 23, 26, 27, 32, 34, 35, 40,
RCP . . . . 24, 22, 23, 25, 55, 58, 133
58, 79, 133, 138
OSGi-Konsole . . 28, 79, 93, 108, 133,
RCP-Plug-In . . . . . . . . . . . . 26, 93, 137
Rich-Client-Anwendung . i, 1, 2225,
134, 138
28, 31, 56
OSGi-Manifest . . . . . . . . . . . . . . . 32, 33
OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Rich-Client-Platform . . . . siehe RCP
Rich-Client 13, 8, 1922, 46, 60, 64,
P
66, 72, 76, 77, 83, 92
Right-Set . . . . . . . . . . . . . . . . . . . . . . . . 81
PAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Rights-Management . . . . . 80, 81, 123
PDE . . . . . . . . . . . . . . . . . . . . 31, 42, 132
Role Based Access Control . . . . siehe
RBAC
PDP . . . . . . . . . . . . . . . . . 73, 7577, 115
PEP . . . . . . . . . . . . . . . . . . . . . . 73, 7577
Rolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Persönliche
Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Identikationsnummer
siehe PIN
PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
PIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Plug-In
Development
Environment
siehe PDE
Plug-In . . . . . . . . . . . . . . . . . . . . . . . . . . 4,
2042, 5559, 78, 79, 8487,
89, 9198, 102105, 107111,
113, 114, 118, 119, 126, 127,
132, 133, 137139
Plug-In-(De-)Aktivierung . . . . . 4, 59,
7880, 84, 98, 100, 102, 103,
126
Plug-In-Klasse . . . . . . . . . . . . . . . . . . . 34
Plug-In-Manifest . . . . . . . . . . . . . 32, 33
Policy Administration Point . . . siehe
PAP
Policy Decision Point . . . . siehe PDP
Policy Enforcement Point siehe PEP
Policy Information Point . siehe PIP
PolicySet . . . . . . . . . . . . . . . . . . . . . . . . 74
Preference Page . . . . . . . . . 9497, 119
S
SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
SDS . . . . . . . . . 100, 120122, 124, 125
Security-Facade 78, 8084, 100, 111
114, 118122, 125127, 139
Security Assertion Markup Language
siehe SAML
Single Sign-On . . . . . . . . . . . siehe SSO
Singleton . . . . . . . . . . . . . . . . . . . . . . . . 34
Sitzung . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Sourceforge . . . . . . . . . . . . . . . . . . 56, 76
SSD . . . . . . . . . . . . . . . . . . . . . . 61, 63, 64
SSO . . . . . . . . . . . . . . 13, 18, 55, 67, 76
Standard Widget Toolkit siehe SWT
Static Seperation of Duty siehe SSD
SWT . . . . . . . . . . . 22, 23, 43, 117, 122
Synoptic Display Studio . siehe SDS
T
Target . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Index
157
Taschenrechner . . . . . . . . . . . . . . . . . 111
TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Thin-Client . . . . . . . . . 1, 2, 19, 20, 83
Transmission Control Protocol siehe
TCP
Trigger Point . . . . . . . . . . . . 94, 95, 119
U
UI . . . . . . . . . . . . . . . . 22, 30, 3739, 56
Uniform Resource Locator . . . . siehe
URL
Update-Site . . . . 4043, 103, 107110
URL . . . . . . . . . . . . . . . 41, 92, 133, 137
Usability . . . . . . . . . . . . . . . . . . . . . 11, 53
User-Management . . . . . . . 80, 81, 123
User Interface . . . . . . . . . . . . . siehe UI
V
Verbotsregel . . . . . . . . . . . . . . . . . . . . . 18
Verzeichnis . . . . . . . . . . . . . . . . . . . . . . 65
Verzeichnisdienst . . . . . . . . . . . . . . . . 65
W
WAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Werkzeug- und Material-Ansatz siehe
WAM
X
X.500 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
XACML . . . . 2, 4, 60, 7376, 84, 115
XML . . . . . . 31, 33, 37, 73, 74, 81, 93
158
Erklärung
Ich versichere, dass ich die vorstehende Arbeit selbstständig und ohne fremde
Hilfe angefertigt und mich anderer als der im beigefügten Verzeichnis angegebenen Hilfsmittel nicht bedient habe. Alle Stellen, die wörtlich oder sinngemäÿ aus Veröentlichungen entnommen wurden, sind als solche kenntlich
gemacht.
Ich bin mit einer Einstellung in den Bestand der Bibliothek des Fachbereichs
einverstanden.
Hamburg, 25. September 2007
Unterschrift
Erklärung
Ich versichere, dass ich die vorstehende Arbeit selbstständig und ohne fremde
Hilfe angefertigt und mich anderer als der im beigefügten Verzeichnis angegebenen Hilfsmittel nicht bedient habe. Alle Stellen, die wörtlich oder sinngemäÿ aus Veröentlichungen entnommen wurden, sind als solche kenntlich
gemacht.
Ich bin mit einer Einstellung in den Bestand der Bibliothek des Fachbereichs
einverstanden.
Hamburg, 25. September 2007
Unterschrift