Benutzerautorisierung mit Anbindung an die ... · Zusammenfassung Diese Arbeit scha t eine...

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 scha�t eine Grundlage, die Lücke in der Literatur zwischen Kai Meyer undTorsten WitteBenutzerautorisierung und gebrauchstauglichen Benutzungsober�ächen, zu

schlieÿen. Dies geschieht am Beispiel von Rich-Client-Anwendungen aufBasis der Eclipse RCP. Bewährte Autorisierungmechanismen werden vor-gestellt, Kriterien für gebrauchstaugliche Software aufgestellt und aktuelleDiskussionen über Autorisierung im Umfeld der Eclipse RCP zusammenge-fasst. Mit den so gewonnenen Erkenntnissen werden lau�ähige Prototypenentwickelt, die als Grundlage für reale Projekte dienen, in denen Benutzer-autorisierung eine Rolle spielt.

ii

Inhaltsverzeichnis

Motivation 1

Ausgangspunkte der Arbeit . . . . . . . . . . . . . . . . . . . . . . 2Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Vorgehensweise der Autoren . . . . . . . . . . . . . . . . . . . . . . 3Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Abgrenzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . 4Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

I Grundlagen 7

1 Begri�e und De�nitionen 9

1.1 Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Benutzungsober�ächen und Benutzungsfreundlichkeit . . . . . 101.3 Identi�zierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Single Sign-On (SSO) . . . . . . . . . . . . . . . . . . . . . . . 131.5 Authenti�zierung . . . . . . . . . . . . . . . . . . . . . . . . . 131.6 Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.7 Rechtevergabe und -entzug . . . . . . . . . . . . . . . . . . . . 151.8 Filterregeln bei Autorisierung . . . . . . . . . . . . . . . . . . 181.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Die Eclipse Rich-Client-Platform 19

2.1 Was ist ein Rich-Client? . . . . . . . . . . . . . . . . . . . . . 192.2 Was ist die Eclipse Rich-Client-Platform? . . . . . . . . . . . . 22

2.2.1 Zur Entstehungsgeschichte der Eclipse RCP . . . . . . 232.2.2 Open Service Gateway Initiative (OSGi) . . . . . . . . 232.2.3 Erfolg der Eclipse RCP . . . . . . . . . . . . . . . . . . 23

2.3 Die Eclipse Plug-In-Architektur . . . . . . . . . . . . . . . . . 242.3.1 Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.2 Lebenszyklus von Bundles/Plug-Ins . . . . . . . . . . . 26

iii

iv Inhaltsverzeichnis

2.3.3 Extension-Points, Extensions und Extension-Registry . 282.3.4 Plug-In-Abhängigkeiten . . . . . . . . . . . . . . . . . 30

2.4 Eclipse-Architektur in der Praxis . . . . . . . . . . . . . . . . 312.4.1 Aufbau von Plug-Ins . . . . . . . . . . . . . . . . . . . 322.4.2 OSGi-Manifest, Plug-In-Manifest und Bundle-Activator 322.4.3 Anwendungsklassen . . . . . . . . . . . . . . . . . . . . 342.4.4 Wichtige Erweiterungspunkte von Eclipse . . . . . . . . 362.4.5 Eine Beispiel-Erweiterung . . . . . . . . . . . . . . . . 372.4.6 Fragmente . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.7 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.5 Update-Sites und Updates . . . . . . . . . . . . . . . . . . . . 412.6 Abschlieÿende Bemerkungen . . . . . . . . . . . . . . . . . . . 43

II Theoretischer Teil 45

3 Diskussionen 47

3.1 Interaktionsobjekte bei der Benutzerautorisierung . . . . . . . 473.1.1 Meldungsfenster . . . . . . . . . . . . . . . . . . . . . . 483.1.2 Log-in-Dialog . . . . . . . . . . . . . . . . . . . . . . . 493.1.3 Optische Kennzeichnung . . . . . . . . . . . . . . . . . 493.1.4 Sperren von Interaktionsobjekten . . . . . . . . . . . . 503.1.5 Verstecken von Interaktionsobjekten . . . . . . . . . . 513.1.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2 Allgemeine Diskussion . . . . . . . . . . . . . . . . . . . . . . 533.3 Aktueller Diskussionsstand über Autorisierung in der Eclipse

RCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4 Bestehende Konzepte und Lösungen 60

4.1 Role Based Access Control (RBAC) . . . . . . . . . . . . . . . 604.1.1 Core RBAC . . . . . . . . . . . . . . . . . . . . . . . . 614.1.2 Hierarchical RBAC . . . . . . . . . . . . . . . . . . . . 624.1.3 Static Seperation of Duty (SSD) . . . . . . . . . . . . . 634.1.4 Dynamic Seperation of Duty (DSD) . . . . . . . . . . . 644.1.5 Einordnung . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2 Lightweight Directory Access Protocol (LDAP) . . . . . . . . 654.2.1 Einordnung . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3 Java Authentication and Authorization Service (JAAS) . . . . 664.3.1 Authenti�zierung mit JAAS . . . . . . . . . . . . . . . 664.3.2 Autorisierung mit JAAS . . . . . . . . . . . . . . . . . 674.3.3 Einordnung . . . . . . . . . . . . . . . . . . . . . . . . 72

Inhaltsverzeichnis v

4.4 eXtensible Access Control Markup Language (XACML) . . . . 734.4.1 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 734.4.2 Daten�uss . . . . . . . . . . . . . . . . . . . . . . . . . 744.4.3 Umsetzungen und Erweiterungen . . . . . . . . . . . . 764.4.4 Einordnung . . . . . . . . . . . . . . . . . . . . . . . . 76

5 Weitergehende Konzepte und Lösungen 78

5.1 Plug-In-(De-)Aktivierung . . . . . . . . . . . . . . . . . . . . . 785.2 Security-Facade . . . . . . . . . . . . . . . . . . . . . . . . . . 805.3 Auswirkungen unterschiedlicher Systemanforderungen . . . . . 83

6 Bestehende Lösungen für Eclipse 85

6.1 Rollenabhängige Plug-Ins . . . . . . . . . . . . . . . . . . . . . 856.2 Eclipse-JAAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.3 Capabilities (Activities) in Eclipse . . . . . . . . . . . . . . . . 936.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

III Praktischer Teil 99

7 Dienstplaner 101

7.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027.1.1 Plug-In-Struktur . . . . . . . . . . . . . . . . . . . . . 1027.1.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . 1037.1.3 Benutzerverwaltung und Rechtevergabe . . . . . . . . . 104

7.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 110

8 Taschenrechner 111

8.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128.2 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 118

9 Control System Studio 120

9.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229.2 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239.3 O�ene Probleme und Zusammenfassung . . . . . . . . . . . . 124

10 Zusammenfassung und Ausblick 126

vi Inhaltsverzeichnis

IV Anhang 129

A Verweise 130

A.1 Eclipse-Newsgroups . . . . . . . . . . . . . . . . . . . . . . . . 130

B Eingesetzte Werkzeuge 132

B.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132B.2 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

B.2.1 Startkon�gurationen für RCP-Anwendungen . . . . . . 133B.2.2 OSGi-Konsole . . . . . . . . . . . . . . . . . . . . . . . 133

B.3 Java Policy-Tool . . . . . . . . . . . . . . . . . . . . . . . . . 135

C CD-Inhalt 136

C.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136C.2 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136C.3 Ausführbare Beispiele zu JAAS . . . . . . . . . . . . . . . . . 136C.4 Ausführbares Beispiel zu Eclipse-JAAS . . . . . . . . . . . . . 137C.5 Ausführbares Beispiel zu Capabilities . . . . . . . . . . . . . . 139C.6 Taschenrechner . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Abbildungsverzeichnis 141

Literaturverzeichnis 143

Abkürzungsverzeichnis 151

Index 153

Erklärung 159

Motivation

Im Bereich der Anwendungssoftware, insbesondere im Mehrbenutzer- und Kai Meyer undTorsten WitteNetzwerkbetrieb, spielen Sicherheitskonzepte eine wichtige Rolle. Neben

Aspekten wie Netzwerksicherheit und Verschlüsselung ist Benutzerauthen-ti�zierung und -autorisierung in Anwendungen, in denen Daten oder Funk-tionalitäten vor unberechtigtem Zugri� geschützt werden müssen, ein zentra-les Thema und die Grundlage für Sicherheit. Für die Benutzerautorisierungsind im Laufe der Zeit unterschiedliche Konzepte, Standards und proprietäreLösungen entstanden. Einhergehend mit der stetig steigenden Verbreitungvon Rich-Client-Anwendungen ergeben sich weitere Anforderungen und neueMöglichkeiten für die Benutzerautorisierung als bei Thin-Client-Lösungen.Die Anforderung, o�ine arbeiten zu können, erfordert neben (teilweiser) lo-kaler Datenhaltung und Datensynchronisation zwischen Client und Serverauch eine clientseitige Regelung des Zugri�s auf diese Daten. Somit reichtes nicht mehr, nur auf dem Server die einzelnen Funktionsaufrufe gegen un-befugte Benutzung zu sichern. Zusätzlich muss clientseitig eine Instanz vor-handen sein, die entscheidet, ob dem Benutzer einzelne Komponenten bzw.Daten zur Verfügung stehen. Darüber hinaus bieten sich bei der Nutzung vonRich-Clients bessere Möglichkeiten an, dem Benutzer mittels der gra�schenBenutzungsober�äche über z.B. nicht gewährte Funktionen Rückmeldung zugeben. Die meisten Arbeiten, die Sicherheitsmechanismen wie Zugri�skon-trolle und Verschlüsselung behandeln, decken den Bereich der Sicherheit gutab, berücksichtigen jedoch nicht die Auswirkungen in der Handhabung derjeweiligen Endanwendung für den Benutzer.

Die Problematik, die somit auftritt, ist, dem Benutzer nicht nur gewisseAktionen, aufgrund der ihm in seiner Rolle zugesicherten Rechte, zu verbie-ten, 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 Zugri�sver-waltung (je nach Benutzerrolle) gewährten und nicht gewährten Rechte imgesamten System umgesetzt und für einen Benutzer clientseitig und jederzeiteindeutig kenntlich gemacht werden?

1

2 Motivation

Im Rahmen dieser Arbeit wird versucht, die Brücke zwischen der Zugri�s-kontrolle und der Benutzungsober�äche zu schlagen. Dazu wird der aktuelleStand der laufenden Diskussionen zu diesem Thema aufgearbeitet. Es wirdder Frage nachgegangen, welche Konzepte es für die Zugri�sverwaltung gibtund was sie in Bezug auf Aspekte wie Granularität der Rechte, Rechtever-waltung, Feedback für den Benutzer sowie der Sicherheit der verwendetenMethode bieten. Des Weiteren wird untersucht, auf welche Art und Weisedie Auswirkungen der Autorisierung am sinnvollsten in der Benutzungsober-�äche dargestellt werden können.

Ausgangspunkte der ArbeitKai Meyer undTorsten Witte Authenti�zierung und Autorisierung

Authenti�zierung ist die Veri�zierung der Zughörigkeit der angegebenen Iden-tität zu dem momentanen Benutzer, z.B. über die Angabe eines Benutzerna-mens und des dazugehörigen Passwortes. Über Autorisierung werden dannder bestätigten Identität ihre Berechtigungen im System zugeteilt. Diese Be-rechtigungen können von einfachen Lese-/Schreibzugri�en bis hin zur Aus-führung komplexer Aktionen reichen. Zu den bekanntesten Authenti�zie-rungs- und Autorisierungskonzepten gehören u.a. RBAC (Role Based AccessControl - 1992: Ferraiolo und Kuhn), XACML (eXtensible Access ControlMarkup Language - 2003: OASIS) und speziell für Java JAAS (Java Au-thentication and Authorization Service - 2004 (seit JDK 1.3): Sun).

Rich-Clients

Im Gegensatz zu herkömmlichen Thin-Clients bieten Rich-Clients eine brei-tere Palette an nativen GUI-Elementen (Graphical User Interface) und erhö-hen somit die Benutzungsfreundlichkeit. Das Arbeiten ohne ständige Server-verbindung ist mit Rich-Clients ebenfalls möglich und der Netzwerkverkehrkann 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 heu-tige Rich-Client-Applikationen und spielt auf diesem Gebiet eine immer stär-kere Rolle. Zum einen ist sie o�en 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 lassensich unter anderem für die Benutzerautorisierung verwenden.

Ziel der Arbeit

Diese Arbeit gibt einen Überblick über den Stand der aktuellen Diskussio- Kai Meyer undTorsten Wittenen zu dem Thema Benutzerautorisierung in (Rich-Client-)Anwendungen.

Des Weiteren werden eigene konzeptionelle Lösungen für Zugri�skontrollme-chanismen mit Auswirkungen auf die Benutzungsober�äche erarbeitet undvorgestellt. Für diese werden in konkreten Projekten softwaretechnische Lö-sungen entworfen und prototypisch umgesetzt. Dazu kommt die Eclipse Rich-Client-Platform (RCP) zum Einsatz. Auf Basis dieser Konstruktionen soll esAnwendungsentwicklern, die die Eclipse RCP einsetzen, auf einfache Weisemöglich sein, Zugri�skontrollen in ein Anwendungssystem zu integrieren, sodass für den Benutzer jederzeit seine gewährten Rechte eindeutig erkennbarsind. Die mögliche Ausblendung nicht gewährter Aktionen (Menüeinträge,Schalt�ächen, usw.) führt zudem zu einer Komplexitätsreduktion der gesam-ten Benutzungsober�äche.

Vorgehensweise der Autoren

Um das festgesteckte Ziel zu erreichen, haben die Autoren die Literatur Kai Meyer undTorsten Wittezu den Themen Benutzerautorisierung und benutzergerechte Softwaregestal-

tung sowohl innerhalb als auch auÿerhalb des Eclipse-Kontextes durchsucht.Ebenso wurden gemeinsam Lösungen ermittelt, wie Autorisierung und Be-nutzungsober�ächen miteinander in Wechselwirkung treten können. Die ge-sammelten Methoden und Konzepte wurden analysiert und anhand ausge-wählter Kriterien miteinander verglichen. Dazu haben die Autoren theore-tische Szenarien durchgespielt sowie kleine Beispielanwendungen entwickeltund getestet. Sofern möglich, sind die Autoren mit den Verfassern der für dieEclipse RCP vorgeschlagenen Techniken in Kontakt getreten. Dazu gehörenBerthold Daum und Je� McA�er. Vor dem Hintergrund realer Projekte undmittels der gewonnenen Erkenntnisse entwickelten beide Autoren gemeinsamPrototypen, die den jeweiligen Anforderungen an die Benutzerautorisierunggerecht werden. Die verwendeten Werkzeuge und Beispielprogramme sinddieser Arbeit auf einer CD beigefügt.

4 Motivation

Aufbau der Arbeit

Die Arbeit gliedert sich in einen Grundlagenteil sowie einen theoretischenKai Meyer undTorsten Witte und einen praktischen Teil.

Teil 1 - Grundlagen

Um auf die anschlieÿenden Kapitel vorzubereiten, befasst sich der Grund-lagenteil mit Begri�en und De�nitionen, auf die die späteren Kapitel auf-bauen. Ferner wird eine kurze Einleitung in die Eclipse RCP und derenPlug-In-Konzept gegeben. Die nötigen Grundlagen der Plug-In- bzw. RCP-Entwicklung werden an dieser Stelle erklärt.

Teil 2 - Theorie

Der theoretischen Teil beginnt mit einer grundsätzlichen Diskussion über dieDarstellung von Berechtigungen innerhalb von Benutzungsober�ächen. An-schlieÿend werden die heute existierenden Authenti�zierungs- und Autorisie-rungsmechanismen RBAC (Role Based Access Control), LDAP (LightweightDirectory Access Protocol), JAAS (Java Authentication and AuthorizationService), XACML (eXtensible Access Control Markup Language), deren Ein-zelaufgaben und ihr Zusammenspiel vorgestellt und diskutiert. Insbesonderestellen die Autoren die Möglichkeiten, der Eclipse RCP vor (z.B. Capabilitiesund Plug-In-(De-)Aktivierung) und untersuchen in diesem Kontext angesie-delte OpenSource-Lösungen (wie Eclipse-JAAS). Es wird sich mit der Fragebeschäftigt, welche vorhandenen Eclipse-Mechanismen für die Zugri�sver-waltung verwendet werden können und was ggf. ergänzt werden muss. Auchwerden hier verschiedene konzeptionelle Lösungen für o.g. Problemstellungerarbeitet.

Teil 3 - Praxis

Der anschlieÿende praktische Teil beschäftigt sich mit der softwaretechni-schen Umsetzung der im zweiten Teil vorgestellten konzeptionellen Lösungenin Form von Prototypen. Dazu wird ein erweiterbarer Taschenrechner vor-gestellt, der als funktioneller Prototyp für das im Anschluss beschriebeneCSS-Projekt dient. Auÿerdem werden Auszüge aus der Realisierung desAutorisierungsmechanismus eines Dienstplaner-Systems für ein Alten- undP�egeheim skizziert.

Motivation 5

Abgrenzung der Arbeit

Komplette Sicherheit wird nur durch Sicherheit auf jeder einzelnen Systeme- Kai Meyer undTorsten Wittebene (Server, Netzwerk, Client, Betriebssystem) gewährleistet. Der Fokus

dieser Arbeit liegt jedoch überwiegend auf der clientseitigen Benutzerauto-risierung. So wird im praktischen Teil vorausgesetzt, dass im Anwendungs-system angemeldete Benutzer korrekt authenti�ziert sind. Ebenso werdenSchutzmaÿnahmen gegen Angri�e, die sich gegen die zugrunde liegendenTechnologien oder die Programmiersprache Java richten, in dieser Arbeitnicht behandelt.

Konventionen

Zu Beginn eines Kapitels oder Abschnittes ist am äuÿeren Seitenrand der Kai Meyer undTorsten WitteAutor vermerkt. Falls verschiedene Autoren Unterabschnitte zu einem Ab-

schnitt beitragen, dann ist der jeweilige Autor bei jedem Unterabschnitt an-gegeben. Sind dagegen alle Unterabschnitte von dem selben Autor, dannwird dieser nur zu Beginn des umfassenden Abschnittes genannt.Bei Textpassagen, die wörtlich oder sinngemäÿ aus Verö�entlichungen ent-nommen wurden, sind am Ende des jeweiligen Abschnitts die zugehörigenQuellenangaben in eckigen Klammern aufgelistet. Direkte Zitate sind �kur-siv� gekennzeichnet. De�nitionen oder Kernbegri�e eines Abschnittes werdenfett dargestellt.Der Text enthält meist maskuline Bezeichnungen, um Textpassagen zu ver-meiden wie �Für einen Anwender/eine Anwenderin, der/die nicht die Berech-tigung besitzt, . . . �. Frauen sind selbstverständlich ebenfalls gemeint.Zu Beginn der Erstellung dieser Arbeit war Eclipse in der Version 3.2.2 ak-tuell und Version 3.3 befand sich noch in der Entwicklung1. Daher beziehtsich diese Arbeit auf die zu der Zeit aktuell verfügbaren Version.

1Eclipse 3.3 wurde am 29.06.2007 verö�entlicht.

6

Teil I

Grundlagen

7

8 Teil 1 - Grundlagen

Der erste Teil dieser Arbeit liefert die Grundlagen für die nachstehendenKai Meyer undTorsten Witte Teile. So ist das erste Kapitel wichtigen Begri�en und De�nitionen gewid-

met, die vorab einen Einstieg in die Thematik bilden. Das anschlieÿendezweite Kapitel stellt Rich-Clients und die Eclipse Rich-Client-Platform inihren Grundzügen vor. Diese Einführung reicht aus, um selbst Eclipse RCP-Neulingen das Verständnis der folgenden Teile zu ermöglichen.

Kapitel 1

Begri�e und De�nitionen

Die Kernfrage dieser Arbeit handelt von der korrekten und benutzergerechten Kai Meyer undTorsten WitteUmsetzung von Benutzerrechten innerhalb der Benutzungsober�äche eines

Softwaresystems. In diesem Zusammenhang werden einige Begri�e verwen-det, die an dieser Stelle erläutert werden.

1.1 Benutzer

Am Entwicklungsprozess von Software sind verschiedene Akteure beteiligt. Torsten WitteDazu gehören neben den Entwicklern, die die Anwendungssoftware konstru-ieren, auch die Benutzer, die die Anwendungssoftware am Arbeitsplatz ein-setzen. Allgemein betrachtet ist ein Benutzer eine natürliche Person, die zurErledigung einer Aufgabe ein Hilfsmittel verwendet, um daraus einen Vorteilzu erzielen. Dabei kann es sich u.a. um Zeitersparnis und Kostenverringerunghandeln. Im IT-Bereich ist also ein Akteur in der Rolle des Benutzers einenatürliche Person, die zur Erledigung einer Aufgabe ein Softwareprodukt ver-wendet, 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� desWerkzeug- und Material-Ansatzes (WAM) [Z+98] betrachtet Benutzer alskompetente Akteure und Fachleute in ihrem Arbeitsgebiet.Im Folgenden werden die Begri�e Nutzer und Endbenutzer als Synonymfür Benutzer verwendet. Anwender sind dagegen Personen oder Organisa-tionen, die eine Benutzung veranlassen, ohne unbedingt selbst (direkt) Benut-zer zu sein. Die in der Literatur ebenfalls verwendete Bezeichnung Bedienerist 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


1.2 Benutzungsober�ächen und Benutzungs-

freundlichkeit

Damit ein Benutzer mit dem Softwaresystem interagieren kann, ist eine ge-Torsten Witteeignete Schnittstelle notwendig. Diese Mensch-Maschine-Schnittstelle mussbenutzergerecht gestaltet sein, um den Nutzer bei seiner Arbeit nicht zu be-einträchtigen oder gar zu behindern. Dazu haben im Laufe der Zeit nebenErkenntnissen der Informatik auch solche aus der Medienpsychologie, derArbeitswissenschaft, der Kognitionswissenschaft, der (Software-)Ergonomie,der Soziologie und dem Design beigetragen.

Heutzutage besitzen die meisten interaktiven Systeme gra�sche Benut-zungsschnittstellen. Fenster, Menüs, Werkzeugleisten, Schalt�ächen undDialoge sind kaum noch vom Bildschirm wegzudenken. In dieser Arbeit wer-den in diesem Zusammenhang auch die Begri�e GUI (engl. Graphical

User Interface) oder Benutzungsober�äche verwendet. Die weit ver-breitete Bezeichnung �Benutzerober�äche� ist etwas unglücklich gewählt, daes sich bei der Ober�äche des Benutzers um seine Haut handelt und nichtum eine Schnittstelle zwischen Mensch und Maschine. Auch die wörtlicheÜbersetzung von �Graphical User Interface�, nämlich �gra�sche Benutzer-schnittstelle� ist nicht ganz tre�end 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 ineiner gra�schen Benutzungsober�äche zu �nden sind, werden unter dem Sam-melbegri� Interaktionsobjekte zusammengefasst.

Die Gestaltung einer Benutzungsober�äche bezieht sich nicht nur auf de-ren Layout (Präsentation) oder die Nutzung der unterschiedlichen Interakti-onsmöglichkeiten (Handhabung) mit dem Computer. Auch die Vorstellungoder das Bild, das sich die Benutzer beim Einsatz im jeweiligen Anwendungs-kontext machen, muss berücksichtigt werden. In [Z+98, S.71] wird dazu dasBenutzungsmodell eingeführt. Es soll verdeutlichen, mit welchen Mittelnund auf welche Weise die anstehenden Aufgaben eines Benutzers unterstütztwerden. �Ein Benutzungsmodell ist ein fachlich orientiertes Modell darüber,wie Anwendungssoftware bei der Erledigung der anstehenden Aufgaben imjeweiligen Einsatzkontext benutzt werden kann. Das Benutzungsmodell um-fasst eine Vorstellung von der Handhabung und Präsentation der Softwareaber auch von den fachlichen Gegenständen, Konzepten und Abläufen, dievon der Software unterstützt werden.�

Benutzungsober�ächen und Benutzungsfreundlichkeit 11

Gra�sche Benutzungsober�ächen verwenden Symbole und Metaphern,um die Interaktion des Menschen mit dem Computer zu erleichtern. Diebekannteste Metapher ist die des Schreibtisches oder Desktops. Dort gibt eseinen Arbeitsplatz, an dem symbolisch dargestellte Dokumente mit Hilfe derMaus ausgewählt und z.B. in einem Ordner oder dem Papierkorb abgelegtwerden können. Objekte aus dem Alltag werden auf Datenobjekte im Systemabgebildet und umgekehrt.Das Prinzip der direkten Manipulation ist auf Shneiderman ([Shn82; Shn83;Shn87]) zurückzuführen. Durch die Verwendung und Darstellung von konkre-ten Objekten (z.B. Textdokumenten) lässt sich die Interaktion des Benutzersmit dem System auf einen relativ kleinen Satz von Operationen beschrän-ken (z.B. Umbenennen, Bearbeiten, Drucken, Löschen). Dies vermittelt denEindruck, die am Bildschirm dargestellten Objekte unmittelbar handhabenzu 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 Maus-bewegungen, Selektionsaktionen und Funktionstastenbetätigungen

• Schnelle, umkehrbare, einstu�ge Benutzeraktionen mit unmittelbarerRückmeldung

Das bedeutet aber noch nicht, dass eine gra�sche Benutzungsober�ächevon vornherein benutzergerecht gestaltet ist. Dazu muss sie, neben demBenutzungsmodell, einige weitere Kriterien erfüllen. Ein wichtiger Aspekt inder Mensch-Computer-Interaktion ist dieGebrauchstauglichkeit von Soft-und Hardware (engl.: usability). Hierfür gibt es die im Jahr 2006 über-arbeitete Norm ISO 9241 �Ergonomie der Mensch-System-Interaktion� derInternational Organization for Standardization [ISO]. Die Normde�niert, 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


• Erlernbarkeit

Als Leitkriterien für die Gebrauchstauglichkeit von Software werden u.a. ge-nannt:

• E�ektivität zur Lösung einer Aufgabe

• E�zienz der Handhabung des Systems

• Zufriedenheit der Nutzer einer Software

Im Kontext dieser Arbeit sind besonders die Aufgabenangemessenheit, dieErwartungskonformität und die Individualisierbarkeit von Bedeutung. EinDialog ist aufgabenangemessen, wenn er den Benutzer unterstützt, seineArbeitsaufgabe e�ektiv und e�zient zu erledigen. Weiter ist ein Dialog er-wartungskonform, wenn er konsistent ist und den Merkmalen des Benut-zers entspricht, z.B. seinen Kenntnissen aus dem Arbeitsgebiet, seiner Aus-bildung und seiner Erfahrung sowie allgemein anerkannten Konventionen.Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen andie Erfordernisse der Arbeitsaufgabe sowie an die individuellen Fähigkeitenund Vorlieben des Benutzers zulässt.

[ZI93, S.9�, S.145�, S.160�], [Z+98, S.71], [Sch06]

1.3 Identi�zierung

Identi�zierung oder auch Identi�kation ist laut Duden [Dud02] eine �Fest-Kai Meyerstellung der Identität�. Bei [ITW07] steht unter Identi�kation: �Die Identi-�kation ist die Überprüfung einer Person oder eines Objektes in Bezug aufvorgelegte, eindeutig kennzeichnende Merkmale, die Identität.� Die Begri�eIdenti�kation und Identi�zierung werden häu�g synonym verwendet. Dader Begri� Identi�kation auch für die Einfühlung in einen anderen Menschensteht, wird in dieser Arbeit der Begri� Identi�zierung verwendet. In einemComputersystem bedeutet Identi�zierung somit, dass der aktuelle Benutzereiner dem System bekannten Identität zugeordnet wird. Im Standardfallerfolgt dies durch einfache Eingabe eines Benutzernamens in einem Log-in-Dialog. Die Identi�zierung kann aber ebenso durch die Wiedererkennungeines Fingerabdrucks geschehen. Durch diesen Vorgang besitzt die Personnoch keine Rechte im System. 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 Identi�zierung ei-ner Person oder Prozesses in dem betre�enden System. Das Management

Single Sign-On 13

unterstützt darüber hinaus bei der Verwaltung der Identitäten, besondersbei Verwendung eines Intranets oder des Internets. Dazu gehört das Erzeu-gen bzw. Löschen von Identitäten sowie deren Zuordnung zu Rollen (vgl.RBAC, Abschnitt 4.1). In groÿen Unternehmen kann dadurch die Zeit, bisein neuer Anwender produktiv wird, reduziert werden (siehe auch [SNL06,S.39]). Des Weiteren kann das Identity-Management die Identitäten anderenAnwendungen und Services in heterogenen Umgebungen bereit stellen, umso 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 Pro- Kai Meyergrammen, die durch ein Log-in geschützt sind. Ein Single Sign-On er-spart dem Benutzer, sich bei jedem Service separat anzumelden und sichebenso den betre�enden Account zu merken. Auÿerdem beugt es Sicher-heitsproblemen vor, die dadurch entstehen, dass sich ein Benutzer nicht beieinem der Dienste abgemeldet hat. Wie schon dem Begri� �Single Sign-On�zu entnehmen ist, meldet sich der Benutzer nur ein einziges Mal an. DasIdentity-Management kümmert sich ab diesem Zeitpunkt um die An- sowieAbmeldung bei allen gestarteten Anwendungen. Dies erhöht nicht nur dieSicherheit, sondern steigert auch die E�zienz der Anwendung, da der Ar-beits�uss der Benutzer nicht ständig durch einen erneuten Anmeldevorganggestört wird.

[SNL06]

1.5 Authenti�zierung

Ähnlich wie bei Identi�zierung und Identi�kation gibt es auch bei der Ver- Kai Meyerwendung der Begri�e Authenti�zierung und Authentisierung Unterschiede,obwohl sie im normalen Sprachgebrauch oft synonym verwendet werden. Au-thenti�zierung ist die Überprüfung (Veri�zierung) der angegebenen Identitäteines Gegenübers, z.B. einer Person oder eines Computersystems. Authenti-sieren wird als �glaubwürdig, rechtsgültig machen� [Dud02] beschrieben. Daes in dem hier geschilderten Vorgang um die Überprüfung der Identität geht,wird im weiteren Verlauf der Arbeit der Begri� Authenti�zierung ver-wendet. Für die Authenti�zierung kann von einer sich anmeldenden Personabgefragt werden:


• Wissen, das nur diese Person haben kann (z.B. Passwörter, PINs)

• Besitz, der der Person zugeordnet werden kann (z.B. Schlüssel, Chip-Karten)

• biometrische Merkmale der Person selbst (z.B. Fingerabdruck, Iris)

Allerdings hat jede Form der Authenti�zierung ihre Schwachpunkte. Passwör-ter können geraten oder ausspioniert, Schlüssel bzw. Karten gestohlen undScanner für Fingerabdrücke überlistet werden. Durch Kombinationen dergenannten Merkmale (z.B. Abfrage von Wissen und Besitz) lässt sich dieSicherheit der Authenti�zierung erhöhen. Für die richtige Wahl der Authen-ti�zierungsverfahren ist nicht nur dieser Aspekt wichtig, sondern auch derAspekt der technischen Möglichkeiten. So hat z.B. nicht jeder einen Karten-leser oder Scanner für biometrische Daten an seinem Arbeitsplatz.

Die Grenze zwischen Identi�zierung und Authenti�zierung ist manchmalschwer zu �nden. �From a technical perspective, most of us get confused whenwe try to distinguish between identi�cation and authenti�cation processes.�[SNL06, S.29] Bei einem Log-in-Dialog sind die Verantwortlichkeiten nochklar erkennbar. Die Eingabe des Benutzernamens ist die Identi�zierung, diedes Passwortes die Authenti�zierung. Doch schon beim Einscannen einesFingerabdrucks sind die Grenzen verwischt. Denn durch das Einlesen desFingerabdrucks wird die entsprechende Identität ermittelt, aber ebenso be-stätigt, dass die Person auch zu der Identität gehört.

[SNL06], [Dud02], [Sie06]

1.6 Autorisierung

Autorisierung ist die Festlegung, welche Rechte die im System angemel-Kai Meyerdete und somit auch authenti�zierte Person bekommt. Die Rechte geben an,welche Funktionen vom Benutzer ausgeführt werden dürfen, welche Dateiengelesen und geschrieben oder welche Software-Komponenten zur Verfügungstehen. Um dies zu erreichen, gibt es verschiedene Techniken. Eine der be-kanntesten Methoden ist die Verwendung von Access Control Lists (ACLs).Sie enthalten alle Benutzer und die ihnen gewährten Rechte, wie z.B. Lese-oder Schreibrechte. Auch die Zuordnung von Benutzern zu Rollen ist weitverbreitet. Dabei überprüft die Anwendung, ob ein Angehöriger der Rolle AAktion B ausführen darf. Im UNIX-Betriebssystem legt der Erzeuger einerDatei die Zugri�srechte für alle anderen Benutzer fest. Auf diese Thematikwird in Abschnitt 1.7 noch weiter eingegangen.

[SNL06]

Rechtevergabe und -entzug 15

1.7 Rechtevergabe und -entzug

Eingangs wurden Benutzer als am Softwareentwicklungsprozess beteiligte Torsten WitteAkteure eingeführt. Wie alle Akteure sind auch Benutzer natürliche Per-sonen. Juristisch gesehen ist eine natürliche Person der Mensch in seinerRolle als Rechtssubjekt, d.h. als Träger von Rechten und P�ichten. Die sog.Rechtsfähigkeit beginnt gemäÿ �1 des Bürgerlichen Gesetzbuches (BGB) mitder Vollendung der Geburt. Demnach besitzt jeder Mensch von Beginn sei-nes Lebens gewisse Rechte.In Bezug auf ein Softwaresystem ist das eher die Ausnahme. Schlieÿlich darfnicht jede natürliche Person bestimmte Daten einsehen oder gar verändern(schon aus juristischen Gründen). Somit müssen diese Daten vor unberech-tigtem Zugri� geschützt werden. Den meisten Personen wird also der Zugri�auf alle Daten und Funktionen innerhalb eines Systems bzw. auf das Systemselbst verwehrt. Auch die Benutzer, die auf das System zugreifen dürfen,besitzen trotzdem nicht die Berechtigung, alles zu tun, und haben nur einge-schränkte Rechte. Lediglich ein Administrator oder der Firmenchef besitztalle Rechte, wenn überhaupt.

Sobald eine Rechteverwaltung/Zugri�skontrolle in ein System integriertwerden soll, stellt sich eine Reihe von Fragen. Abgesehen von den technischenSchwierigkeiten, 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 authenti�zierte Benutzer weitergereicht wer-den?

Je nach Kontext und Betrachtungsebene belaufen sich die Rechte aufeinfache 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änenspezi�sche Berechtigungen hinzu, diemeist nur gröÿere Konstrukte der erstgenannten sind. Zum Beispiel darfaufgrund der Organisation innerhalb eines Alten- und P�egeheimes nur dieHeimleitung die Freistellungsanträge von Mitarbeitern genehmigen. Vorstell-bar ist also das Recht �Freistellungsanträge genehmigen� für eine bestimmte


Benutzergruppe. Im System kann dies durch eine einfache Schreibberechti-gung umgesetzt werden, die sich auf ein Feld mit booleschen Werten (geneh-migt/abgelehnt) einer Datenbanktabelle bezieht.

Für die Vergabe und den Entzug von Rechten gibt es unterschiedlicheAutorisierungsstrategien:

• Zentral: z.B. durch einen Administrator (z.B. bei Mandatory AccessControl (MAC))

• Dezentral: durch verschiedene Benutzer (i.d.R. bei Discretionary Ac-cess Control (DAC))

• Eigentümerprinzip: Der Erzeuger eines Objektes wird sein Eigentümerund kann Rechte am Objekt vergeben/entziehen

• Hierarchisch dezentralisiert: Eine zentrale Autorität vergibt Admini-stratorrechte für einzelne Teile der Anwendung an Sub-Administratoren

• Kooperativ: Die Vergabe von Rechten �ndet nur in Zusammenarbeiteiner Gruppe von Benutzern statt (4-Augen-Prinzip)

Ebenso existieren verschiedene Methoden für die Menge der vergebenenBerechtigungen zu einem Zeitpunkt:

• Need-to-know: Jeder Benutzer bekommt nur die Rechte, die er höch-stens braucht.

• Minimum privilegies: Über das Need-to-know Prinzip hinaus bekommtjeder Nutzer nur die Rechte, die er aktuell braucht.

Gerade der Entzug von Rechten führt weitere Fragen mit sich. FallsBenutzer ihre Rechte an andere Benutzer weiterreichen können, sollen dannweitergereichte Rechte ebenfalls entzogen werden, wenn dem Benutzer, derein Recht weitergereicht hat, das betre�ende Recht entzogen wird?Unabhängig davon ist zu klären, welche Auswirkungen sich für den Benutzerergeben. Folgendes Szenario ist vorstellbar: Ein Benutzer bearbeitet geradeein Dokument (weil er die Befugnis hat) und ihm wird währenddessen diesesRecht entzogen. Ab wann gilt der Entzug des Rechtes? Sofort oder erstnach einem Neustart der Anwendung? Wann wird der Benutzer darüber inKenntnis gesetzt und was passiert mit dem bearbeiteten Dokument? Es gibtverschiedene, mehr oder weniger sinnvolle, Möglichkeiten:

1. Es erscheint sofort ein Meldungsfenster mit einem entsprechenden Hin-weis.

Rechtevergabe und -entzug 17

a. Der Benutzer kann noch weiter arbeiten und seine Änderungen andiesem Dokument abspeichern.

b. Der Benutzer kann noch weiter arbeiten, wird aber nicht abspei-chern können.

c. Das Dokument wird geschlossen und alle Änderungen rückgängiggemacht.

2. Erst beim Speichern erscheint eine Meldung über die fehlende Berech-tigung.

a. Das aktuelle Dokument wird noch gespeichert.b. Das aktuelle Dokument wird nicht gespeichert und alle Änderun-

gen verworfen.

3. Beim nächsten Ö�nen des Dokumentes erscheint eine Meldung über dieentzogenen Rechte.

a. Bei der vorherigen Bearbeitung wurde das Dokument noch gespei-chert.

b. Bei der vorherigen Bearbeitung wurde das Dokument nicht ge-speichert und alle Änderungen verworfen.

Sicherlich gibt es noch weitere Varianten. Aus Benutzersicht ist wohl einemöglichst schnelle Rückkopplung wünschenswert, ohne die aktuelle Arbeitzu 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äu�g auf Datenbank-Ebene disku-tiert, um den Zugri� auf die darin enthaltenen Daten zu schützen. VieleDatenbanksysteme bieten vernünftige Lösungen an, so dass diese in der ei-genen Anwendung nur aufgegri�en werden brauchen. Dadurch besteht derSchutz sehr nah an den Daten selbst. Allerdings ist damit noch kein Bezugzu der Benutzungsober�äche der eigenen Anwendung gescha�en. Im (ausEntwicklersicht) einfachsten Fall erhält der Benutzer entsprechende Meldun-gen 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 erneutanwählen.

Auf jeden Fall sollte die Rechteverwaltung von Beginn der Entwicklungan mit in die Architektur der Anwendung einbezogen werden. Dies erspartunnötige Arbeit und erhöht die Sicherheit des Systems.

[Sch05, S.39], [Bru04, Kap.7]


1.8 Filterregeln bei Autorisierung

Zum Schutz vor Angri�en aus einem anderen Netzwerk (z.B. dem Internet)Torsten Wittewerden Firewalls eingesetzt. Diese lassen lediglich bestimmte Dienste in daslokale Netzwerk durch. Für diese Autorisierung von Diensten gibt es zweiFilterregeln. Die Verbotsregel besagt, dass als gefährlich eingestufte Dien-ste verboten werden. Dies ist ein sehr einfaches Verfahren. Dienste, die nichtexplizit verboten werden, bleiben erlaubt und werden nicht in ihrer Ausfüh-rung 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 sichereingestuften Dienste erlaubt.Diese Filterregeln lassen sich von dem Firewall-Kontext auch auf die Benut-zerautorisierung übertragen. Nach der Verbotsregel werden einem Benutzergrundsätzlich alle Dienste erlaubt und nur bestimmte Funktionalitäten oderKomponenten verboten. Im Gegensatz dazu werden dem Benutzer analogzur Erlaubnisregel generell alle Dienste verboten und nur bestimmte erlaubt.

[Bru04, Kap.3]

1.9 Zusammenfassung

Die in diesem Kapitel genannten Begri�e und De�nitionen bilden das Basis-Kai Meyer undTorsten Witte vokabular und die Grundlage für diese Arbeit. Sie wurden hier vorgestellt,

um von Anfang an Missverständnissen vorzubeugen, da einige Begri�e in derLiteratur unterschiedlich verwendet werden. Im weiteren Verlauf dieser Ar-beit werden die Begri�e durchgehend verwendet:Benutzer werden von einem Softwaresystem authenti�ziert, um ihre Identi-tät zu bestätigen. Ein Single Sign-On erleichtert dabei den Anmeldevorgangbei anwendungsübergreifenden Systemen. Über die Autorisierung erhaltendie Benutzer ihre Berechtigungen innerhalb des Systems. Dies kann überunterschiedliche Strategien und Filterregeln realisiert werden.Wenn die Benutzer ihren Aufgaben nachkommen, interagieren sie über dieBenutzungsober�äche und Interaktionsobjekte mit der Anwendung. Die Ober-�äche sollte daher für eine benutzergerechte Gestaltung bestimmte Kriterienerfüllen und ein passendes Benutzungsmodell umsetzen, um die Benutzernicht bei ihrer Arbeit zu behindern.

Das nächste Kapitel liefert einen Einblick in eine weitere Grundlage dieserArbeit: die Eclipse Rich-Client-Platform.

Kapitel 2

Die Eclipse Rich-Client-Platform

Dieses Kapitel behandelt Grundlagen von Rich-Clients, Eclipse und der Torsten WitteEclipse RCP. Es ist nicht das Ziel, Eclipse oder die Entwicklung von Eclipse-Rich-Clients in vollem Umfang und bis in das letzte Detail zu erläutern,sondern lediglich einen kurzen Einblick zu geben und auf spätere Kapitelvorzubereiten.

2.1 Was ist ein Rich-Client?

Ein Rich-Client ist ein Ableger des Fat-Clients mit reichhaltigeren Problem- Torsten Wittelösungen. Er bietet die Vorteile eines Fat-Clients sowie einige eines Thin-Clients ohne zusätzliche Nachteile.Um einen Rich-Client genauer de�nieren und abgrenzen zu können, ist esdaher nötig, zuerst die Begri�e 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 werdenmeist in Form von HTML-Dateien über das Intra- bzw. Internet übertragen.Zudem übernehmen Thin-Clients die Interaktion mit dem Benutzer, d.h. dieEingabe über Formulare. Daher reicht ein gängiger Webbrowser auf Client-seite aus. Die gesamte Logik der Anwendung be�ndet sich auf dem Server.

Vorteile von Thin-Clients:

• Kaum bis gar kein Installationsaufwand des Clients, denn Webbrowsersind bereits in den meisten Betriebssystemen integriert.

• Reduzierung des Trainingsaufwandes, da jeder seinen bevorzugtenWeb-browser verwenden kann und das Benutzungsmodell für alle Anwendun-gen gleich ist.

19


• Anwendungen können leicht über das Internet zur Verfügung gestelltwerden. So können Mitarbeiter auch von zu Hause aus arbeiten.

• Änderungen, die auf dem Server durchgeführt werden, werden automa-tisch und ohne Installationsaufwand von allen Clients übernommen.

• Benutzungsober�ächen sind relativ einfach und günstig zu implemen-tieren.

Nachteile von Thin-Clients:

• Reine HTML-Seiten sind statisch und nur sehr wenige Dialogelementestehen zur Verfügung. Darunter leidet die Benutzungsfreundlichkeit.1

• Thin-Clients können nur Online verwendet werden. Der Server ist dieeinzige Datenquelle, die sie besitzen.

• Sie sind nicht geeignet für Anwendungen, die einen groÿen Rechen-aufwand für die Darstellung benötigen. Diese Aufgabe überschreitetmeistens die Rechenleistung des Servers. Auÿerdem ist der Durchsatzdes Datentransfers begrenzt.

Ein Fat-Client ist das Gegenstück zum Thin-Client. Zu einem Fat-Clientwerden zu der API (Application Programming Interface) auch die dazugehö-rige Hardware, und deren Abstraktionsschicht (engl. Hardware AbstractionLayer, HAL) gezählt. Ein Fat-Client ist also weder hardware-, noch plattfor-munabhä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 eigent-liche Datenverarbeitung wird clientseitig durchgeführt. Die gra�sche Benut-zungsober�ä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 Nach-teilen entgegenzuwirken, bietet sich der Rich-Client an. Rich-Clients be-sitzen ein robustes Komponentenmodell, das durch Module und Plug-Inserweiterbar ist. So löst ein Rich-Client nicht nur ein Problem (was bei Fat-Clients üblich ist), sondern kann auch noch artverwandte oder gar artfremdeProbleme lösen. Idealerweise können fremde Lösungen (z.B. von verschiede-nen Anbietern) innerhalb eines Rich-Clients zusammen arbeiten, so dass siewie eine einzige Anwendung erscheinen. Software-Entwickler und -Anbieter

1Dieser Umstand hat zur Entwicklung vieler neuer Technologien beigetragen, die inHTML 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-Client-Distributionen aus bestimmten Modulen/Plug-Ins bündeln und bestimmtenBenutzergruppen fertig zur Verfügung stellen. So erhält Benutzergruppe 1eine Anwendung, die aus Plug-In A und B besteht, während die Anwendungfür Benutzergruppe 2 aus Plug-In 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 O�ine-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 üb-liche Desktop-Anwendung zu bieten hat und zusätzlich die Kommunikationmit einem Server gestatten. Darüber hinaus sollen alle denkbaren Vorteileder Serveranbindung zur Geltung gebracht werden.

[KB06, S.8�], [Dau05b, S.1�], [Bea05], [Bur05]


2.2 Was ist die Eclipse Rich-Client-Platform?

�In short, Eclipse is an ideal technology for building rich clientapplications.�

Je� McA�er, Jean-Michel Lemieux [ML06, S.25]

Die Eclipse Rich-Client-Platform (RCP) ist eine erweiterbare Plattform fürTorsten Wittedie Entwicklung und den Einsatz von nativen Java-Anwendungen. Mit ihrerHilfe können schnell und einfach Rich-Client-Anwendungen erstellt werden.Die Eclipse RCP stellt bereits die Infrastruktur für die Entwicklung einerkompletten Rich-Client-Anwendung zur Verfügung. Beispielsweise könnenvorgefertigte Plug-Ins für einen Update-Mechanismus oder ein Hilfesystemverwendet werden. Das UI-Framework sorgt durch SWT (Standard WidgetToolkit) und JFace für native GUI-Elemente. Somit können sich Rich-Client-Entwickler ganz auf ihre Problem-Domäne konzentrieren. �The RCP part iseasy; 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-Anwen-dungen

• beschleunigt die Desktop-Entwicklung

• beinhaltet Equinox, ein auf dem OSGi-Standard basierendes Kompo-nenten-Framework

• durch das zugrunde liegende Plug-In-Modell können Anwendungsmerk-male über eine groÿe Produktpalette hinweg gemeinsam verwendet wer-den

• das Plug-In-Modell ermöglicht verteilte Entwicklung, auch über geo-gra�sch und organisatorisch getrennte Teams hinweg

• ist fähig, native GUI-Anwendungen auf einer Vielzahl von Betriebssys-temen einzusetzen, wie z.B. Windows, Linux oder Mac OSX

• integrierter Update-Mechanismus für den Einsatz von Desktop-Anwen-dungen von einem zentralen Server aus

• bietet O�enheit 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 seitdem 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 Version3.0 wurde die gesamte Plattform neu organisiert. Die bis dahin proprietäreAblaufumgebung wurde auf die standardisierte OSGi-Plattform umgestellt(Equinox2). Die IDE (Integrated Development Environment) wurde vomKern getrennt. Der Kern ist sehr klein und hat nur die Aufgabe, Plug-Inszum Ablauf zu bringen. Die Eclipse RCP besteht aus der Laufzeitumge-bung, SWT, JFace und der Generic Workbench (siehe Abschnitt 2.3). �Thisis a generic platform for running applications.� [ML06, S.5] Die Eclipse-IDEselbst ist nur noch eine spezi�sche Rich-Client-Anwendung auf Basis dieserRCP. Zur Zeit der Erstellung dieser Arbeit ist Eclipse in der Version 3.2.2verfü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 dieStandardisierung von Diensten, die auf lokalen Netzwerken und eingebette-ten Geräten zum Einsatz kommen sollen. OSGi-konforme Dienste können aufOSGi-konformen Servern ausgeführt werden. Der Ablaufkern von Eclipse ar-beitet als ein solcher OSGi-Server. Der Vorteil dieser Ablaufumgebung liegtunter anderem darin, dass Hot Plugging möglich ist, also der Austausch vonBundles im laufenden Betrieb. Bundles (zu deutsch �Bündel�) sind Java-Module; im Fall von Eclipse sind es die Plug-Ins. �A plug-in is a bundle.A bundle is a plug-in. They are the same thing.� [ML06, S.18] Im weite-ren Verlauf dieser Arbeit wird daher im OSGi-Kontext von Bundles und imEclipse-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 eineimmer gröÿere Rolle. Laut einer Umfrage von Evans Data [Eva] im Septem-ber 2006 ist die Akzeptanz der Eclipse Rich-Client-Platform gegenüber einer

2Equinox ist eine Implementierung der OSGi R4.0-Spezi�kation, eine Menge von Bund-les die verschiedene optionale OSGi-Dienste und die übrige Infrastruktur zur AusführungOSGi-basierter Systeme zur Verfügung stellt.


früheren Untersuchung aus dem Jahr 2005 um 130% gestiegen. 22% der rund400 Teilnehmer gaben an, dass sie bereits Rich-Client-Anwendungen basie-rend auf der Eclipse RCP erstellen. 69% gaben an, innerhalb der nächstensechs 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 ofplug-ins and a Runtime on which they run.�Je� McA�er, Jean-Michel Lemieux [ML06, S.13]

Eine Plattform unterscheidet sich von einer erweiterbaren Anwendung da-Torsten Wittedurch, dass die Plattform lediglich eine kleine Laufzeitumgebung zur Verfü-gung stellt, auf der die einzelnen Komponenten ablaufen, die die eigentlicheAnwendung ausmachen. Dadurch ist die Anwendung kein �fester Klotz�,sondern �exibel und einzelne Komponenten können leicht ausgetauscht wer-den (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 �zu-sammengesteckt� und auf der Laufzeitumgebung, der Eclipse RCP, ausge-führt.

Plug-Ins 25

Abbildung 2.2: Eclipse-Plattform [Dau05a, S.347]

An dieser Stelle sei ein kurzer Blick auf die Eclipse-Plattform in Abbil-dung 2.2 geworfen. Der dunkel gekennzeichnete Teil entspricht der Laufzeit-umgebung aus Abbildung 2.1(b). Er macht bis auf einige Komponenten derGeneric Workbench die Eclipse RCP-Minimaldistribution aus. Die GenericWorkbench stellt die Kernfunktionalität der Rich-Client-Platform dar. Sieverwaltet 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 Gra�k entspricht denPlug-Ins aus Abbildung 2.1(b) und enthält die Komponenten für die Eclipse-IDE. Diese Komponenten können auch für eigene Rich-Client-Anwendungenwiederverwendet werden (z.B. die Plug-Ins Help und Update).

Im Weiteren werden die Konzepte der einzelnen Bestandteile der Eclipse-Architektur vorgestellt.

[Dau05a], [ME05], [ER05]

2.3.1 Plug-Ins

Ein Plug-In bildet die kleinste Einheit in der Eclipse RCP-Architektur, die Kai Meyereine Funktion bereitstellt und getrennt von anderen Komponenten entwickeltund ausgeliefert werden kann. Für gewöhnlich wird ein kleines Werkzeug


durch ein Plug-In realisiert, während komplexe Werkzeuge aus mehrerenPlug-Ins bestehen. So ist z.B. fast die gesamte Funktionalität der EclipsePlattform in Plug-Ins enthalten. Nur der Kern, also die �Platform Runtime�,ist kein Plug-In. Die einzelnen Plug-Ins können selbstständig ihre Aufgabendurchführen oder andere Plug-Ins benutzen beziehungsweise deren Funktio-nalität erweitern. Die Anbindung eines Plug-Ins an den Rest des Systemswird über die Extension-Registry (siehe Abschnitt 2.3.3) geregelt.

Grundsätzlich besitzt jede RCP-Anwendung ein bestimmtes Plug-In, wel-ches als Anwendungs-Plug-In oder RCP-Plug-In bezeichnet wird. Die-ses Plug-In kon�guriert die RCP-Anwendung und identi�ziert die Anwen-dung 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 Frag-mente und Features vor.Fragmente sind im Gegensatz zu Plug-Ins keine eigenständigen Komponen-ten. So besitzen sie auch keine korrespondierende Repräsentation auf derOSGi-Plattform. Fragmente bieten lediglich weitere Funktionalitäten zu ei-nem existierenden Plug-In an. Dazu gehören unter anderem Sprachpaketeund ergänzende Funktionen für andere Betriebssysteme oder Datenbanken.Der Vorteil von Fragmenten ist, dass sie unabhängig vom Rest des Plug-Inserstellt und somit auch zu einem späteren Zeitpunkt ausgeliefert werden kön-nen.Ein Feature hingegen dient der Gruppierung von mehreren Plug-Ins, dieeine abgeschlossene Funktionsgruppe bilden. Darüber hinaus werden Featu-res für Update-Sites (siehe Abschnitt 2.5) benötigt. Eigenen Code besitzt einFeature 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

Wie das Zustandsdiagramm in Abbildung 2.3 auf Seite 28 zeigt, kann einTorsten WitteOSGi-Bundle im Verlauf seines Lebens bis zu sieben verschiedene Zuständeeinnehmen:

• Deployed: Ein Bundle ist �aufgeboten�, wenn es physikalisch auf derFestplatte vorhanden ist. Es kann vorkommen, dass ein Bundle le-diglich auf einem Server aufgeboten ist und nie auf der ausführendenMaschine vorhanden sein wird. Dieser Zustand wird formal nicht vomSystem repräsentiert. Daher ist er in Abbildung 2.3 nur als schwar-zer Punkt vermerkt. Dennoch wird der Begri� verwendet, um überBundles zu sprechen, die installiert werden könnten.

Lebenszyklus von Bundles/Plug-Ins 27

• Installed: Ein �installiertes� Bundle ist aufgeboten und im OSGi-Frame-work enthalten, so dass es ausgeführt werden kann. Im Fall von Eclipsewerden die Registerbeiträge (engl. registry contributions) installierterPlug-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 ebenfallsaufgelöst sein. Innerhalb der Eclipse-Laufzeitumgebung sind die Regi-sterbeiträge aufgelöster Plug-Ins in die Extension-Registry eingebun-den. Aufgelöste Bundles können vollständig betriebsbereit sein. Eskann aber vorkommen, dass so ein Bundle nie gestartet wird, da keinProgrammcode aus dem Bundle aufgerufen wird.

• Starting: Ein aufgelöstes Bundle wechselt in den aktiven Zustand in-dem es �startet�. Es bleibt in diesem Zustand bis die start()-Methodedes 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 Zustandindem sie �angehalten� werden. In diesem Zustand bleiben sie solangedie stop()-Methode des Bundle-Activator ausgeführt wird.

• Uninstalled: Bundles erreichen den Zustand �Deinstalliert� nur, wennsie bereits im installierten Zustand gewesen sind und deinstalliert wer-den. Sollte das Bundle sogar aktiv geworden sein, muss es erst angehal-ten werden, um deinstalliert werden zu können. Deinstallierte Bundlesbe�nden sich immer noch im System. Sie sind nicht von der Festplattegelöscht und beim nächsten Start der Plattform wieder verfügbar (In-stalled).

In dem Diagramm ist ebenfalls dargestellt, dass Bundles nur in den Zu-ständen �Installed� und �Resolved� aktualisiert werden können. Das bedeu-tet, dass bereits aktive Bundles gestoppt werden müssen, bevor eine Aktua-lisierung statt�nden kann. Ein aktualisiertes Bundle be�ndet sich nach demUpdate stets wieder im Zustand �Installed�. Dementsprechend müssen diebetre�enden Bundles neu aufgelöst werden, um sie wieder in die (laufende)Anwendung einzubinden. Weitere Informationen zu Updates in der EclipseRCP be�nden sich in Abschnitt 2.5.


Abbildung 2.3: Lebenszyklus von Bundles [ML06, S.460]

Für die Beobachtung und Steuerung, der in einer Eclipse RCP vorhandenenPlug-Ins eignet sich die OSGi-Konsole (Anhang B.2.2). Der Lebenslauf derEclipse-Workbench ist in [ML06, S.217�] dargestellt. Der Lebenslauf einerganzen Eclipse-Rich-Client-Anwendung ist in [ML06, S.475�] beschrieben.

[ML06, S.455, S.459f]

2.3.3 Extension-Points, Extensions und Extension-Registry

Ein Erweiterungspunkt (engl. extension point;Torsten Witteoft auch als �Steckdose� bezeichnet) de�niert eineSchnittstelle eines Plug-Ins. Diese Schnittstelle kannvon (anderen) Plug-Ins in Form von Erweiterungen(engl. extensions; bei obiger Metapher als �Stecker�bezeichnet) erfüllt werden. Das Erweiterungsregi-ster (engl. extension registry) von Eclipse verwaltetdiese Beziehungen zwischen Plug-Ins. Hier sindalle Erweiterungspunkte und Erweiterungen alleraufgelösten Plug-Ins registriert. Jede Eclipse RCP-Anwendung besitzt so ein Register. Die nebenstehendeAbbildung 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-Insliefern dann die benötigte Information zu diesen Erweiterungspunkten über

Extension-Points, Extensions und Extension-Registry 29

Erweiterungen. In welchen Relationen Plug-Ins zu Erweiterungen stehenkö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 Erweiterungenanbieten

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 Plug-Ins vorsehen

6. Eine einzige Erweiterung eines einzelnen Plug-Ins kann mehrere Call-back-Objekte erzeugen (siehe Abschnitt 2.4.5)

7. Ein Plug-In kann Erweiterungen zu seinen eigenen Erweiterungspunktenanbieten

Auf diese Weise entstehen Abhängigkeiten zwischen Plug-Ins, die einer Anbie-ter-Kunde-Beziehung gleichen (vgl. Vertragsmodell [Z+98, S.45]). Wie Ab-hängigkeiten zwischen Plug-Ins aufgebaut sein können, ist in Abschnitt 2.3.4beschrieben.

Die Vorteile von Erweiterungspunkten und Erweiterungen sind:

• Sie werden lediglich deklarativ angegeben. Dadurch können sie ge�l-tert, ü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 zuladen.

• Sie können zur Laufzeit hinzugefügt und entfernt werden.

• Der Mechanismus kann verwendet werden, um Code und/oder Datenbeizutragen.

Die Eclipse RCP bietet bereits einen Satz von Erweiterungspunkten an. Ei-nige davon sind in Abschnitt 2.4.4 aufgelistet. Zusätzlich können eigene(domänenspezi�sche) Erweiterungspunkte de�niert werden.In Abschnitt 2.4.5 wird ein tieferer Blick auf die Verwendung und das Zu-sammenspiel von Extension-Points, Extensions und Extension-Registry aufprogrammiertechnischer Ebene geworfen.

[ML06, S.21, S.392�], [ME05], [Bol03]


2.3.4 Plug-In-Abhängigkeiten

Plug-Ins ö�nen sich für andere Plug-Ins, indem sie Erweiterungspunkte an-Torsten Wittebieten und Teile ihrer Paketstruktur und somit die darin enthaltenen Klassenund Schnittstellen verö�entlichen. Dies hat den Vorteil, dass andere Plug-Insdiese Klassen und Schnittstellen verwenden können. Somit können Plug-Insüber die de�nierten Schnittstellen miteinander kommunizieren (wie in Ab-schnitt 2.4.5 zu sehen). Auch muss Logik nur einmal implementiert werden,da vorhandene (Hilfs-)Klassen wiederverwendet oder erweitert werden kön-nen.

(a) (b) (c)

Abbildung 2.4: Plug-In-Abhängigkeiten

Verwendet z.B. ein Plug-In B einen Erweiterungspunkt eines anderenPlug-Ins A oder importiert B die Paketstruktur von A, führt dies zu einerdirekten Abhängigkeit von B zu A (vgl. Abbildung 2.4(a)). D.h. ohne A kannB nicht den Zustand �Aufgelöst� erreichen (siehe Abschnitt 2.3.2). Plug-In A

kann dagegen auch ohne Plug-In B aktiv werden.

Ein Plug-In B kann aber auch zu einem anderen Plug-In A beitragen, ohnedavon 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.pop-upMenus des UI-Plug-Ins erlaubt zum Beispiel, Menüpunkte in Kontextmenüsanderer 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än-gig: B, weil es eine Klasse vom Typ IActionDelegate anbietet und denExtension-Point erweitert (beides kommt aus C), und A, weil es ebenfalls zurBenutzungsober�äche beiträgt. Somit können beide Plug-Ins ohne das drittePlug-In C nicht gestartet werden.Trotzdem sind A und B unabhängig voneinander. Falls sich nur B in der

Einleitung 31

Laufzeitumgebung be�ndet, verlaufen die Beiträge zu A ins Leere. Dies störtjedoch nicht. Sollte nur Plug-In A in der Umgebung vorhanden sein, dannwird dieses normal ausgeführt, ohne irgendwelche Beiträge von B. Schlieÿlichist B nicht verfügbar und A weiÿ nichts von B. Erst wenn beide Plug-Ins inder Laufzeitumgebung angemeldet sind, sind die Beiträge von B innerhalbvon A vorzu�nden.

Plug-Ins sind in der Lage, ihre eigenen Abhängigkeiten an Dritte wei-terzureichen. Benötigt Plug-In B z.B. Schnittstellen von Plug-In A, da essich selbst für Erweiterungen zur Verfügung stellt, für die diese Schnittstel-len benötigt werden, dann kann Plug-In B die Abhängigkeit zu Plug-In A anmögliche erweiternde Plug-Ins von B (hier C) durchreichen. Auf diese Weisesind Plug-Ins nur noch von dem Plug-In direkt abhängig, das sie erweitern.Die Struktur unterhalb des durchreichenden Plug-Ins muss dabei nicht be-kannt sein (vgl. Fassade [GHJV95, S.212]).C kann ohne A und ohne B nicht existieren. Da B ebenfalls ohne A nicht exi-stieren kann, reicht es aus, wenn C nur von B direkt abhängig ist. Indirektbleibt C von A 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 aufge- Torsten Wittebaut ist, wie Plug-Ins zueinander in Beziehung treten und wie die einzelnenFunktionen einer zu entwerfenden Anwendung auf Plug-Ins abgebildet wer-den sollten.Seit Eclipse-Version 3.1 erleichtert die Plug-In Development Environment

(PDE) die Entwicklung von Rich-Client-Anwendungen. PDE stellt einfachzu bedienende Werkzeuge wie Wizards und Formular-Editoren zur Verfü-gung. Diese unterstützen Entwickler beim Entwickeln, Testen, Beseitigenvon Fehlern (debugging), Aufbau und Einsatz von Eclipse Plug-Ins. Durchdie PDE ist es möglich, schnell und ohne viel Kenntnis der inneren Struktu-ren (XML-Tags usw.) eigene Rich-Client-Anwendungen zu erzeugen. So istes nur bedingt nötig, zu wissen, welche Daten in welche Datei gehören, oderdie erforderlichen XML-Dateien von Hand zu schreiben. Dennoch wird aneinigen Stellen in dieser Arbeit (wie hier) ein kurzer Blick in diese Dateiengeworfen, um Zusammenhänge zu verdeutlichen und so das Verständnis zuerleichtern.

[MG03]


2.4.1 Aufbau von Plug-Ins

Der Ausspruch �Everything in Eclipse is a plug-in.� [ML06, S.13] ist zwarKai Meyerkorrekt, kann allerdings auch irreführend sein. Ist nun alles in Eclipse eineinziges Plug-In oder sollte jede noch so kleine Funktion ein neues Plug-Inbilden? Diese Frage ist nicht ganz einfach zu beantworten, da es in Eclipsedurchaus die Möglichkeit gibt, dass ein Plug-In nur aus dem OSGi- und demPlug-In-Manifest (siehe Abschnitt 2.4.2) besteht. Aber es ist ebenso vor-stellbar, dass die gesamte Anwendung in einem einzigen Plug-In steckt. Hierist zu empfehlen, dass die Plug-Ins gemäÿ ihren fachlichen Aufgaben undin Übereinstimmung mit der Architektur erstellt werden. Ein Plug-In sollteeine 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 bestimmtenPlug-Ins lediglich dazu führen, dass in der laufenden Anwendung nur genaudiese Funktionalität fehlt. Dies ermöglicht es zusätzlich, ein Plug-In gezieltohne Seitene�ekte durch ein anderes zu ersetzen, welches die gleiche Aufgabeerfüllt, aber von einem anderen Anbieter sein kann.Als Vorbild für die Strukturierung der Plug-Ins können die Schichten einerSchichtenarchitektur dienen. Zudem erweist sich eine Unterteilung in Plug-Ins für die Geschäftslogik und Plug-Ins für die Benutzungsober�äche oft alssinnvoll.Fragmente und Features, die der besseren Strukturierung von Plug-Ins die-nen, werden in den Abschnitten 2.4.6 und 2.4.7 beschrieben.

[Dau05a, S.439�]

2.4.2 OSGi-Manifest, Plug-In-Manifest und Bundle-Activator

Die manifest.mf und die plugin.xml sind fester Bestandteil jedes Plug-Ins.Kai MeyerDiese beiden Dateien steuern die Einbettung der Plug-Ins in die Workbenchund 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 derOSGi-Umgebung. So sind hier u.a. folgende Daten zu einem Bundle festge-halten:

• der Name des Bundles

• ein �symbolischer� Name (als Id)

OSGi-Manifest, Plug-In-Manifest und Bundle-Activator 33

• die Versionsnummer

• der Bundle-Activator

• die benötigten Bundles

• die durchgereichten Bundles

• die verö�entlichten Pakete dieses Bundles

In älteren Versionen von Eclipse standen sämtliche Informationen nur in derplugin.xml, die auch als Plug-In-Manifest bezeichnet wird. Das OSGi-Manifest wurde daraus bei jedem Start neu generiert. Doch seit Eclipse3.1 enthält die in XML (eXtensible Markup Language) geschriebene Dateiplugin.xml nur die neu de�nierten Erweiterungspunkte, einen Verweis aufderen Schemata sowie die von einem Plug-In angesprochenen Erweiterungs-punkte.Zur Veranschaulichung, wie diese Dateien aussehen, folgen Auszüge ausder manifest.mf und der plugin.xml aus dem DienstplanRCP-Plug-In desDienstplaner-Projektes, welches in Kapitel 7 genauer erläutert wird.

Quellcode 2.1: manifest.mfManifest−Version: 1.0Bundle−ManifestVersion: 2Bundle−Name: DienstplanRCP Plug−inBundle−SymbolicName: DienstplanRCP; singleton:=trueBundle−Version: 1.0.0Bundle−Activator: dienstplanrcp.DienstplanerPluginBundle−Localization: pluginRequire−Bundle: org.eclipse.ui; visibility: =reexport,org. eclipse .core.runtime; visibility: =reexport,org. eclipse .update.con�gurator,org. eclipse .ui .forms; visibility: =reexport,org. eclipse .update.core; visibility: =reexport,org. eclipse .update.ui,DP_Server_Jar;visibility:=reexportEclipse−LazyStart: trueExport−Package: dienstplanrcp,dienstplanrcp.actions ,dienstplanrcp.comparator,dienstplanrcp.dnd,...dienstplanrcp.widgets.tree


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"/>

<extensionid="dienstplanerID"point="org.eclipse.core.runtime.applications">

<application><run

class="dienstplanrcp.Dienstplaner"></run>

</application></extension>

DerBundle-Activator bildet die Verbindung zwischen der OSGi-Plattform,den Bundles, der Workbench und den zu diesem Plug-In gehörenden Objek-ten. Der Activator ist entweder eine Unterklasse von org.eclipse.core.-

runtime.Plugin oder von org.eclipse.ui.plugin.AbstractUIPlugin,falls das Plug-In mit einer Benutzungsober�äche ausgestattet ist. Da esnur einen Bundle-Activator pro Plug-In gibt, wird er auch oft als Plug-In-Klasse bezeichnet. Zudem wird der Activator meist als Singleton (vgl. dazu[GHJV95, S.157]) implementiert. Zur Regulierung des Lebenszyklusses wer-den start(BundleContext context), stop(BundleContext context) so-wie getBundle() angeboten (siehe dazu auch Abschnitt 2.3.2). Des Weiterenbeinhaltet der Activator Methoden für die Ressourcen- und Benutzungso-ber�ächenverwaltung. Dazu gehören getPluginPreferences(), getState-Location(), getDialogsettings(), getWorkbench() und imageDescrip-

torFormPlugin().

[ML06, S.16�], [Dau05a, S.363]

2.4.3 Anwendungsklassen

Jede RCP-Anwendung muss mindestens eine Anwendungsklasse am Erwei-Torsten Witteterungspunkt org.eclipse.core.runtime.applications deklarieren. Üb-licherweise wird dies in dem Anwendungs-Plug-In der RCP-Anwendung ge-macht. Anwendungsklassen implementieren das IPlatformRunnable-Inter-

OSGi-Manifest, Plug-In-Manifest und Bundle-Activator 35

face und stellen eine run()-Methode bereit3. Das Interface dient dazu, seineImplementatoren gegenüber Eclipse als Eintrittspunkt der Anwendung zuidenti�zieren. Die run()-Methode ist dabei vergleichbar mit der main()-Methode einer einfachen Java-Anwendung.Es ist durchaus möglich, mehrere Eintrittspunkte zu spezi�zieren. Welcherder Eintrittspunkte beim Start von Eclipse aktiv werden soll, lässt sich übereine kleine Kon�gurationsdatei auÿerhalb des Plug-Ins nachträglich steuern.Eine minimale Anwendungsklasse mit einer typischen Implementierung derrun()-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 ein neues Display-Exemplar er-zeugt, welches die Bildschirmanzeige repräsentiert. Dann wird der Workbench-Advisor generiert, der für die Kon�guration der Benutzungsober�äche zu-ständig ist. Anschlieÿend wird die Workbench über PlatformUI.createAnd-RunWorkbench() gestartet. Wenn die Workbench wieder beendet wird, wirdderen Rückgabewert noch in das OSGi-konforme IPlatformRunnable-Proto-koll übersetzt.

[Dau05b, S.59�], [ML06, S.48f]

3In Eclipse 3.3 ist das Interface IPlatformRunnable als deprecated markiert. Statt-dessen wird das Interface IApplication mit einer start()-Methode verwendet.


2.4.4 Wichtige Erweiterungspunkte von Eclipse

Nun folgt ein Auszug aus der in [Dau05a, S.369�] aufgeführten Liste derKai Meyervon Eclipse bereitgestellten Erweiterungspunkte. Die hier vorgestellte Aus-wahl ist grundlegend für die Gestaltung der Benutzungsober�äche einer RCP-Anwendung. Zudem werden sie im weiteren Verlauf der Arbeit eingesetzt.Eine Beschreibung für das Anlegen von Extension-Points und deren Schema-tas be�ndet sich in [Dau05a] ab Seite 367.

• -.ui.actionSets - Ein actionSet fasst Aktionen (Actions) zu einerGruppe zusammen. Eine Aktion ist in Eclipse eine abstrakte Benut-zeraktion, die verschiedene Erscheinungsformen annehmen kann, wieMenüs, Menüpunkte oder Werkzeuge auf der Werkzeugleiste. Ein an-gelegtes ActionSet kann über diesen Extension-Point mit all seinen Ac-tions in ein von einem anderen Plug-In de�niertes Menü eingefügt wer-den.

• -.ui.activities - Über diesen Erweiterungspunkt kann die Benutzungs-ober�ä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 anzuzei-gen, die vom Benutzer in seinem aktuellen Aufgabenkontext benötigtwerden. Eine genauere Beschreibung ist in Abschnitt 6.3 zu �nden.

• -.ui.perspectives / -.ui.perspectiveExtension - Mit dem Erweite-rungspunkt perspectives können neue Perspektiven in die Workbencheingebracht werden. Eine Perspektive gibt die Anordnung von Edito-ren, Views und Menüs in der Workbench vor. Die in dem Extension-Point angegebene Klasse erzeugt das anfängliche Layout der Perspek-tive, wobei der Benutzer in der Lage ist die Anordnung der Views undEditoren innerhalb der Perspektive nach seinen Vorlieben individuellzu gestalten und neue Views hinzugefügen bzw. vorhandene entfer-nen kann. Mit perspectiveExtension lassen sich bereits vorhandenePerspektiven um weiteren Komponenten anreichern.

• -.ui.views / -.ui.viewActions - Mit views können neue Views indie Workbench eingeführt werden. Views gewähren in Eclipse einebestimmte Sicht auf die Arbeitsmaterialien. So können verschiedeneViews auf dem gleichen Material arbeiten, dabei aber verschiedenenAspekte in den Vordergrund stellen. Mit viewActions können neueAktionen (Menüpunkte und Werkzeuge [...]) in bereits bestehendeViews eingeführt werden.

• -.ui.editors / -.ui.editorActions - Die Extension-Points editors

Eine Beispiel-Erweiterung 37

und 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 wer- Torsten Witteden und das Zusammenspiel mit der Extension-Registry auf programmier-technischer Ebene funktioniert, folgt ein einfaches Beispiel, das häu�g in derLiteratur auftaucht. Das Beispiel zeigt, wie ein Plug-In eine Aktion hintereinem Menüpunkt innerhalb des Anwendungsmenüs unterbringen kann.

Das Eclipse-User-Interface-Plug-In org.eclipse.ui bietet den Erweite-rungspunkt org.eclipse.ui.actionSets an, um eine Menge von Menü-und Werkzeugleisteneinträgen zu der Benutzungsober�äche der Anwendunghinzuzufügen. Damit verp�ichtet sich das UI-Plug-In, Beiträge von Plug-Inszu dem ActionSet-Erweiterungspunkt zu verwalten und zu bearbeiten. Dieplugin.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 De�nition (.exsd-Datei)angegeben. Diese Datei enthält wiederum die eigentliche De�nition des Er-weiterungspunktes in Form eines XML-Schemas. U.a. wird spezi�ziert, wel-che Attribute angegeben werden müssen und welche optional sind. Dazugehören Pfad-Angaben zu Java-Klassen oder anderen Ressourcen (z.B. Bil-der) und Zeichenketten. Diese Zeichenketten können Repräsentationen fürboolesche 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 denfolgenden Eintrag enthalten, da sonst der benötigte Erweiterungspunkt unddas IActionDelegate-Interface nicht verfügbar sind.Require−Bundle: org.eclipse.ui;

Hier wird auch die Abhängigkeit von MyPlugin zu dem UI-Plug-In deutlich(vgl. Abschnitt 2.3.4).


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">

<actionid="org.myApplication.myPlugin.myActionId"class="org.myApplication.myPlugin.MyAction"icon="icons/myAction.gif"label="My Action"menubarPath="myMenu"/>

<actionid="..."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 einzelnenAktionen (action) wird jeweils eine Id (id), ein Menütext (label), ein gra-�sches Symbol (icon) und eine Klasse des Typs IActionDelegate (class)angegeben. Diese Klasse implementiert die durchzuführende Aktion. Zusätz-lich können noch weitere Attribute angegeben werden, z.B. an welcher Stelleder Menüeintrag im Menü auftauchen soll (menubarPath).

Das UI-Plug-In durchsucht das Erweiterungsregister der Eclipse RCP-Anwendung nach Beiträgen zu seinem Erweiterungspunkt. Dazu muss es imQuellcode auf das Erweiterungsregister der Plattform zugreifen, welches überfolgenden Aufruf zu erhalten ist:

IExtensionRegistry registry = Platform.getExtensionRegistry();

An diesem IExtensionRegistry-Exemplar kann mit einer der getConfigu-rationElementsFor()-Methoden das Register nach Erweiterungen für ein-zelne Erweiterungspunkte durchsucht werden. Genau das macht auch dasUI-Plug-In mit seinem Erweiterungspunkt. Die Suchergebnisse werden alsObjekte des Typs IConfigurationElement zurückgeliefert. Von diesen Ob-jekten sind die Attributwerte durch die getAttribute(String attrName)-

Fragmente 39

Methode in Form von String-Objekten erhältlich. Soll ein Exemplar ei-ner in der Erweiterung angegebenen Klasse erzeugt werden, kann dies mitdem Aufruf von createExecutableExtension(String propertyName) ge-schehen, wobei lediglich der Name des Attributes angegeben werden muss.Über die Methoden getExtension() oder getExtensionPoint() an demIExtensionRegistry-Exemplar sind auch Objektrepräsentationen der Er-weiterungen und Erweiterungspunkte selbst zu beziehen.Sind alle Erweiterungen zu einem Extension-Point gefunden und ausgewer-tet, können sie entsprechend behandelt werden. Das UI-Plug-In wird denMenütext und das Symbol jeder Aktion in der Benutzungsober�äche dar-stellen. Sobald der Benutzer mit der Maus auf so einen Menüeintrag klickt,wird ein Exemplar der zugehörigen Klasse erzeugt, auf ein IActionDelegate

gecastet und dessen run()-Methode aufgerufen.So ein Exemplar der konkreten IActionDelegate-Klasse (hier MyAction)wird auch als Callback-Objekt bezeichnet, da es von dem erweiterbarenPlug-In erzeugt und dann �zurückgerufen� wird (vgl. �Hollywood-Prinzip:Don't call us, we call you.�). Das Beispiel veranschaulicht auch den Lazy-Mechanismus von Eclipse. Das konkrete Objekt wird erst erzeugt, wenn eswirklich benötigt wird. In diesem Fall, wenn ein Benutzer auf den Menüein-trag klickt und die run()-Methode ausgeführt werden soll. Abbildung 2.5veranschaulicht den Aufbau und Ablauf von Erweiterungen nochmals gra-�sch.

Abbildung 2.5: Erweiterungen [ML06, S.21]

[ML06, S.21f, S.392�]

2.4.6 Fragmente

Fester Bestandteil jedes Fragmentes ist die fragment.xml. Diese XML- Kai MeyerDatei ist vom Aufbau her der plugin.xml sehr ähnlich. Die wichtigsten


Angaben in der fragment.xml sind die Identi�kation und die Version desPlug-Ins, auf das sich dieses Fragment bezieht. Eine eigene Plug-In-Klassedarf ein Fragment in keinem Fall besitzen, da ein Fragment auf der OSGi-Plattform keinen eigenen Namensraum bekommt, sondern vollständig mitdem zugehörigen Plug-In verschmilzt. Eine Beschreibung, wie ein Fragmentangelegt wird, ist in [Dau05a, S.439] zu �nden.

[Dau05a, S.439]

2.4.7 Features

In Eclipse besteht ein Feature aus dem Namen des Features, einer mög-Kai Meyerlichst eindeutigen Id, einer Angabe der Version, sowie dem Anbieter desFeatures (Feature Provider) und einer Liste der beinhalteten Plug-Ins. Fer-ner kann auch ein Branding-Plug-In und eine URL zur Update-Site (sieheAbschnitt 2.5) spezi�ziert werden. Das Branding-Plug-In enthält Daten fürdie Produktanpassung. Dazu gehören unter anderem Grs�ken und weiterge-hende Beschreibungen für das Feature. Für das Feature kann ebenso festge-legt werden, für welchen Betriebs- und Windowing-Systeme oder für welcheSprachen die enthaltenen Plug-Ins ausgelegt sind. Zusätzlich können einegenaue Beschreibung des Features sowie Urheberrechtsinformationen und Li-zenzbedingungen hinterlegt werden.Eine aus dem Dienstplaner-Projekt (siehe Kapitel 7) entliehene feature.xmlsieht 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"/>

Update-Sites und Updates 41

<import plugin="org.eclipse.core.runtime"/><import plugin="DienstplanRCP"/>

</requires><plugin

id="DP_BenutzerAu�ister"download−size="0"install −size="0"version="1.0.0"unpack="false"/>

<pluginid="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 Kai Meyerderen Plug-Ins in verschiedenen Versionen zum Download und zur Installa-tion anbietet. Zu Testzwecken kann eine Update-Site auch auf der lokalenFestplatte eingerichtet werden.Im wesentlichen besteht eine Update-Site aus einem Verzeichnis für die bein-halteten Features, einem für deren Plug-Ins, sowie eine site.xml. In dersite.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. Bevor eine Update-Site betriebsbereit ist, muss für die einzelnenFeatures erst der Build-Prozess angestoÿen werden. Die site.xml für dieUpdate-Site, die im Dienstplaner (siehe Kapitel 7) Verwendung �ndet, siehtwie folgt aus:


<?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 wer-den. Eine genauere Beschreibung dieses Vorgangs ist in [Dau05a, S.448�]aufgeführt.

Eclipse bietet bereits die Möglichkeit vorhandene Features zu aktualisie-ren oder neue Features zu installieren. Zwar lassen sich die zu den Featuresgehörenden Plug-Ins auch einfach in Eclipse hinein kopieren, aber wird derin Eclipse enthaltene Update-Manager verwendet, so ergeben sich einige Vor-teile. Zum einen zeigt der Manager alle Features und deren Plug-Ins an, dieauf den angegebenen Update-Sites vorhanden sind, wodurch die Auswahl desrichtigen Plug-Ins erleichtert wird. Zum anderen kann der Update-Managervor der Installation überprüfen, ob benötigte Plug-Ins vorhanden sind oderob Versionskon�ikte auftreten. Darüber hinaus ist es möglich, benötigte abernoch nicht auf der lokalen Festplatte vorhandene Plug-Ins mit einem Druckauf �Add required Plugins� zusammen mit dem gewünschten Plug-In her-unterzuladen. Selbstverständlich muss dafür die Update-Site diese Plug-Insanbietet. Der Update-Manager ist zudem in der Lage, die auf der Update-Site hinterlegte Lizenzbedingung dem Benutzer vorzulegen und zur Annahmeaufzufordern. In Eclipse ist der Update-Manager über Help → Software

Updates → Find and Install... zu erreichen.

Die Suche nach Updates kann manuell von dem Benutzer oder von derAnwendung automatisiert ausgelöst werden. Diese automatischen Updates

Abschlieÿende Bemerkungen 43

können beim Starten der Anwendung, beim Beenden oder zu bestimmtenZeitpunkten erfolgen. Es ist sogar denkbar, dass eine Administration überdas Netzwerk diesen Vorgang startet. Jede Variante birgt ihre eigenen Vor-und Nachteile. Wird beim Start nach Updates gesucht, so sind immer dieaktuellsten Versionen in Benutzung. Allerdings verlängert dieser Vorgangdie benötigte Zeit für das Starten. Auÿerdem kann es passieren, dass einNeustart der Anwendung erforderlich ist, sofern neue Versionen gefundenwurden. Wird erst beim Schlieÿen der Anwendung nach Updates gesucht,ist kein Neustart erforderlich. Jedoch wurde in diesem Fall die ganze Zeitmit einer alten � vielleicht fehlerhaften � Version gearbeitet. Des Weiterenwird in dieser Variante mehr Zeit für das Beenden des Programms benötigt.Tri�t der Benutzer die Entscheidung, wann nach Updates gesucht wird, soist dies oft e�zienter. Doch kann er bei Verwendung des Standard-Update-Managers auch auf Update-Sites zugreifen, die nicht gewünschte Inhalte an-bieten. Ebenso kann es vorkommen, dass der Benutzer nie oder nur sehrspärlich die Programmkomponenten aktualisiert.Die Initialisierung des Update-Vorgangs über das Netzwerk ist die programm-technisch anspruchsvollste. Denn es muss ein Weg gefunden werden, der er-laubt, Updates durchzuführen, ohne den angemeldeten Benutzer zu störenoder seine bereits gemachte, aber noch nicht gesicherte Arbeit zu verwerfen.Zusätzlich muss die Anwendung aktiv sein, wenn die Au�orderung zum Up-date 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 undTorsten Wittenur in Auszügen behandelt werden kann. Weitere interessante Gebiete wären:

Perspektiven, Views, Editoren, Wizards, Verwendung von SWT, JFace undForms, De�nition eigener Produkte, Internationalisierung, Verwaltung vonBenutzerpräferenzen usw. Als weiterführende Literatur ist hierfür [Dau05a;Dau05b; Dau06; ML06] zu empfehlen. Ebenso ist eine Trennung der Entwick-lungs- und der Zielplattform ratsam, um während der Entwicklung von An-wendungen auf Basis der Eclipse RCP beide Plattformen unabhängig vonein-ander kon�gurieren oder sogar austauschen zu können (siehe [ML06, S.30�]).Die in diesem Kapitel vorgestellten Begri�e und Konzepte sind notwendig,um die im theoretischen und praktischen Teil beschriebenen Konzepte undRealisierung von und für die Eclipse RCP nachvollziehen zu können.

44

Teil II

Theoretischer Teil

45

46 Teil 2 - Theorie

In diesem Teil soll geklärt werden, wie die Benutzer eines SoftwaresystemsKai Meyerautorisiert und die Auswirkungen der Autorisierung dem Benutzer kenntlichgemacht werden können.Dazu werden zunächst die grundsätzlichen Varianten für die gra�sche Re-präsentation von Interaktionsobjekten im Rahmen der Benutzerautorisierungbeschrieben. Es werden ihre Vor- und Nachteile geschildert und wie sich diejeweilige Variante auf das Verhalten eines Benutzers auswirken könnte. An-schlieÿend werden aktuelle Diskussionen zu diesem Thema zusammengefasstund ihre Ergebnisse dargelegt.In Kapitel 4 erfolgt eine Beschreibung bereits existierender Autorisierungs-mechanismen. Innerhalb der Beschreibung wird ebenfalls untersucht in wieweit sie Bezug auf die Benutzungsober�äche nehmen und ob sie sich für denEinsatz in einem Rich-Client eignen.Danach werden zwei grundlegende Konzepte vorgestellt, die die Anbindungder gra�schen Benutzungsober�äche bereits beinhalten, und unter welchenUmständen sie eingesetzt werden können.Als Abschluss dieses Teils werden Lösungen innerhalb der Eclipse RCP vor-gestellt.

Kapitel 3

Diskussionen

Dieses Kapitel greift unterschiedliche Diskussionen auf, deren Ergebnisse den Torsten Witteweiteren Verlauf dieser Arbeit beein�ussen. Zunächst wird der richtige Ein-satz von Interaktionsobjekten bei Benutzerautorisierung unter Aspekten derbenutzergerechten Softwaregestaltung diskutiert. Daraufhin wird nochmalsauf die Wichtigkeit von Gebrauchstauglichkeit gerade im Zusammenhang mitAutorisierung eingegangen. Im Anschluss wird der aktuelle Diskussionsstandüber Benutzerautorisierung innerhalb der Eclipse RCP ermittelt. Die dortvorgestellten Methoden und Lösungen werden später in Kapitel 6 näher be-trachtet.

3.1 Interaktionsobjekte bei der Benutzerauto-

risierung

Im Zusammenhang mit Benutzerautorisierung ist es für die Gebrauchstaug- Kai Meyer undTorsten Wittelichkeit besonders wichtig, die Benutzungsober�äche an die Berechtigungen

des aktuellen Benutzers anzupassen. In diesem Abschnitt werden die dafürmöglichen Darstellungsformen von Interaktionsobjekten und deren Verhalteninnerhalb der Ober�äche diskutiert. Dies geschieht ohne Berücksichtigungvon vorhandenen technischen Realisierungen und der Machbarkeit. Die inAbschnitt 1.2 geforderten Kriterien für benutzergerechte Softwaregestaltungwerden mit in die Diskussion einbezogen, um diese soweit wie möglich zuerfüllen.Das folgende einleitende Beispiel hat noch keinen Bezug zu Benutzerautori-sierung, illustriert aber schon die Wege und Schwierigkeiten der Ober�ächen-gestaltung: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

48 Teil 2 - Theorie

der Benutzer kein Feedback über den aktuellen Bearbeitungszustand einesDokumentes.Andererseits werden selten verwendete Menüpunkte aus Menüs weg geblen-det und tauchen erst nach längerem Aufenthalt innerhalb des Menüs wiederauf. Das vereinfacht die Benutzungsschnittstelle, da sie sich an die Gewohn-heiten des Benutzers anpasst, und reduziert die Fehlerhäu�gkeit. Die Aus-blendung einiger Menüpunkte kann aber auch zu �verzweifelten Suchaktio-nen� führen.

Im Folgenden werden kleine Szenarios gebildet, die verschiedene Varian-ten der Darstellung und des Verhaltens von Interaktionsobjekten bei nichtgewährtem Zugri� aufzeigen. Anhand dieser Szenarien werden die Konse-quenzen für den Benutzer und die Gebrauchstauglichkeit der Software dis-kutiert.

3.1.1 Meldungsfenster

Szenario 1. Ein Benutzer klickt mit der Maus auf eine Schalt�äche in derBenutzungsober�äche. Daraufhin erscheint ein Meldungsfenster mit demHinweis, dass der Benutzer für diese Aktion nicht berechtigt ist.

Das Anzeigen eines Meldungsfensters aufgrund nicht-autorisierten Zu-gri�s ist die einfachste und wohl am meisten verwendete Variante der Rück-meldung an den Benutzer. Für die Realisierung dieses Verhaltens wird ledig-lich ein Mechanismus benötigt, der die auftretenden Zugri�sverweigerungenan der Ober�äche darstellt. Alle Interaktionsobjekte der Anwendung bleibenvon den Benutzerberechtigungen unberührt.

Wie in dem Beispiel zu erkennen ist, erfährt der Benutzer erst nachdemer die Aktion ausgelöst hat, dass er keine Berechtigung dafür besitzt. Diesist ine�zient und behindert ihn in seinem Arbeits�uss, weil er nicht nur dieZeit vergeudet hat, auf die Schalt�äche zu klicken, sondern zusätzlich dasMeldungsfenster schlieÿen muss. Auÿerdem widerspricht dieses Systemver-halten seinen vorhandenen Erfahrungen aus anderen Anwendungen, in denener jede hinter einem anwählbaren Interaktionsobjekt liegende Aktion ausfüh-ren kann. Der Benutzer muss demzufolge mühsam durch Versuch und Irrtumerlernen, welche Aktionen er in welcher Rolle ausführen darf.Zur Verbesserung ist statt einem einfachen Meldungsfenster ein Log-in-Dialogdenkbar. Mit diesem kann sich der Benutzer unter einer anderen Rolle an-melden, die für die jeweilige Aktion berechtigt ist. Des Weiteren ist eineKombination 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 derBenutzungsober�äche. Daraufhin erscheint ein Log-in-Dialog, der darauf hin-weist, dass diese Aktion mit der aktuellen Benutzerkennung nicht durchge-führt werden darf. Über den Dialog ist der Benutzer in der Lage, sich (kurz-fristig) mit einer anderen Nutzerkennung anzumelden. Nach erfolgreichemLog-in wird die Aktion sofort ausgeführt.

Das hier vorgestellte Prinzip ist dem Meldungsfenster sehr ähnlich. Al-lerdings erlaubt es dem Benutzer seine Arbeit fortzusetzen, sofern er übereine weitere Nutzerkennung mit entsprechenden Berechtigungen verfügt. AlsKonsequenz muss der Nutzer wissen, mit welchem Benutzernamen und Pass-wort er das benötigte Recht bekommt. Je mehr Kennungen ein Benutzerbesitzt, desto schwieriger wird für ihn die richtige Auswahl. Zur Unterstüt-zung kann der Log-in-Dialog weitere Informationen zu den benötigten Rech-ten bzw. Rollen bereitstellen. Sollte der Benutzer nicht in der Lage sein,sich unter einer geeigneten Nutzerkennung anzumelden, ergibt sich dasselbeVerhalten wie bei einem einfachen Meldungsfenster. Insbesondere ist das derFall, wenn der Benutzer nur über eine Kennung verfügt. Zur Entlastung desBenutzers kann der Dialog nach einmaliger Eingabe von Benutzername undPasswort die passenden Log-in-Informationen beim erneuten Anstoÿ der sel-ben Aktion vorgeben. Auf diese Weise muss der Benutzer sich nicht mehr alleZugangsdaten merken und braucht nur noch zu bestätigen. Um auch nochdiese Zeit zu sparen und den Benutzer in seiner Arbeit nicht zu unterbre-chen, kann der Rollenwechsel im Hintergrund geschehen. Dadurch ist demBenutzer allerdings nicht mehr bewusst, dass ein Wechsel statt�ndet und inwelcher Rolle er gerade agiert.

3.1.3 Optische Kennzeichnung

Szenario 3. Ein Benutzer möchte eine Aktion auslösen. Die betre�endeSchalt�äche ist jedoch rot gekennzeichnet. Der Benutzer erkennt, dass ernicht berechtigt ist, diese Aktion durchzuführen. Daraufhin lässt er von sei-nem Vorhaben ab.

In den vorherigen Szenarien erfuhr der Benutzer erst nachdem er eineAktion angestoÿen hat, dass er keine Berechtigung dafür besitzt. Dem kanndurch eine optische Hervorhebung der betre�enden Interaktionsobjekte vor-gebeugt werden. Auf diese Weise wird der Benutzer nicht in seinem Arbeits-�uss unterbrochen und muss keine unnötigen Dialogfenster schlieÿen. Op-tische Hervorhebung können andere Text- oder Hintergrundfarben, Schrift-arten und -stile, unter- oder durchgestrichene Texte, andere Symbole, usw.

50 Teil 2 - Theorie

sein. Allerdings muss die Hervorhebung innerhalb der gesamten Anwendungkonsistent gehalten werden. Dadurch fällt es dem Benutzer leichter, die Be-deutung der Kennzeichnung zu erlernen. Sofern Standards vorhanden sind,ist deren Verwendung ebenfalls sinnvoll. Damit wird die Ober�äche für denBenutzer erwartungskonform. Auf der anderen Seite kann so eine Hervorhe-bung vieler Interaktionsobjekte zu einer überladenen Benutzungsober�ächefü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 gekenn-zeichnet, bleiben aber aktivierbar. Somit stellt sich die Frage: Was passiert,wenn der Benutzer nicht wie in dem Szenario beschrieben, von seinem Vor-haben ablässt und die Aktion dennoch anstöÿt? Hierbei kommen die bereitsin 3.1.1 und 3.1.2 genannten Verhaltensweisen mit ihren Konsequenzen inFrage. Zusätzlich gibt es die Möglichkeit, dass gar nichts passiert. Schlieÿlichsieht der Benutzer ja anhand der Kennzeichnung, dass er diese Aktion nichtdurchführen darf. Allerdings erwartet der Benutzer, dass etwas passiert. Fol-gerichtig sollte das Interaktionsobjekt gesperrt werden. Diese Variante wirdim nächsten Abschnitt diskutiert.

3.1.4 Sperren von Interaktionsobjekten

Szenario 4. Ein Benutzer möchte eine Aktion auslösen. Die betre�endeSchalt�äche ist jedoch gesperrt. Der Benutzer erkennt, dass er diese Aktionnicht ausführen kann. Daraufhin lässt er von seinem Vorhaben ab.

Gesperrte Interaktionsobjekte werden zwar in der Benutzungsober�ächedargestellt, können aber nicht ausgelöst werden. Die Sperrung von Interakti-onsobjekten geht meist einher mit einer optischen Kennzeichnung und einemanderen Verhalten als freigegebene Interaktionsobjekte:

• andere optische Darstellung (blasser Text, graues Symbol, . . . )

• keine Hervorhebung des Objektes, wenn sich der Mauszeiger darüberbe�ndet

• 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 ge-macht, wenn Aktionen im momentanen Systemzustand keinen Sinn machen.Z.B. das Sortieren einer Liste mit nur einem Eintrag oder das Speichern einesunveränderten Dokumentes. Durch einfache Aktionen, wie das Bearbeiten


(a) freigegeben (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 wiederfrei schalten.Werden nun gesperrte Interaktionsobjekte ebenfalls für Benutzerautorisie-rung verwendet, kann der Benutzer nicht mehr unterscheiden, weshalb er dieAktion gerade nicht ausführen kann.

�As you implement a role-based �lter, be careful not to disa-ble (gray out) user-inappropriate tasks if they are never possible,because this would only clutter the UI and also be misleading, asit might prompt users to think they could tweak some settings toenable the never-needed functions.� [Mol01, Part 2]

Um die Konsistenz der Benutzungsober�äche zu erhöhen und dem ebengeschilderten E�ekt entgegen zu wirken, können Interaktionsobjekte, die zurEingabe, Veränderung und Auswahl von Daten dienen (z.B. Text- und Aus-wahlfelder), durch rein anzeigende Objekte (z.B. Labels) ausgetauscht wer-den.

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 nichtsichtbar. Dies hat den Vorteil, dass der Benutzer nur die Interaktionsobjekte

52 Teil 2 - Theorie

vor�ndet, die er Verwenden darf und (im Idealfall) zur Erledigung seinerAufgaben benötigt. Dadurch ist die GUI auf die nötigen Funktionen redu-ziert und übersichtlicher. Die E�zienz der Handhabung der Anwendung wirderhöht. Die Anwendung ist zudem aufgabenangemessen und erwartungskon-form in Bezug auf gesperrte Interaktionsobjekte (siehe Abschnitt 3.1.4).

�And if a user never needs to do something, his or her UIwill be simpli�ed if it's never shown. Chances for errors are alsoreduced.� [Mol01, Part 2]

Da nur für gewährte Aktionen Interaktionsobjekte vorhanden sind, weiÿder Benutzer bei fehlenden Interaktionsobjekten nicht, ob er diese Aktionennicht durchführen darf, ob es sie überhaupt gibt oder ob er sie nur nicht �n-det. Aber bei vernünftiger Zuordnung von Rollen zu Aufgaben und Rechtensollte der Benutzer kein Bedürfnis nach weiteren Funktionen haben. Zumin-dest wenn die Anwendung über alle Funktionen verfügt, die zur Erledigungder Aufgabe nötig sind.

Das Verstecken von Interaktionsobjekten führt natürlich zu einem unter-schiedlichen Aussehen der Benutzungsober�äche, abhängig von der aktuellenRolle. Wenn der Benutzer Kenntnis über das Aussehen der Ober�äche untereiner anderen Rolle besitzt, vermisst der Benutzer unter Umständen Inter-aktionsobjekte, die nur in jener Rolle verfügbar sind. Auf der anderen Seiteverdeutlicht dies dem Benutzer, in welcher Rolle er gerade agiert.

3.1.6 Fazit

Welche Variante Verwendung �ndet, hängt sicherlich von den Anforderun-gen an das System, den Gewohnheiten der Benutzer und letztendlich dentechnischen Gegebenheiten ab. Kombinationen sind ebenfalls denkbar, umdie Nachteile der einzelnen Ansätze zu reduzieren. Allerdings schlieÿen sichMeldungsfenster und Login-Dialog mit Sperren und Verstecken aus.Die Entscheidung der gewählten Variante hängt ebenfalls davon ab, wie häu-�g die aktive Rolle im laufenden Betrieb gewechselt werden muss. Bei zu häu-�gen 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 vonInteraktionsobjekten ist ein gängiges Vorgehen und in den meisten Fällendem puren Kennzeichnen vorzuziehen. Für eine hohe Gebrauchstauglichkeitder Software ist das Verstecken von Interaktionsobjekten zu empfehlen.Mitunter macht es trotzdem Sinn, Interaktionsobjekte, auf die der Benutzer


nicht zugreifen darf, anzuzeigen und zu sperren oder mit einem Dialogfen-ster darauf hinzuweisen. Zum Beispiel in funktionell eingeschränkten Test-versionen von Software, die für Vermarktungszwecke eingesetzt werden. Derpotentielle Kunde soll selbst den Funktionsumfang und den Umgang mit derSoftware (in der Vollversion) ermitteln können.Wichtig ist in jedem Fall eine konsistente Ober�äche, bzw. eine einheitlicheDarstellungsform der Interaktionsobjekte.

3.2 Allgemeine Diskussion

Sämtliche Bereiche der Sicherheit, ob Verschlüsselung, Virenschutz oder Be- Kai Meyernutzerautorisierung, werden rege auf verschiedenen Sicherheitskonferenzendiskutiert. Auch zur Gestaltung der Benutzungsober�äche und dem groÿenBegri� Usability gibt es viele Bücher, Artikel und Berichte. Doch gibt eskaum Literatur, die sich mit den Auswirkungen der Benutzerautorisierungauf 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üsselungspro-grammen, aber die allgemeinen Aussagen über die Benutzungsober�äche las-sen sich auch auf Benutzerautorisierung anwenden. So wird in dem Textunter anderem folgendes erörtert:

�User errors cause or contribute to most computer securityfailures, 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 wirksameund benutzbare Sicherheit die bisherigen Vorgehensweisen für die Gestaltungder Benutzungsober�äche nicht ausreichen und fordern daher weitergehendeUsability-Standards. Um die Einhaltung der neuen Design-Regeln für die Be-nutzungsober�äche festzustellen, werden ebenfalls neue, noch zu erstellendeEvaluierungsmethoden benötigt.Laut den Untersuchungen, die für �Why Johnny Can't Encrypt� durchgeführtwurden, spielt für die Benutzer die Gebrauchstauglichkeit eine deutlich stär-kere Rolle als das Verlangen nach Sicherheit. Ist das verwendete Programmsehr sicher, aber unzureichend in der Handhabung, �ndet es bei den Benutzerwenig Akzeptanz oder es wird nach Wegen gesucht, die Sicherheitsmechanis-men zu umgehen.In Bezug auf die Benutzerautorisierung bedeutet dies, dass Benutzer, die

54 Teil 2 - Theorie

aufgrund von unzureichender Darstellung ihrer Berechtigungen von dem Pro-gramm frustriert sind, es entweder nicht benutzen oder einen Account ver-wenden, der möglichst viele Rechte beinhaltet. Dies kann im schlimmstenFall dazu führen, dass ein Account mit allen Rechten erstellt und dieser vonjedem Benutzer verwendet wird. Das macht die gesamte Benutzerautorisie-rung über�üssig.Bei der Administration der Rechte ist es ähnlich. Ist die Editierung derRechte zu kompliziert oder nur mit viel Aufwand durchzuführen, werden dieAdministratoren die Rechte nur sehr selten anpassen und daher u.U. denBenutzern 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 Benut-zerautorisierung verwenden. Ist das Schützen einer Komponente und dieAnbindung an die Benutzungsober�äche mit hohem Aufwand verbunden, sowerden die Programmierer das Framework nicht verwenden oder versuchenden Mechanismus zu umgehen.

Dass die Auswirkungen der Autorisierung auf die Benutzungsober�ächemit verschiedenen Mitteln umgesetzt werden können und dass dabei nocho�ene Fragen existieren, wurde bereits im vorherigen Abschnitt (3.1) erör-tert. Welche Bemühungen, die Autorisierung mit der Benutzungsober�ächezu verweben, speziell im Eclipse-Umfeld existieren, ist Gegenstand des näch-sten Abschnittes.

[WT99]

3.3 Aktueller Diskussionsstand über Autorisie-

rung in der Eclipse RCP

Das Verlangen nach rollenbasierter Autorisierung in Eclipse mit entsprechendTorsten Witteadaptiver GUI ist groÿ. Wer die Eclipse-Newsgroups in den letzten Jahrenverfolgt hat, �ndet viele Einträge zu diesem Thema. In Anhang A.1 sindeinige Einstiegspunkte in die Diskussionen aufgelistet. Aufgrund des wach-senden Interesses wurden auch auf der EclipseCon [Ecld] immer wiederVorträge über Authenti�zierung und Autorisierung gehalten. Die Eclipse-Con ist die gröÿte Konferenz zu Eclipse und �ndet seit 2004 jedes Jahr imMärz statt. Auf der mehrere Tage andauernden Veranstaltung werden dieneuesten 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 Fla-herty im Rahmen ihres Vortrags �Eclipse RCP Applications and EnterpriseSecurity� [RF06] darüber, was an der Eclipse RCP getan werden muss, umdie Entwicklung sicherer Unternehmensanwendungen einfacher zu gestalten.Unter den Anforderungen an sichere Anwendungen, wie Authenti�zierung,Netzwerksicherheit, Verschlüsselung und Single Sign-On, wird natürlich auchAutorisierung genannt. Während einige Techniken wie digitale Signaturenbereits von Eclipse 3.2 unterstützt werden, bleibt es bisher den Entwicklernüberlassen, vorhandene Java- und J2EE-Sicherheitstechniken wie �Sandbo-xing� und JAAS in die Rich-Client-Platform und die eigene Anwendung zuintegrieren. Rosenthal und Flaherty geben daher an, was die Eclipse RCP inder Zukunft auf diesem Gebiet leisten könnte. Dazu zählt ein Rahmenwerk,das basierend auf JAAS ein Plattform-Log-in bereit stellt. Eine bessere undeinfachere Integration von verschiedenen Java-Sicherheitsimplementierungenüber den Plug-In-Mechanismus ist ebenfalls ein Punkt auf ihrer Liste. Zu-dem ist eine �exible und erweiterbare Benutzungsschnittstelle denkbar, diemit dem zugrundeliegenden Sicherheitssystem in Wechselwirkung steht. DieDialoge und das Verhalten der Ober�äche werden von den jeweiligen Berech-tigungen beein�usst. Funktionen für die Verbreitung von Benutzungsrichtli-nien und zur Administration könnten in Zukunft zusätzlich von Eclipse bereitgestellt werden.Eine weitere Anforderung von Rosenthal und Flaherty an zukünftige Eclipse-Versionen ist die Code-Sicherheit auf Basis von J2SE-Berechtigungen. Bisherbesitzt Eclipse keine Einschränkungen auf die Ausführung von Code. Derverwendete FrameworkSecurityManager verletzt das �Minimum privilegies�-Prinzip (siehe Abschnitt 1.7), da er standardmäÿig alles zulässt. Plug-Insbrauchen nur in das plugins-Verzeichnis kopiert werden und der neue Codeist lau�ähig. Dieser Code kann unter Umständen private Daten lesen und ver-ändern. Ein Prototyp, der diese Code-Sicherheit in die Plattform integriertund mit einem J2SE SecurityManager ausgeführt wird, existiert bereits imRahmen 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 sichererUnternehmenssoftware zu ermöglichen. In den letzten drei Jahren hat er amWorkplace Managed Client gearbeitet. Matt Flaherty ist der Sicherheitsleiterdieses 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ürdie Filterung groÿer Benutzungsschnittstellen gedacht, kann dieser Erweite-

56 Teil 2 - Theorie

rungspunkt des Eclipse-UI-Plug-Ins auch für Autorisierungszwecke eingesetztwerden. Sie selbst sagt jedoch, dass diese Vorgehensweise keine Sicherheitbietet: �Very poor substitute for real security � throw food at me for evensuggesting this� [Hor05b, Folie 22]. Weshalb, wird in Abschnitt 6.3 erläutert.Kimberly Horne arbeitet seit 2003 im IBM Ottawa Team und ist seit dem3.0 Release Mitglied des Eclipse Platform UI Teams. Dort ist sie u.a. für dasCapabilities-Framework und dynamische Plug-Ins verantwortlich.

Bereits in seinem Buch [Dau05b] aus dem Jahr 2005 stellt Berthold Daumzur Demonstration des Plug-In-Mechanismus einen starren Ansatz der Be-nutzerautorisierung vor. Er verwendet in seiner Beispielanwendung rollen-abhängige Plug-Ins. Der vorhandene Plug-In-Mechanismus von Eclipse wirdso ausgenutzt, dass jedem Benutzer nur die Plug-Ins zur Verfügung stehen,die er in seiner Rolle verwenden darf. Die Realisierung dieses Ansatzes wirdin Abschnitt 6.1 ausführlicher vorgestellt.Die Eclipse-IDE bietet so etwas ähnliches bereits über die Startkon�gurationzum Testen von Plug-Ins bzw. Rich-Client-Anwendungen. Dort kann aus-gewählt werden, mit welchen Plug-Ins die Rich-Client-Anwendung oder dieTestumgebung gestartet werden soll (siehe Anhang B.2.1).Berthold Daum hat noch weitere Bücher über Eclipse und die Eclipse RCPverfasst. 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ügunggestellt. Dabei handelt es sich um ein Rahmenwerk für die Eclipse RCP, dasden Java Authentication and Authorization Service nutzt, um den Benutzerbeim Starten der Anwendung zu authenti�zieren. Aufgrund seiner Identitätwerden dem Benutzer dann nur bestimmte Plug-Ins angeboten. [Eclb]Im März 2007 hielt Neil Bartlett den Vortrag �Secure Desktop Applicationswith Eclipse RCP� [Bar07] auf der EclipseCon. Das Abstract dazu lautetwie folgt:

�Eclipse RCP is rapidly gaining popularity as a frameworkfor corporate desktop applications. These applications are oftendeveloped bespoke or in-house, and are the gateways to criticalbusiness functions. As such they must be secured: we must knowexactly who each user is (i.e. they must be authenticated), and wemust prevent users from performing tasks that they do not havethe authority to perform (i.e. they must have authorization).Eclipse RCP is an excellent base on which to build secure applica-tions. Through plugins and extensions, we can o�er a far cleaner


experience for users by simply hiding the functions for which theyare not authorized, instead of constantly showing �Access Denied�errors. Using OSGi we can even dynamically grant or deny ac-cess 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 mustbe added on. In this talk we discuss the principle techniques requi-red; what the most common business requirements are for secu-rity, and how to achieve them; and how to integrate with existingtechnologies such as JAAS or Kerberos.� [Bar07]

In dem Vortrag spricht er also an, dass auf dem Gebiet der Authenti�zierungund Autorisierung in Eclipse noch einiges getan werden muss, damit allge-meine Sicherheitsanforderungen auf Basis der vorhandenen Techniken erfülltwerden können. Was heute allerdings schon getan werden kann und was auchin 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 Benut-zerrechte auf einem (zentralen) Server und somit beim Administratorbleibt. Denn nur der Administrator weiÿ, wozu welcher Benutzer au-torisiert ist.

2. �If they can't do it... don't show it to them!�Damit bezieht sich Neil Bartlett auf die Gebrauchstauglichkeit vonSoftware. 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 in-stallierten Erweiterungen zu erhalten, muss überwacht werden, welchePlug-Ins den Zustand Aufgelöst erreichen dürfen (siehe Abschnitt 2.3.2).Wenn die benötigte Information zu dieser Überwachung von einem Ser-ver stammt, wie in der ersten Lektion verlangt, dann wird durch dieseVorgehensweise die zweite Lektion ebenfalls erfüllt.

Allerdings bleiben einige Kritikpunkte:Zum einen muss eine Verbindung zum Server bestehen, was den Netzwerk-verkehr erhöht. Auf der anderen Seite steht die Problematik der Granu-larität. Durch Überwachung der aufzulösenden Plug-Ins werden automa-tisch alle Erweiterungen der einzelnen Plug-Ins kontrolliert. Ein Benutzerkann also nicht für einzelne Erweiterungen eines Plug-Ins autorisiert sein.Einer der Vorschläge von Neil Bartlett zur Verfeinerung dieses �Alles oder

58 Teil 2 - Theorie

Nichts�-Prinzips ist die Filterung der Ergebnisse aus der Extension-Registry(registry.getExtension*() und registry.getConfigurationElements-

For*()). Auch die deklarative Angabe von Rollen in Erweiterungspunktenwäre denkbar:

<extension point="..." role="admin">

Zur Autorisierung auf deklarativen Erweiterungen stuft Bartlett den JavaAuthentication and Authorization Service als ungeeignet ein, da dieser Dienstnur Code vor unbefugter Ausführung schützt. Bartlett sieht einen weiterenNachteil bei der Verwendung von JAAS. Ob ein Benutzer zu einer Aktionberechtigt ist oder nicht, entscheidet sich erst, wenn die Aktion durchgeführtwird (siehe Abschnitt 4.3.3).Neil Bartlett ist ein Java-Entwickler und Berater, der sich insbesondere aufdie Nutzung von Eclipse RCP und OSGi innerhalb von Unternehmen spezia-lisiert hat. Er hat bereits einige Kreditinstitute bei der Einführung der RCPunterstützt und predigt die Verwendung der RCP- und OSGi-Technologiebei der client- und serverseitigen Entwicklung.

In den eingangs erwähnten Diskussionen in den Eclipse-Newsgroups wer-den überwiegend Kimberly Hornes Activities und Neil Bartletts Eclipse-JAAS diskutiert. Es werden sogar Versuche unternommen, die beiden An-sätze miteinander zu verknüpfen.Je� McA�er ist Leiter der Eclipse RCP und Equinox Teams und seit Anfangan in Eclipse einbezogen. Er ist einer der Architekten der Eclipse-Plattformund Koautor des Buches �eclipse Rich Client Platform� (siehe Literaturver-zeichnis [ML06]).McA�er bevorzugt die Deaktivierung von Plug-Ins vor der Nutzung von Ac-tivities und äuÿert sich zu dem Thema wie folgt:

�Activities are weak and I don't really see going further withthem. Fundamentally they are a UI �ltering mechanism to controlwhat is on the glass. There are many other aspects to the genericnotion of capabilities than just what the user sees. For example,there may be some set of services registered that either show upin the UI (through some third party mechanism) or just do workin the background (e.g., a builder). If the user is not authorizedfor this function, activities are not going to help.Personally I am a fan of simply disabling plugins that the user isnot authorize to use. The problem is e�ectively one of granularity.What if you want the user to be able to use part of a plugin andyou are not the plugin producer? Is this a real usecase? Are thereany simplifying assumptions we can make to help sort out the


presentation?To answer these, imagine you can change anything in Eclipse.What would need to be changed (and how) to get the right securitymodel in place and address these issues?� [McA05]

In den folgenden Kapiteln werden vorerst von Eclipse unabhängige, grund-legende und bewährte Konzepte und Lösungen für Benutzerautorisierungvorgestellt. Dabei wird untersucht, in wie weit sie in einer Eclipse RCP-Anwendung verwendet werden können. Um im Anschluss der Au�orderungvon McA�er nachzukommen, greifen die Autoren dieser Arbeit den einfachenAnsatz der Plug-In-(De-)Aktivierung auf. Auÿerdem stellen sie ein Konzeptvor, 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ätzewird in Kapitel 6 ein Blick geworfen.

Kapitel 4

Bestehende Konzepte und

Lösungen

Die folgenden Abschnitte stellen einige der bekanntesten Konzepte und Pro-Kai Meyerdukte für die Authenti�zierung 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 genaue-rer Blick auf die Funktionsweise und die einzelnen Komponenten geworfenwird. Danach werden vorhandene Erweiterungen, Kooperationsmöglichkei-ten 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 geeig-net ist für den Einsatz innerhalb eines Rich-Clients und wie die GUI in derSpezi�kation berücksichtigt wurde.

4.1 Role Based Access Control (RBAC)

Die Idee, einzelnen Benutzern aufgrund ihrer Rolle Berechtigungen zuzu-Kai Meyerweisen, gibt es schon seit über 25 Jahren. Doch erst 1992 wurde dieser

60

Role Based Access Control (RBAC) 61

Gedanke von D.F Farraiolo und D.R. Kuhn zu einem akzeptierten Stan-dard namens Role Based Access Control (RBAC) aufbereitet. RBACspezi�ziert ein �exibles und einfach zu handhabendes Konzept für die Au-torisierung. Die überarbeitete Version von RBAC wurde im November 2001von dem InterNational Committee for Information Technology

Standards (INCITS) als �INCITS BSR 359� verö�entlicht.Wie dem Namen Role Based Access Control, also Rollen-basierte Zugri�skon-trolle, zu entnehmen ist, �ndet die Autorisierung aufgrund der Rollen einesBenutzers und den mit ihnen verbunden Rechten statt. Rollen in einem Be-trieb oder einer Organisation bleiben über einen langen Zeitraum konstant,während die registrierten Benutzer und ihre Verantwortlichkeiten häu�genÄnderungen unterliegen. So ist es bei einer Versetzung oder Neueinstellungnur nötig dieser Person eine andere Rolle zuzuweisen. Dabei kann die Struk-tur der Rollen und die Zuordnung der Rechte zu den Rollen unangetastetbleiben.

Das RBAC Referenz Modell de�niert vier Komponenten. Dazu gehörenCore RBAC, Hierarchical RBAC, Static Seperation of Duty undDynamic Seperation of Duty. In Core RBAC sind die grundlegendenElemente enthalten. Somit ist Core RBAC für jedes Role Based Access Con-trol System erforderlich, während die anderen Komponenten unabhängig voneinander sind und einzeln implementiert werden können. In den folgendenAbschnitten werden die Aufgabenbereiche der einzelnen Komponenten nähererläutert.

4.1.1 Core RBAC

Im RBAC Modell werden den einzelnen Benutzern verschiedene Rollen zuge-wiesen und die Berechtigungen mit den Rollen verknüpft. Dafür beinhaltetCore RBAC fünf Hauptelemente: Benutzer (USER), Rollen (ROLES), Ob-jekte (OBS), Operationen (OPS) und Genehmigungen (PRMS). Zusätzlichenthält die Spezi�kation Sitzungen (SESSIONS). Die Beziehungen zwischendiesen Elementen ist in Abbildung 4.1 dargestellt.

• Das Grundkonzept von RBAC sieht Benutzer als natürliche Personen,was mit der De�nition des Begri�es 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

62 Teil 2 - Theorie

Abbildung 4.1: Core RBAC Elemente [Ame03, S.8]

vorgesehenen Rechte und Verp�ichtungen 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 zugeord-net sind.

Was genau eine Operation oder ein Objekt ist, hängt von dem zugrundeliegenden System ab. Innerhalb einer relationalen Datenbank können dieOperationen 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 an-zupassen, wird in vielen RBAC Anwendungen Hierarchical RBAC ver-wendet. Die Rollenhierarchie de�niert eine Vererbungsbeziehung zwischen

Role Based Access Control (RBAC) 63

Rollen. So vererbt eine �Vater�-Rolle alle ihre Rechte an ihre �Kinder�, diedann eigene Berechtigungen hinzufügen können. Hierarchical RBAC unter-stützt Mehrfachvererbung, um eine beliebige partielle Ordnung zu erzeugen.Wird lediglich Einfachvererbung verwendet, ist die Struktur der Rollen eineinfacher Baum, in dem jede Rolle zwar mehrere Kinder haben kann, abernur eine einzige Vaterrolle.

4.1.3 Static Seperation of Duty (SSD)

Mit Static Seperation of Duty (SSD) also der statischen Trennung vonVerp�ichtungen ist RBAC in der Lage, die Zuordnungen von Benutzern zuRollen einzuschränken.Static Seperation of Duty erlaubt einem Administrator SSD-Richtlinien zude�nieren, so dass sich bestimmte Rollen gegenseitig ausschlieÿen. Auf dieseWeise verhindert SSD, dass ein Benutzer zwei sich gegenseitig ausschlieÿendeRollen bekommt.Die Interessenpolitik einer Firma kann es vorsehen, dass ein Benutzer mitRolle A nicht der Rolle B angehören darf. So wird sichergestellt, dass anwichtigen Entscheidungen mehrere Personen beteiligt sind, um Risiken bes-ser erkennen und abschätzen zu können (Vier-Augen-Prinzip). Zum Beispielkann es in einem Betrieb verlangt werden, dass Verträge, die von einer Per-son erstellt werden, vor der Unterzeichnung von einem anderen Mitarbeiterüberprüft werden.Wird zusätzlich zu SSD auch Hierarchical RBAC verwendet, kann es zu In-konsequenzen bezüglich der Vererbungsstruktur kommen. Schlieÿen sich zweiRollen gegenseitig aus, muss zusätzlich auf die Rollen geachtet werden, dievon diesen Rollen erben. Um dies zu bewerkstelligen wurde die Rollenhier-archie um die Vererbung der SSD-Bedingungen erweitert (siehe Abbildung4.3).

Abbildung 4.3: SSD Elemente [Ame03, S.13]

64 Teil 2 - Theorie

4.1.4 Dynamic Seperation of Duty (DSD)

Ebenso wie Static Seperation of Duty reduziert auch Dynamic Seperationof Duty (DSD) die für einen Benutzer verfügbaren Berechtigungen. DerUnterschied liegt im Kontext, in dem die einzelnen Regeln greifen. WährendSSD die Menge der zuweisbaren Rechte im gesamten System beschränkt, istDSD verantwortlich für die Reduzierung der Rechte zur Laufzeit innerhalbeiner 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 Interessenskon�ikte verursa-chen. Nur wenn der Benutzer innerhalb einer Sitzung verschiedenen Rollenaktiviert, kommt es zu diesen Kon�ikten. Hier greift DSD ein. Versucht einBenutzer sich mit einer weiteren Rolle anzumelden, die in Kon�ikt mit einerbereits aktiven Rolle steht, wird er von RBAC aufgefordert, die aktive Rollezu beenden, bevor die neue aktiviert werden kann.Somit unterstützt DSD das �Minimum Privilegies�-Prinzip, welches bereitsin Abschnitt 1.7 erklärt wurde.

4.1.5 Einordnung

RBAC beschreibt eine einfaches und leicht zu administrierendes Vorgehenum Benutzerautorisierung durchzuführen. Durch die Verwendung von Rol-len und den dazu de�nierbaren Bedingungen kann RBAC eine groÿe Band-breite an Sicherheitsrichtlinien umsetzen. Da beim Anmelden eines Benutzersseine Berechtigungen ermittelt werden und RBAC keine Annahmen darübermacht, was geschützt werden soll, kann auch die Benutzungsober�äche ent-sprechend angepasst werden. Der Einsatz in einer Rich-Client-Architekturist ebenfalls denkbar. Es müssen lediglich die Rollenzuordnungen auf demRich-Client verfügbar sein und bei einer bestehenden Serververbindung ak-tualisiert 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 Torsten WitteVerzeichnisdienste an.

Ein Verzeichnis ist eine Au�istung von Informationen über Objekte ineiner gewissen Ordnung. Zu jedem Objekt können Detailinformationen ab-gefragt werden.Beispiel: In einem Telefonbuch sind die Objekte die Personen, die Ordnungist alphabetisch und die Detailinformationen sind Adresse und Telefonnum-mer.Neben solchen Kontaktdaten kann ein Verzeichnis auch Passwörter, privateSchlüssel, Zerti�kate, Richtlinien und Zugri�skontrolllisten (Access ControlLists, ACLs) enthalten.

Ein Verzeichnisdienst wird eingesetzt, um die Daten zentral zu haltenund redundante Informationen an verschiedenen Stellen zu vermeiden. Dabeiliegen die Daten in einem einheitlichen Schema vor und sind unter einer ein-heitlichen Schnittstelle erreichbar. Eine Zugri�skontrolle auf die enthaltenenInformationen �ndet ebenfalls statt.Verzeichnisdienste sind mehr für das schnelle Au�nden und Auslesen aufInformationen ausgelegt als auf das Schreiben neuer Informationen.Beispiel: Ein Telefonbuch wird nur jährlich aufgelegt, eine Passwort-Daten-bank 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 Verzeichnisstruk-tur vor. LDAP basiert auf dem X.500-Standard, der 1988 von der ISOund der International Telecommunication Union (ITU) gescha�enwurde. Die Kommunikation mit der Verzeichnisstruktur �ndet über das Di-rectory Access Protocol (DAP) statt. Bei X.500 ist das DAP sehr umfang-reich und setzt auf den vollständigen ISO/OSI-Stack auf ([ISO94, S.34],[Z+98, S.346f]). Dadurch ist das Protokoll schwer zu implementieren. Ausdiesem Grund wurde 1995 an der Universität von Michigan LDAP entwickelt.LDAP bietet eine leichtgewichtigere Version des Directory Access Protocolfür den Zugri� auf X.500 Verzeichnisse über TCP/IP. Aufgrund seiner Ein-fachheit, Flexibilität und Vielseitigkeit ist LDAP zum de facto Standard fürdie Verwaltung von Benutzerinformationen geworden. LDAP ist ein o�enerStandard und hersteller- und plattformunabhängig. Die enthaltenen Infor-mationen werden durch Authenti�zierung, Zugri�skontrollen (über ACLs)und Verschlüsselung geschützt. Eine bekannte OpenSource-Umsetzung von

66 Teil 2 - Theorie

LDAP ist OpenLDAP [Ope]. OpenLDAP wird standardmäÿig bei Linux undBSD-Betriebssystemen verwendet und kann mit den meisten UNIX-Systemengenutzt werden.

4.2.1 Einordnung

Da in Java über das Java Naming and Directory Interface (JNDI) Kontaktmit einem LDAP-Server aufgenommen werden kann, ist die Verwendung vonLDAP auch innerhalb eines Eclipse-Rich-Clients möglich. Damit ist ein ge-eigneter Ort für die Authenti�zierungs- und Autorisierungsdaten innerhalbeines Netzwerks gefunden.

[SNL06, S.73�], [Mit], [BG03]

4.3 Java Authentication and Authorization Ser-

vice (JAAS)

Ursprünglich bietet Java bezugsquellen-basierte Zugri�skontrollen an (code-Torsten Wittesource-based access controls), d.h. Zugri�skontrollen die darauf basieren,von wo der Code abstammt und wer den Code signiert hat. Der JavaAuthentication and Authorization Service (JAAS) erweitert die Java-Sicherheitsarchitektur um die Fähigkeit, Zugri�skontrollen davon abhängigzu machen, wer den Code ausführt. Seit Java Version 1.4 ist JAAS fest in dasJava 2 Standard Edition Development Kit (J2SDK) integriert. Es handeltsich dabei um eine reine Java-Implementierung.

JAAS kann für zwei Anwendungsbereiche eingesetzt werden:

1. für die Authenti�zierung von Benutzern, um zuverlässig und sicher zubestimmen, wer gerade Java-Code ausführt

2. für die Autorisierung von Benutzern, um sicherzustellen, dass Benutzerdie für ihre Handlungen erforderlichen Genehmigungen besitzen

[Jav07c], [Jav07d]

4.3.1 Authenti�zierung mit JAAS

Da JAAS modular aufgebaut ist, bleiben Anwendungen unabhängig von derdarunterliegenden Authenti�zierungs-Technologie. Auf diese Weise können

Java Authentication and Authorization Service (JAAS) 67

stets neue oder verbesserte Technologien verwendet werden, ohne dass die zu-gehörige Anwendung angepasst werden muss. Es ist sogar möglich, mehrereAuthenti�zierungs-Module aufzuschichten und ein anwendungsübergreifen-des Single Sign-On (siehe Abschnitt 1.4) zu realisieren.

Die Authenti�zierung eines Benutzers spielt sich bei JAAS in einem Log-

inContext ab. Für die korrekte Authenti�zierung innerhalb dieses Kontextesist das Login-Modul, eine Implementierung des Interfaces javax.security.-auth.spi.LoginModule, verantwortlich. Vorgefertigte Login-Module fürUnix, Windows, JNDI (Java Naming and Directory Interface) und Kerberossind in Java bereits enthalten.Login-Module kommunizieren mit Hilfe von Callbacks und einem Callback-

Handlermit dem Benutzer, um z.B. dessen Namen und Passwort abzufragen.Dadurch bleiben Login-Module unabhängig von der eingesetzten Benutzerin-teraktion. Da Login-Module lediglich in einer Kon�gurationsdatei angegebenwerden, sind sie leicht austauschbar. Hier ein Beispiel für den Inhalt so einerDatei:

LoginContextName {authorizationExample.MyLoginModule required;

};

Ein authenti�zierter Benutzer oder Dienst wird in JAAS von einem Sub-

ject repräsentiert. Bei erfolgreicher Authenti�zierung eines Benutzers bin-det das Login-Modul ein oder mehrere Principals an dessen Subject. JedesPrincipal repräsentiert eine Identität des Benutzers. Dabei ist eine einfacheNamens- oder Benutzerkennung (Id) denkbar, wodurch Subjects voneinan-der unterschieden werden können. Die Zuweisung von Gruppen oder Rollenist ebenfalls über Principals möglich. Anhand dieser Kennungen kann dannspäter ermittelt werden, ob der Benutzer die Erlaubnis besitzt, bestimmteCode-Abschnitte auszuführen.Das Sequenzdiagramm in Abbildung 4.5 auf Seite 68 veranschaulicht denAuthenti�zierungsvorgang gra�sch. Ein ausführliches Beispiel zur Authenti-�zierung 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. DieseRichtlinien-Dateien sind einfache ASCII-Dateien und können mit Hilfe des

68 Teil 2 - Theorie

Abbildung 4.5: Authenti�zierung mit JAAS - Sequenzdiagramm


Policy-Tools von Java erstellt und bearbeitet werden (siehe Anhang B.3).Eine Policy-Datei enthält z.B. folgende Einträge:

grantPrincipal authorizationExample.principals.MyNamePrincipal "joe"{permission java. io .FilePermission "foo.txt", "read, write";permission java. util .PropertyPermission "java.home", "read";permission authorizationExample.permissions.MyPermission "permissionForMyAction1";

};

grantPrincipal authorizationExample.principals.MyNamePrincipal "bob"Principal authorizationExample.principals.MyRolePrincipal "role1"{//Nur ein Subject, das ALLE o.g. Principals besitzt , darf die jew. Action ausführenpermission authorizationExample.permissions.MyPermission "permissionForMyAction1";permission authorizationExample.permissions.MyPermission "permissionForMyAction2";

};

In diesem Beispiel hat ein Subject, dass das Principal MyNamePrincipal

aus dem Paket authorizationExample.principals mit dem Namen �joe�besitzt, folgende Berechtigungen:

• Lesen und Schreiben der Datei foo.txt

• Lesen der Property-Variable java.home

• Ausführen von MyAction1, d.h. dem Code-Block, der durch ein Exem-plar der Klasse MyPermission mit dem Attributwert �permissionFor-MyAction1� geschützt ist (siehe unten)

Das Beispiel zeigt ebenfalls, dass Java bereits einige Permissions zur Verfü-gung stellt und diese auch überprüft. Zusätzlich können eigene Permissionsund Principals angelegt werden. Die Überprüfung der Permissions ge-schieht im Code über eine der zahlreichen check...-Methoden des Security-Managers der Java-Anwendung. Besitzt das System nicht die benötigte Be-rechtigung, wird eine SecurityException geworfen.

Der Code, der nur von bestimmten Subjects ausgeführt werden darf, be-�ndet sich in der run()-Methode einer java.security.PrivilegedActionoder java.security.PrivilegedExceptionAction. Diese Schnittstellen wer-den benötigt, um den Code als geschützte Aktion zu kapseln und vom Sy-stem �im Auftrag eines Subjects� ausführen zu lassen. Dazu später mehr.Das folgende Codebeispiel zeigt die Implementierung von MyAction1. Mitder checkPermission()-Methode des SecurityManagers wird überprüft, obdas System (im Auftrag eines Subjects) die benötigte Berechtigung besitzt.

70 Teil 2 - Theorie

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 somethingreturn result;

} catch (SecurityException e) {System.out.println("MyAction1 −> not ok");throw e;

}}

}

Damit das System eine PrivilegedAction �im Auftrag eines Subjects�ausführen kann, enthält die Klasse Subject die statischen Methoden doAs()

und doAsPrivileged(). Diese Methoden nehmen als Parameter ein Subjectund eine PrivilegedAction entgegen. Die Methode doAsPrivileged() er-wartet darüber hinaus einen AccessControlContext. Der SecurityManagerist nach dem Aufruf einer der doAs-Methoden in der Lage, Berechtigungs-entscheidungen aufgrund der Principals des Subjects und dem Inhalt derPolicy-Datei zu tre�en. Die run()-Methode der jeweiligen PrivilegedActionwird ausgeführt und, sofern alle benötigten Berechtigungen vorhanden sind,deren Ergebnis von der doAs-Methode zurückgeliefert. Andernfalls wird eineSecurityException geworfen.Die komplette Beispielanwendung be�ndet sich auf der CD zu dieser Ar-beit (siehe Anhang C.3). Abbildung 4.6 auf Seite 71 zeigt ein vereinfachtesSequenzdiagramm des Autorisierungsvorgangs. In dem Diagramm ist zu er-kennen, dass bereits für die Ausführung der doAs-Methoden Systemberech-tigungen notwendig sind.

[Jav07b]


Abbildung 4.6: Autorisierung mit JAAS - Sequenzdiagramm

72 Teil 2 - Theorie

4.3.3 Einordnung

JAAS ist ein bewährtes, Java-internes Rahmenwerk, das den von vornher-ein in Java vorhandenen Sicherheitsmechanismus um benutzerabhängige Zu-gri�skontrollen erweitert. Dadurch wird benutzer-, gruppen- und rollenba-sierte Autorisierung möglich. Der Bezug zu einer GUI ist im Bereich der Au-thenti�zierung einfach herzustellen (z.B. mit einem Log-in-Dialog). Da diedoAs-Methoden im nicht-autorisierten Fall eine SecurityException werfen,werden diese meist einfach an den Benutzer in Form eines (Fehler-)Dialogsweitergereicht. Allerdings können über einen kleinen Workaround die Berech-tigungen abgefragt werden, ohne die geschützte Aktion durchzuführen. Soist auch auf dem Gebiet der Autorisierung eine anpassbare Benutzungsober-�äche möglich (z.B. durch Weglassen von Menüpunkten, für die der Benutzernicht 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 Problemevon unbefugten Benutzern verändert werden. Auÿerdem sind sie durch keinePrüfsumme gesichert, um Änderungen gegebenenfalls zu erkennen. Da je-doch die Berechtigungen von Benutzern oder Rollen von Zeit zu Zeit ge-wechselt werden, ist ein weiterer Nachteil die fehlende Aktualisierung imSystem. Wurden Policy-Dateien einmal vom System eingelesen, können siezwar nachträglich verändert werden, doch das Java-System erkennt diese Än-derung nicht. Als Konsequenz muss die Anwendung neu gestartet werden.

Um JAAS innerhalb eines Rich-Clients verwenden zu können, muss alsoein Weg gefunden werden, der diese Probleme sinnvoll löst. Da sich dasSicherheitssystem von Java beliebig erweitern lässt, lassen sich z.B. die Stan-dardtextformate durch XML-Dateien ersetzen, die verschlüsselt und mit ei-ner (durch eine digitale Signatur gesicherten) Prüfsumme gespeichert werden.Solange die Policy-Dateien auf dem Client bleiben, kann der Rich-Client dieBerechtigungsentscheidungen weiterhin auch ohne bestehende Serververbin-dung tre�en. Sobald die Verbindung zum Server wieder hergestellt ist, mussdie lokale Policy-Datei mit dem Server synchronisiert werden.Eine Umsetzung, die den Java Authentication and Authorization Service unddie Eclipse Rich-Client-Platform zusammenführt, ist Eclipse-JAAS (sieheAbschnitt 6.2).

[Ull06, Kap. 24.3]

eXtensible Access Control Markup Language (XACML) 73

4.4 eXtensible Access Control Markup Lan-

guage (XACML)

Die von der Organization for the Advancement of Structured In- Kai Meyerformation Standards (OASIS) spezi�zierte eXtensible Access Con-trol Markup Language ist eine bewährte Beschreibungssprache für Sicher-heitsrichtlinien. Es ist eine XML-basierte Sprache zur Beschreibung sowohlvon Autorisierungsregeln und Policies (siehe Abschnitt 4.4.1) als auch vonAuswertungsregeln, um Entscheidungen für die Autorisierung tre�en zu kön-nen. Zusätzlich beschreibt XACML ein Nachrichtenformat, das für die Erzeu-gung von Autorisierungsanfragen und -antworten verantwortlich ist. Dabeiist XACML generisch und �exibel genug, um verschiedene Sicherheitsanfor-derungen sowie groÿe und komplizierte Richtlinienstrukturen zu unterstüt-zen. Einer der groÿen Vorteile von XACML ist, dass es Zugri�srechte aufbestimmte Teile von XML-Dokumenten vergeben kann.

Den Kern von XACML bilden der Policy Enforcement Point (PEP)und der Policy Decision Point (PDP). Im Kontext von XACML ist derBegri� Point als Einstiegspunkt zu verstehen. Der PEP schützt die zugrun-deliegenden Ressourcen, indem er die Anfragen eines Benutzers zuerst an denPDP schickt und nur wenn diese Instanz den Zugri� gewährt, werden die ent-sprechenden Aktionen vom PEP veranlasst. Die Nachrichten zwischen PEPund PDP werden in dem in XACML enthaltenen Nachrichtenformat gene-riert 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 getro�en werden, da be-nötigte Daten nicht vorhanden oder Fehler aufgetreten sind

• Not Applicable - Die Anfrage kann von diesem PDP nicht beantwortetwerden

4.4.1 Policies

Die XACML Beschreibungssprache für Policies ist in der Lage auch sehr �e-xible und komplexe Policies zu de�nieren. Aufgrund der Gröÿe des zugrun-deliegenden Daten-Modells werden hier nur die wichtigsten Komponentenvorgestellt:

74 Teil 2 - Theorie

• Eine XACML-Policy (Richtlinie) ist eine Menge von Regeln zusam-men mit einem Algorithmus, um diese Regeln zu kombinieren. Zusätz-lich können mehrere Obligations (Verp�ichtungen) hinterlegt werden.Diese spezi�zieren Operationen, die ausgeführt werden sollen, nachdemeine Autorisierungsentscheidung getro�en wurde. Jede Policy beinhal-tet genau einen Policy- oder PolicySet-XML-Tag.

• Ein PolicySet ist eine Menge von Policies oder anderen PolicySets unddient hauptsächlich der Strukturierung von Policies. Ähnlich wie beieiner Policy, ist in jedem PolicySet ein Algorithmus, der die Policiesverknüpft. Auch hier können wieder Obligations angegeben werden.

• Eine Rule (Regel) beschreibt, welche Bedingungen erfüllt sein müssen,damit erbetene Zugri�e auf Ressourcen gewährt werden. Sie beziehensich auf genau ein Target. Das Ergebnis bzw. der E�ekt einer Regel(�permit� oder �deny�) wird zurückgegeben, sofern das Target und dieoptionalen Conditions zutre�en.

• 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önnenanschlieÿ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 Anfrageenthaltenen Attribute den Bedingungen im Target entsprechen. DieInformation in einem Target können auch dazu verwendet werden, diePolicies zu strukturieren. Dies ist gerade bei einer sehr groÿen Anzahlvon Policies hilfreich.

• Ein Attribute (Attribut) ist ein unter einem Bezeichner bekannterWert eines Subjects, einer Ressource, einer Aktion oder der Umgebung.Der Name des Benutzers, seine Gruppenzugehörigkeit, die aktuelle Uhr-zeit oder die Uhrzeit der Anfrage sind solche Attribute.

4.4.2 Daten�uss

Die Abbildung 4.7 stellt einen typischen Anfrageablauf in XACML da. Dieeinzelnen Schritte sind dabei:

1. Ein Administrator legt am Policy Administration Point (PAP) Po-licies und Policies-Sammlungen fest.


Abbildung 4.7: XACML-Daten�uss [SNL06, S.419]

2. Ein Antragsteller (Benutzer oder andere Instanz) stellt eine Anfragebzgl. einer Ressource an den PEP. Dazu müssen die Attribute und Po-licies der Ressource, der Umgebung, der Aktion und des Antragstellersselbst bekannt sein.

3. Der PEP leitet die in dem domänenspezi�schen Format verfasste An-frage an den Context Handler weiter.

4. Der Context Handler kreiert aus der Anfrage einen XACML Anfrage-Kontext und sendet anschlieÿend eine Auswertungs-Anfrage an denPDP.

5. Der PDP fragt nun den Context Handler nach Daten, die für die Ent-scheidung benötigt werden. Dazu gehören Attribute des Benutzers, desbetre�enden Subjects, der Ressource, der Aktion sowie der Umgebung.

6. Der Context Handler bezieht die geforderten Attribute entweder ausdem schon erstellten Anfrage-Kontext oder aus einem Policy Infor-

mation Point (PIP).

7. Der PIP sammelt die Attribute von den entsprechenden Stellen.

8. Der PIP übergibt die Daten dem Context Handler.

76 Teil 2 - Theorie

9. Optional kann der Context Handler die Ressource dem Kontext anhän-gen.

10. Der Context Handler sendet die gesammelten Attribute an den PDP

11. Die passenden Policies werden ausgewertet, ein Entscheidungskontextgeneriert und dieser Kontext zusammen mit der Entscheidung zurückan den Context Handler geschickt.

12. Der Context Handler übersetzt die Antwort in das domänenspezi�scheFormat und leitet dies an den PEP weiter.

13. Der PEP führt am Obligations Service alle von der Entscheidung ab-hängigen Verp�ichtungen (engl. obligations) aus.

4.4.3 Umsetzungen und Erweiterungen

Sun Microsystems hat auf Sourceforge eine OpenSource Implementierungvon XACML verö�entlicht. Das XACML Kit Version 1.2 [Sun] unterstütztdie derzeit aktuelle XACML 2.0 Spezi�kation. Das Kit bietet verschiedenePakete, die einzelne Bereiche der XACML Spezi�kation umsetzen. Derzeitwird an der Version 2.0 gearbeitet.ebXML Registry [ebX] benutzt XACML, um eine Zugri�skontrolle für Web-Services zu realisieren. Es regelt unter welchen Umständen ein BenutzerZugri� auf einen Web-Service hat.SAML (Security Assertion Markup Language) ermöglicht in der Version 2.0eine Anbindung von XACML. SAML übernimmt die Authenti�zierung unddie Aufgaben eines Identity-Management und kann somit ein SSO (sieheAbschnitt 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 Spezi�kation keine Annahmen gemacht, wie sich die Ent-scheidungen auf die Benutzungsober�äche auswirken. Bei entsprechender Im-plementierung des PEP und des PDP ist es jedoch vorstellbar, aufgrund dergetro�enen Entscheidungen einzelne GUI-Komponenten auszublenden bzw.zu (de-)aktivieren und zwar bevor die zu den Komponenten gehörenden Ak-tionen ausgeführt werden.XACML kann auch innerhalb eines Rich-Clients verwendet werden, da die


Spezi�kation keine Annahmen darüber macht, wo und wie der PDP zu er-reichen ist. Wenn der Policy Enforcement Point bestandteil des Rich-Clientsist, ist es sogar möglich, dass ein Policy Decision Point ebenfalls lokal vor-handen ist. So wäre der Rich-Client ohne Serververbindung in der Lage,Autorisierungsentscheidungen zu tre�en. Sobald der Server wieder erreich-bar ist, können die Policies synchronisiert werden. Es ist ebenfalls denkbar,dass der Server seinen eigenen PDP besitzt. Dieser kann dann nicht nur dieeingehenden Synchronisationsanfragen überprüfen, sondern auch direkt voneinem Rich-Client angesprochen werden, um ohne weitere Synchronisierungdirekt auf den aktuellen Policies zu arbeiten.

[SNL06, S.411�], [Sun]

Kapitel 5

Weitergehende Konzepte und

Lösungen

Die bisher vorgestellten Autorisierungsmechanismen sind alle bewährt undKai Meyervielfach eingesetzt. Jedoch beschreibt keines der Konzepte, wie sich die Aus-wirkungen der Autorisierung sinnvoll in die Benutzungsober�äche integrierenlassen.Die Eclipse RCP bietet über die Plug-In-(De-)Aktivierung (Abschnitt 5.1)eine einfache Möglichkeit für die Autorisierung. Durch diesen Mechanismuswird, die in Abschnitt 3.1.5 diskutierte Variante des �Verstecken von Inter-aktionsobjekten� realisiert. Unter bestimmten Umständen, die in dem nochkommenden Abschnitt �Auswirkungen unterschiedlicher Systemanforderun-gen� (5.3) näher erläutert werden, ist dieses Vorgehen allerdings nicht rat-sam. Für diese Fälle wurde im Zuge dieser Diplomarbeit von den Autorendas Konzept der Security-Facade (Abschnitt 5.2) erstellt. Dieses Konzepterlaubt eine �exible Anbindung der Benutzungsober�äche, die sich für jedeszu schützende Interaktionsobjekt individuell kon�gurieren lässt.

5.1 Plug-In-(De-)Aktivierung

Die Plug-In-Architektur von Eclipse erlaubt die Auswahl der Plug-Ins, dieTorsten Wittein eine RCP-Anwendung integriert sein sollen. Dies ist nicht nur für dieEntwicklung von Produkten interessant, sondern ebenso für die Benutzerau-torisierung. Durch die Kontrolle, welche Plug-Ins in einer Anwendung aktivsein dürfen, wird automatisch kontrolliert, welche Registerbeiträge in ihr Er-weiterungsregister gelangen. Somit werden gleich zwei Ziele erreicht: Zumeinen ist der, vor der Ausführung zu schützende, Code nicht die Anwendungintegriert 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 Rechte-vergabe auf Plug-In-Ebene an. Dies ist ein �Alles oder Nichts�-Prinzip, dennentweder hat eine Rolle Zugri� auf ein komplettes Plug-In oder nicht. Dabeimüssen bei der Zuordnung von Rechten die Abhängigkeiten der Plug-Ins un-tereinander beachtet werden. Es ergibt sich zwangsläu�g eine hierarchischeBerechtigungsordnung, da keine Rolle die Berechtigung für ein Plug-In ha-ben kann, ohne die Berechtigung auf dessen benötigte Plug-Ins zu besitzen.Dementsprechend müssen Plug-In- und Rechte-Hierarchie aufeinander abge-bildet werden können. Dieser Umstand ist bereits bei der Entwicklung derPlug-Ins für eine RCP-Anwendung zu berücksichtigen und kann bei Integra-tion 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 An-satz von Berthold Daum (Abschnitt 6.1), Eclipse-JAAS (in Abschnitt 6.2)und eine Eigenentwicklung der beiden Autoren (Dienstplaner-Projekt, Ka-pitel 7). Jede dieser Realisierungen hat ihre Vor- und Nachteile und ist füreinen anderen Einsatzkontext mehr oder weniger sinnvoll. Auch müssen dieKonsequenzen beachtet werden, die sich aus der gewählten Methode ergeben.

Die hier vorgestellten Umsetzungen haben gemeinsam, dass der Benut-zer sich beim Starten der Anwendung anmeldet und ihm daraufhin nur diegewährten Plug-Ins zugesprochen werden. Für einen Wechsel der Rolle iststets ein Neustart der Anwendung notwendig. Laut OSGi-Spezi�kation istdas Hinzufügen und Entfernen von Bundles zu einer Anwendung währenddes laufenden Betriebes möglich. Also auch ein Rollenwechsel ohne Neustartder Anwendung, da Plug-Ins nachgeladen oder entfernt werden können. Daswird in den hier vorgestellten Realisierungen jedoch nicht behandelt.

Allerdings liegt genau in dieser O�enheit der Plattform eine Sicherheits-lücke. Im Fall der Eclipse RCP können über die OSGi-Konsole (siehe An-hang B.2.2) jederzeit weitere Plug-Ins in die Anwendung integriert werden.Keine der drei hier genannten Umsetzungen überwacht oder unterbindet dienach dem Anwendungsstart eingespielten Plug-Ins. Also kann nachdem dieAutorisierung und damit die Deaktivierung einiger Plug-Ins stattgefundenhat, diese wieder rückgängig gemacht werden. Um diese Sicherheitslückezu schlieÿen, sollte entweder verhindert werden, die jeweilige Eclipse RCP-Anwendung mit der OSGi-Konsole zu starten, oder besser, auf Änderungenan dem Erweiterungsregister �gehorcht� werden, um entsprechend zu reagie-ren.

80 Teil 2 - Theorie

5.2 Security-Facade

Da die Granularität der Berechtigungen bei der Plug-In-(De-)Aktivierung fürKai Meyermanche Anwendungskontexte zu grob ist, haben die Autoren im Zuge dieserDiplomarbeit das Konzept der Security-Facade erstellt. Das Konzept be-schreibt einen Autorisierungsmechanismus, der sich direkt auf die gra�scheBenutzungsober�äche auswirkt. Ferner erlaubt es eine sehr feine Struktu-rierung der Berechtigungen, da es den Schutz einzelner Code-Blöcke unter-stützt. Zudem können beliebige Interaktionsobjekte individuell den aktuellenBerechtigungen des Benutzers angepasst werden. Zusätzlich ermöglicht dasKonzept, die Berechtigungen zur Laufzeit zu editieren, was sich dann eben-falls 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 bildet zusammen mit den Executables denKern des Konzeptes. Die Executables beinhalten neben einem Be-zeichner die zu schützenden Code-Blöcke. Die Bezeichner dienen derIdenti�zierung eines Executables und für die spätere Ermittlung der be-nötigten Rechte zu dessen Ausführung. Die erstellten Executables wer-den jedoch nur dann aufgerufen, wenn es die Security-Facade erlaubt.Diese Entscheidung wird mit Hilfe des User- und Rights-Managementsgetro�en.

• Das User-Management dient der Anbindung des Authenti�zierungs-mechanismus. Darüberhinaus referenziert es den zur Zeit angemeldetenBenutzer und welche Berechtigungen er besitzt. Das User-Managementist auch dafür verantwortlich, einen Wechsel des Benutzers sowie Verän-derungen 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 vonRight-Sets festgehalten.

• DasRights-Management verwaltet die für die Ausführung jedes Exe-cutables benötigten Rechte. Diese können aus einem persistenten Spei-cher (Datenbanken, XML-Dateien, LDAP, . . . ) bezogen werden. DieReferenzierung der benötigten Rechte für ein Executable erfolgt überdessen Bezeichner. Auch dieses Management arbeitet auf den Right-Sets. Des Weiteren benachrichtigt das Rights-Management die Security-Facade und andere Instanzen über Änderungen der geforderten Rechtefür die Bezeichner.

• Ein Right-Set besteht aus einer Menge von Rechten und einem Be-zeichner. Der Bezeichner kann entweder der Name eines Benutzers oderder Bezeichner eines Executables sein. Es ist ebenso möglich, dass dieBezeichner komplexe Objekte sind. Für einen Benutzer repräsentiertdas Right-Set die ihm gewährten Berechtigungen im System, währendein Right-Set zu einem Executable den geforderten Rechten entspricht.Über die eingesetzten Bezeichner kann ein Right-Set eindeutig einemBenutzer oder einem Executable zugeordnet werden. Die Verwendungder Right-Sets im User- und Rights-Management vereinfacht die Er-mittlung der Berechtigungen in der Security-Facade.

• Das Activation-Management und die Activation-Adapter dienender Anpassung der Benutzungsober�äche. Eine genauere Beschreibungdieser Komponenten erfolgt später.

Die Executables werden also nicht direkt mit den Berechtigungen belegt,sondern lediglich mit einem Bezeichner versehen. Ein Administrator weistnur den Bezeichnern die benötigten Berechtigungen zu. Durch Vergabe desselben Bezeichners an mehrere Executables können Funktionsgruppen erstelltwerden. Somit sind entweder alle Executables einer Gruppe ausführbar oderkeines von ihnen.Wie aus dem Daten�ussdiagramm in Abbildung 5.2 zu ersehen, ermittelt

die Security-Facade bei einer eingehenden Anfrage nach einem Executablezunächst die gewährten Berechtigungen des aktuellen Benutzers vom User-Management. Anschlieÿend werden die geforderten Rechte für den Bezeich-ner des Executables vom Rights-Management erfragt. Ergibt sich bei demVergleich der beiden Right-Sets eine Übereinstimmung, erlaubt die Security-Facade die Ausführung des Executables.

82 Teil 2 - Theorie

Abbildung 5.2: Security-Facade-Daten�uss

Die geforderte Anbindung der Benutzungsober�äche wird über das Acti-vation-Management erreicht. Es nutzt die schon vorhandenen Bezeichnerund die Security-Facade. Das Activation-Management erlaubt, beliebige Ob-jekte zusammen mit einem Bezeichner und einem Activation-Adapter zuregistrieren. Diese Objekte können sowohl existierende oder selbst erstellteInteraktionsobjekte aber auch Verbindungen zu Datenbanken oder anderenDiensten sein.Die registrierten Objekte werden abhängig von den geforderten Rechten fürden Bezeichner und den gewährten Rechten des Benutzers (de-)aktiviert. DasWissen, auf welche Weise das Objekt aktiviert bzw. deaktiviert werden soll,ist im zugehörigen Activation-Adapter gekapselt. Wechselt der Benutzer oderwerden Rechte neu zugewiesen, erfährt dies das Activation-Management aufdie gleiche Weise wie die Security-Facade. Daraufhin kann es alle registrier-ten Objekte den neuen Bedingungen entsprechend anpassen. Somit bestehtdie Möglichkeit, nicht nur die Ausführung eines bestimmten Code-Blocks zuverhindern, sondern ebenso das zugeordnete Interaktionsobjekt, gemäÿ denin Abschnitt 3.1 geschilderten Varianten, zu markieren.

Es folgt ein kleines Beispiel, das verdeutlicht, wie die einzelnen Kompo-nenten verwendet werden:Eine Anwendung beinhaltet eine sensible Funktion, die über eine Schalt�ächeauf der gra�schen Benutzungsober�äche erreichbar ist.Um diese Funktion zu schützen, wird der betre�ende Code innerhalb einesExecutables mit dem Bezeichner �Exec1� implementiert. Die Schalt�ächeruft nun bei Betätigung über die Security-Facade das Executable auf. Damitist diese Funktion vor unberechtigter Ausführung geschützt.Soll dem Benutzer eine optische Rückmeldung über die aktuellen Berech-tigungen gegeben werden, muss lediglich diese Schalt�äche zusammen miteinem 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 Executableausgeführt werden kann. Darf die Funktion nicht ausgeführt werden, ist auchdie Schalt�äche gesperrt.Um das Interaktionsobjekt zu verstecken, muss ein Activation-Adapter ver-wendet werden, der die Sichtbarkeit der Schalt�äche steuert.

Die Abbildung 5.3 beschreibt, wann welche Nachrichten verschickt wer-den, um die beim Activation-Management registrierten Objekte bei einemBenutzerwechsel oder bei Veränderungen der Berechtigungen den aktuellenGegebenheiten anzupassen.

Abbildung 5.3: Security-Facade-Daten�uss mit Activation-Management

5.3 Auswirkungen unterschiedlicher Systeman-

forderungen

Der Kontext, in dem ein Softwaresystem eingesetzt werden soll, stellt be- Kai Meyerstimmte Bedingungen an die Anwendung. Diese Anforderungen wirken sichauf die Benutzungsober�äche und die Autorisierungsmechanismen aus. Soerlaubt die Verwendung eines Rich-Clients zwar eine reichhaltigere Benut-zungsober�äche als ein Thin-Client, aber da der Rich-Client ein Arbeitenohne Serververbindung fordert, muss auch die Authenti�zierung und Auto-risierung 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, kannes ausreichen, die Berechtigungen nur beim Starten der Anwendung zu über-prüfen. Läuft die Anwendung jedoch im Dauerbetrieb, also 24 Stunden an7 Tagen die Woche, mit wechselnden Benutzern, reicht dies natürlich nichtaus. Es muss dann ein Weg gefunden werden, die Berechtigungen jederzeit

84 Teil 2 - Theorie

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 odernur 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 ausliestund 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 sinnvollauf Plug-Ins abzubilden, können Plug-In-(De-)Aktivierungsstrategien durch-aus eingesetzt werden. Bei feiner strukturierten Rechten ist dieses Vorgehennicht zu empfehlen. Stattdessen können XACML (Abschnitt 4.4), JAAS oderdie Security-Facade (Abschnitt 5.2) eingesetzt werden.Selbst Vorgaben für die Gestaltung der Benutzungsober�äche können dieWahl des Autorisierungsmechanismus beein�ussen. Wird für eine möglichstkonstante GUI gefordert, dass sämtliche Funktionen und Optionen stetssichtbar sind (nur eventuell gesperrt), kann die Autorisierung ebenfalls nichtüber (De-)Aktivierung von Plug-Ins realisiert werden. Auf diese Weise wür-den die nicht gewährten Elemente in der GUI fehlen. Sind die Geräte derBenutzer nicht sehr leistungsstark (z.B. PDAs, einfache Workstations, usw.)bietet sich hingegen die (De-)Aktivierung der Plug-Ins gerade zu an, da sodas laufende Programm möglichst wenig Speicherplatz benötigt. Dies wirddurch den in der Eclipse RCP verwendeten �Lazy Loading�-Mechanismusnoch unterstützt.Gerade bei sehr fein strukturierten Rechten kann die Handhabung unüber-sichtlich und somit auch die Administration erschwert werden. Dem entgegenwirken kann die Verwendung von RBAC (Abschnitt 4.1) oder LDAP (Ab-schnitt 4.2).

Aufgrund der verschiedenen Anforderungen an ein Softwaresystem gibtes keine universell einsetzbare Autorisierungsstrategie. Je nach geforderterGranularität der Rechte, Darstellungsrichtlinien für die Benutzungsober�ä-che und Betriebsart der Software bieten sich unterschiedliche Autorisierungs-Konzepte an.

Kapitel 6

Bestehende Lösungen für Eclipse

Dieses Kapitel greift die in Abschnitt 3.3 angesprochenen Autorisierungs- Torsten Wittemethoden für die Eclipse RCP auf. Hier wird ihre Funktionsweise und Reali-sierung vorgestellt. Des Weiteren werden sie auf ihre Tauglichkeit untersuchtund 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 Torsten WitteVariante für die Realisierung von Benutzerautorisierung in Eclipse RCPs vor.Hauptsächlich macht er dies, um zu demonstrieren wie Plug-Ins programmge-steuert (de-)aktiviert bzw. RCP-Anwendungen nur mit bestimmten Plug-Insgestartet werden können.Die Situation in seiner Beispielanwendung ist folgende: Jeder Benutzer be-sitzt eine oder mehrere Rollen. Jeder Rolle kann eine oder mehrere Per-spektiven zugeordnet sein. Wenn einem Benutzer mehrere Perspektiven zurVerfügung stehen, soll der Benutzer zwischen den für ihn zugelassenen Per-spektiven umschalten können. Für die Auswahl von Perspektiven bietet sichdie Standard-Perspektivenleiste von Eclipse an. Das Problem ist, dass diesestets alle registrierten Perspektiven verwaltet.Eine Lösung für dieses Problem ist die programmgesteuerte (De-)Aktivierungvon Plug-Ins, um deren Perspektiven aus der Extension-Registry zu entfer-nen. Wird jede Perspektive durch ein eigenes Plug-In implementiert undwerden je nach Benutzerrolle nur die wirklich benötigten (und zugelasse-nen) Plug-Ins aktiviert, so kann die normale Eclipse-Perspektivenleiste fürdie Auswahl der Perspektiven verwendet werden.

85

86 Teil 2 - Theorie

Für die Realisierung dieser Problemlösung de�niert Berthold Daum indem Anwendungs-Plug-In com.bdaum.planner seines Projektplaners einenExtension-Point namens com.bdaum.planner.roles. Über diesen Extension-Point wird eine Perspektiven-Rollen-Zuordnung ermöglicht. Gleichzeitig wirdeine Zuordnung zwischen Rolle und Plug-Ins getro�en.

Ein Plug-In, das zu diesem Erweiterungspunkt beiträgt, gibt den Na-men einer (ggf. neuen) Rolle an, welche Perspektive erlaubt ist und ggf.initial geö�net werden soll und welche Plug-Ins für diese Rolle zugelassensind. Die folgende plugin.xml des Supervisor-Plug-Ins zeigt dies am Bei-spiel der Supervisor -Rolle. Supervisor verwalten innerhalb des Projektpla-ners die Projektressourcen. Projektpläne dürfen sie dagegen nicht erstellen.Das dürfen nur Benutzer in der Planer -Rolle. Als initiale Perspektive fürSupervisor wird daher die in dem Plug-In de�nierte Supervisor-Perspektivegesetzt. Diese Perspektive enthält die ebenfalls deklarierte ResourceView.Die zulässigen Plug-Ins sind das Supervisor-Plug-In selbst sowie das pas-sende 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">

<perspectiveclass="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 de�niert, die TaskPlanner-Perspektive alsinitiale Perspektive festgelegt und das TaskPlanner-Plug-In selbst sowie des-sen Hilfe-Plug-In der Planer-Rolle zugeordnet.

Alle Plug-Ins, die der Benutzer aufgrund seiner Rollen nicht verwendendarf, müssen nun von der Anwendung ausgeschlossen werden. Dies wirdin der Application-Klasse des Anwendungs-Plug-Ins erledigt, also direktbeim Start der Anwendung. Für die Deaktivierung und Deinstallation vonPlug-Ins gibt es die Bundle-Methoden stop() und uninstall() (siehe Ab-schnitt 2.3.2).

public class Application implements IPlatformRunnable {

public Object run(Object args) throws Exception {// Benutzer muss sich anmelden und authenti�ziert werdenDisplay 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 gehaltenUser user = PlannerPlugin.getDefault().getUser();if (user == null)// Shutdownreturn IPlatformRunnable.EXIT_OK;

// Update durchführen, falls nötigUpdateAction updateAction = new UpdateAction();updateAction.run(null);if (updateAction.isRestart())// Restartreturn 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)con�gureSystem(user.roles );

88 Teil 2 - Theorie

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 con�gureSystem(Collection roles) {// Alle Plugins, die Benutzerrollen zugeordnet sindSet<String> allNegotiableBundles = new HashSet<String>();// Alle Plugins, die den aktiven Benutzerrollen zugeordnet sindSet<String> activeBundles = new HashSet<String>();// ErweiterungsregisterIExtensionRegistry registry = Platform.getExtensionRegistry();

// Rollende�nitionen durchlaufenfor (ICon�gurationElement role : registry .

getCon�gurationElementsFor("com.bdaum.planner", "roles")) {// Bestimmen, ob eine gegebene Rolle aktiv istboolean active = roles.contains(role .getAttribute("name"));for (ICon�gurationElement plugin : role .getChildren("plugin")) {// zugeordnetes PluginallNegotiableBundles.add(plugin.getAttribute("id"));if (active)activeBundles.add(plugin.getAttribute("id"));

}}

// Nicht erlaubte Plugins entfernenBundleContext 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äuftbundle.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 Be-nutzernamen und Passwort einzuloggen. Im Erfolgsfall enthält die Plug-In-Klasse des Anwendungs-Plug-Ins ein User-Objekt. Dieses User-Objektenthält neben dem Benutzernamen auch eine Liste mit den Namen aller be-willigten Rollen. Schlieÿlich werden in der configureSystem()-Methode allePlug-Ins von der Anwendung ausgeschlossen, die mindestens einer Rolle zu-geordnet sind, aber keine dieser Rollen vom aktuellen Benutzer eingenommenwerden darf. Somit bleiben nur die Plug-Ins installiert, die entweder gar kei-ner Rolle oder mindestens einer Rolle des aktiven Benutzers zugeordnet sind.Plug-Ins von Drittanbietern können also weiterhin in die Anwendung inte-griert werden, obwohl sie nicht den role-Erweiterungspunkt erweitern. Dieskann abhängig vom Einsatzkontext ein Vor- oder Nachteil sein, widersprichtjedoch der Erlaubnisregel, da grundsätzlich alle Fremd-Plug-Ins für jedenBenutzer 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-Insvon einer Rolle genutzt werden dürfen, muss also nicht in einem einzigenPlug-In untergebracht sein. Somit lassen sich vorhandene Rollen jederzeitum neue Plug-Ins für zusätzliche Funktionalitäten oder Aufgabenbereicheerweitern, ohne existierende Plug-Ins anpassen zu müssen.Allerdings müssen die Zugehörigkeiten von Plug-Ins zu Rollen bereits zurEntwicklungszeit bekannt sein und können im späteren Betrieb nur über Ma-nipulation der jeweiligen plugin.xml verändert werden. Dementsprechendkönnen die Zugehörigkeiten nicht zur Laufzeit kon�guriert werden. Zusätz-lich muss bei der Zuordnung von Plug-Ins zu Rollen darauf geachtet werden,dass die von einem Plug-In vorausgesetzten Plug-Ins generell oder zumindestfür dieselbe Rolle verfügbar sind. Ansonsten kann das Plug-In nicht aufgelöstwerden.Damit ein Benutzer von einem neuen Recht Gebrauch machen kann, ist einNeustart und ein Update der Anwendung nötig (wie in der run()-Methodeder Application-Klasse zu sehen ist). Dies reicht in einigen Einsatzgebietenaus. Beim Entzug von Rechten fällt dieser Umstand allerdings schwerer insGewicht. Solange ein Benutzer seine Anwendung nicht neu startet, kann ermit Plug-Ins arbeiten, für die er keine Berechtigung mehr besitzt.Ein Neustart der Anwendung ist auch für einen einfachen Rollenwechsel er-forderlich. Plug-Ins, die für die neue Rolle erlaubt sind, könnten beim vorhe-rigen Log-in deinstalliert worden sein und sind über die Extension-Registrynicht mehr verfügbar.

90 Teil 2 - Theorie

Berthold Daum erkennt diese Probleme und schreibt:

�[. . . ] Allerdings wird die Verwaltung der Kon�guration durchein 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 Kon-�gurationsinformationen sichtbar. Eine �exiblere Möglichkeit istdie De�nition einer eigenen Kon�gurationsdatei (z.B. im XML-Format). Eine solche Datei kann leicht zwischen Server und Cli-ent ausgetauscht werden. Sie muss natürlich lokal auf dem Kli-enten gespeichert werden, um auch im O�ine-Fall verfügbar zusein. Die Auswertung kann dann über einen Kon�gurationsma-nager erfolgen, der vom Anwendungs-Plugin aus erreichbar seinsollte. Hier können bei kommerziellen Projekten auch Lizenzengeprüft werden, wenn bestimmte Funktionen abhängig von der je-weiligen Lizenz sind. Es versteht sich, dass auch die Kon�gu-rationsdateien digital signiert sein sollten, um Manipulationenvorzubeugen.� [Dau05b, S.456]

Auf genauere Anfrage zu seinem vorgestellten Ansatz antwortet Daum:

�[. . . ] Dass diese Art der Rollenzuordnung für die Praxis zustarr ist, versteht sich. In der Regel wird man eher mit einer se-paraten Kon�gurationsdatei arbeiten, und zur Laufzeit statt derExtensionRegistry diese Kon�gurationsdatei auswerten. So arbei-tet z.B. der IBM Workplace Managed Client [. . . ], eine kommer-zielle Erweiterung der Eclipse Rich Client Platform. Sie sorgtinsbesondere dafür, dass rollenbasierte Desktops im Zusammen-spiel mit den IBM Workplace Collaboration Services zentral ver-waltet und kon�guriert werden können.� [E-Mail von B. Daum anT. Witte]

Die komplette Beispiel-Anwendung ist in [Dau05b] beschrieben und kannunter [Dau] heruntergeladen werden.

Zusammenfassung

Dieser Ansatz eignet sich für Anwendungen, in denen die Anforderungenfolgendes zulassen:

Eclipse-JAAS 91

Kriterium Eigenschaft

Autorisierungs-Ebene Plug-InsFilterregel VerbotsregelGUI-Anpassung verstecken, über Plug-In-MechanismusRollen-/Rechtezuordnung sehr starr, zur Entwicklungszeit, nicht

durch AnwenderAnpassung 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. Torsten WitteDas Framework erweitert die Eclipse RCP so, dass der Java Authenticationand Authorization Service zur Authenti�zierung und Autorisierung von Be-nutzern verwendet wird. LoginModule und CallbackHandler können überErweiterungspunkte kombiniert und kon�guriert werden. Dies erlaubt einenhohen Freiheitsgrad bei der Auswahl der Authenti�zierungs-Technologie, z.B.von einem einfachen Log-in-Dialog über Smartcards bis zu Fingerabdruck-Scannern.Die Autorisierung �ndet auf Plug-In-Ebene statt. Ob ein Benutzer (in sei-ner Rolle) für ein Plug-In autorisiert ist, wird über das eingeloggte Subjectund die jeweilige Plug-In-Id entschieden. Das geschieht in einem oder meh-reren Exemplaren des Types IPluginAuthorization. Der Benutzer erhältZugri� auf ein Plug-In, falls ihm eines dieser Exemplare die Erlaubnis erteilt.Die Grundlage, auf der das jeweilige IPluginAuthorization-Exemplar seineEntscheidung tri�t, ist freigestellt. Sie kann hart codiert sein oder eine ex-terne Datei, ähnlich der Policy-Datei bei JAAS, zu Rate ziehen. Auch dieAnfrage bei einer Datenbank oder einem Verzeichnisdienst ist denkbar. DieIPluginAuthorization-Exemplare werden über einen Erweiterungspunkt indie Anwendung eingebunden. Welche Plug-In-Ids auf Benutzerberechtigungabgefragt werden, wird ebenfalls über Erweiterungen angegeben.

Eclipse-JAAS sieht eine strikte Trennung von Kern- und rollenspezi�-schen Plug-Ins vor, um die Autorisierung und die Verteilung der Plug-Ins zuvereinfachen. Zu den Kern-Plug-Ins zählen:

• Das Plug-In, das die RCP-Anwendung de�niert

• Das Plug-In, das den Code für die Authenti�zierung über JAAS ent-hält, die Orte der rollenspezi�schen Plug-Ins au�istet (siehe unten) unddie Autorisierung für diese Plug-Ins übernimmt

92 Teil 2 - Theorie

• Alle allgemein verwendeten Library-Plug-Ins

• Alles, was von allen Benutzern verwendet werden darf, unabhängig vonderen Rolle

Die rollenspezi�schen Plug-Ins enthalten die Geschäftslogik, die nur von be-stimmten Benutzerrollen verwendet werden darf. Diese Plug-Ins werden se-parat aufgeboten (deployed), z.B. auf einem HTTP-Server. Von ihnen wer-den bei jedem Start der RCP-Anwendung nur die Plug-Ins installiert undgestartet, für die der Benutzer berechtigt ist. Die übrigen Plug-Ins bleibenlediglich (auf dem Server) aufgeboten. Wo sich die rollenspezi�schen Plug-Insgenau be�nden, wird als URL über Erweiterungen bzw. System-Propertiesangegeben.

An dieser Stelle werden bereits einige Schwächen dieser Vorgehensweisedeutlich. Wenn die rollenspezi�schen Plug-Ins auf einem separaten Serverliegen, zu dem zum Startzeitpunkt der Rich-Client-Anwendung keine Ver-bindung besteht, stürzt die Anwendung zwar nicht zwangsläu�g ab, sondernwird ohne die rollenspezi�schen Plug-Ins ausgeführt. Dies behindert aberdennoch den Benutzer bei seiner Arbeit, falls ihm genau diese Plug-Ins feh-len.Ein gröÿeres, sicherheitsrelevantes Problem ist, dass bei der Autorisierungdie Erlaubnisregel nicht umgesetzt ist. Alle Plug-Ins, die sich im lokalenplugin-Verzeichnis der RCP-Anwendung be�nden, sind unweigerlich in dieAnwendung eingebunden. Da es zusätzlich ausreicht, dass nur eines derIPluginAuthorization-Exemplare die Erlaubnis für die Verwendung einesPlug-Ins gibt, kann nachträglich mühelos ein Plug-In integriert werden, dasgrundsätzlich den Zugri� auf alle Plug-Ins erlaubt. Die O�enheit der EclipseRCP für Erweiterungen birgt also eine Sicherheitslücke in sich.Wie bei JAAS auch, fehlt hier die Benachrichtigung und die automatischeAnpassung an wechselnde Berechtigungen zur Laufzeit. Sobald ein Benut-zer ein weiteres Plug-In verwenden darf oder ihm die Berechtigung für dieVerwendung eines Plug-Ins entzogen wird, muss die RCP-Anwendung neu ge-startet werden. Ansonsten sind die neuen Plug-Ins nicht in die Anwendungeingebunden und die alten Plug-Ins immer noch für den Benutzer verfügbar.

Dennoch ist die Verbindung des in Java vorhandenen Java Authenticationand Authorization Service und der Eclipse RCP eine gute Idee. Besondersfür die Benutzerauthenti�zierung lohnt sich der Einsatz. Auf Seiten der Au-torisierung besteht allerdings noch Entwicklungsbedarf.Die Verwendung in einer eigenen RCP-Anwendung ist sehr einfach, da Eclipse-JAAS 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 Inter-face IPlatformRunnable direkt zu implementieren, braucht nur von derenabstrakten Implementierung JaasApplication geerbt werden. Das Startender Workbench geschieht von da an über Subject.doAs(...). Alles weitere(LoginModule, CallbackHandler usw.) wird deklarativ über Erweiterungeneingebunden und beein�usst nicht den Code der eigenen Anwendung.

Das hier vorgestellte Konzept beruht auf der Version 1.0.0 von Eclipse-JAAS, das unter [Eclc] verfügbar ist. In Anhang C.4 be�ndet sich eine Bei-spielanwendung, der auch ein Plug-In zur Umgehung der Benutzerautorisie-rung beigefügt ist. Des Weiteren ist dort beschrieben, wie die Autorisierungmit Hilfe der OSGi-Konsole (Anhang B.2.2) umgangen werden kann.

Zusammenfassung

Eclipse-JAAS besitzt folgende Eigenschaften:Kriterium Eigenschaft

Autorisierungs-Ebene Plug-InsFilterregel VerbotsregelGUI-Anpassung verstecken, über Plug-In-MechanismusRollen-/Rechtezuordnung Fest codiert oder �exibel über XML-

Dateien, Datenbank oder Verzeichnis-dienst. Dadurch auch durch Anwenderkon�gurierbar.

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. Torsten WitteD.h. die Benutzungsober�äche kann an die jeweilige Arbeitsaufgabe an-gepasst werden. Nicht jede Funktionalität ist für die aktuelle Arbeitsauf-gabe relevant. Groÿe, unübersichtliche Menüs werden somit klein gehal-ten und dadurch übersichtlicher. Für die Skalierung lassen sich Menüs undMenüeinträge, Werkzeugleisten und deren Einträge, Views, Editoren, Per-spektiven, Preference- und Property-Pages sowie Wizards logisch in Grup-pen zusammenfassen. Diese Gruppierung kann nach Funktionalität (�Java-Entwicklung�, �Plug-In-Entwicklung�) oder Benutzererfahrungen (�Einfach�,

94 Teil 2 - Theorie

�Erfahren�, �Experte�) statt�nden. Die einzelnen Gruppen können manu-ell vom Benutzer oder auch programmgesteuert in der Benutzungsober�ächeein- und ausgeblendet werden.

Zur Realisierung dieser Filterung der Benutzungsober�äche werden Ca-pabilities verwendet. Ursprünglich wurde jedoch die Bezeichnung Activi-ties gewählt. Der Begri� Capability wurde erst eingeführt, nachdem bei derEntwicklung von Eclipse 3.0 erkannt wurde, dass Activity bereits an an-derer Stelle verwendet wird. Um Verwirrung zu vermeiden, wurden alsoin der Dokumentation und in der Benutzungsober�äche Activities in Ca-pabilities umbenannt, aber aus Kompatibilitätsgründen der Extension-Pointorg.eclipse.ui.activities und die bestehende API beibehalten.

Sowohl Perspektiven als auch Capabilities unterstützen das aktuelle Inter-essengebiet eines Benutzers und beziehen sich auf seine jeweilige Arbeitsauf-gabe. Während Perspektiven das Layout der Ober�äche, d.h. die Anordnungvon Views, Editoren usw., bestimmen und den einfachen Zugri� auf häu�gbenötigte Funktionalitäten ermöglichen, sind Capabilities für die Filterungnicht 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-Entwicklervorgesehen. Sie sind dafür verantwortlich, Plug-Ins so zusammenzustellen,dass sie sinnvoll miteinander arbeiten. Daher verstehen sie, wie die Plug-Inszusammen verwendet werden, und können am besten deren Funktionalitätenin Gruppen fassen. Plug-In-Entwickler dagegen haben meist nur ihr eige-nes Plug-In im Fokus. Die Erstellung und Verwaltung von Capabilities wirddurch ein Entwickler-Werkzeug erleichtert, welches bei [Khe04] zu �nden ist.

Die Eclipse-IDE besitzt z.B. die Capability Java Development. Sie bein-haltet sämtliche Funktionen für die Java-Entwicklung. Wenn diese Capabilityabgeschaltet ist, ist die Mehrheit dieser Funktionalitäten vor dem Benutzerversteckt. 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 kon�-guriert sowie ein- und ausgeschaltet werden. Damit die Benutzer sich nichtmerken müssen, wann sie welche Capability (de-)aktivieren müssen, um andie gewünschten Funktionen zu kommen, können Trigger Points eingerich-tet werden. Trigger Points sind z.B. Aktionen, die als Einstiegspunkt ineinen neuen/anderen Aufgabenbereich dienen. Wird so ein Trigger Pointausgelöst, wird die zugehörige Capability aktiviert und deren Beiträge in derBenutzungsober�äche angezeigt.Auch die Capability Java Development besitzt solche Trigger Points. Dabei


handelt es sich um die kleine Menge der Funktionen, die für die Entwicklungvon Java-Anwendungen nötig sind und stets in der GUI sichtbar bleiben,selbst wenn die Capability Java Development abgeschaltet ist. Über dieseTrigger Points bekundet der Benutzer ausdrücklich sein Interesse an denzusätzlichen Funktionalitäten der Java Development-Capability. Der �NewJava Project�-Eintrag in dem New-Wizard ist so ein Trigger Point. Sollte derBenutzer ein neues Java-Projekt anlegen, werden die übrigen Java Funktio-nalitäten sofort sichtbar und für den Benutzer verfügbar. Schlieÿlich wird ersie zur weiteren Entwicklung seines Projektes benötigen.

Des Weiteren können einzelne Capabilities untereinander in Beziehungstehen. So werden bei Aktivierung einer Capability ebenfalls alle Capabili-ties aktiviert, von denen die aktuelle Capability abhängig ist. Beispielsweisemacht die Capability Plug-In Development ohne Java Development keinenSinn, da Plug-Ins in Java geschrieben werden.

Das Konzept der Skalierung der Benutzungsober�äche über Capabilitieslässt sich auch auf Benutzerrollen übertragen. In den Eclipse-Newsgroupswird dies häu�g vorgeschlagen. Anstatt eine Capability Java Developmentoder Plug-In Development anzulegen, ist eine CapabilityAdministrator, Gast,Rolle A oder Rolle B denkbar. Auf diese Weise können in der Benutzungs-ober�äche bestimmte Erweiterungen nur bestimmten Benutzern mit der je-weiligen Rolle angezeigt werden. Da Capabilities für die Produktentwicklunggedacht sind, brauchen die einzelnen Rollen bei der Entwicklung der Plug-Insnoch nicht bekannt sein und berücksichtigt werden.

Allerdings ist zu beachten, dass diese Vorgehensweise ohne weitere Mecha-nismen keine Sicherheit bietet. Die einzelnen Funktionen sind lediglich ausder Benutzungsober�äche ausgeblendet, der Code bleibt in der Anwendungenthalten und kann potenziell jederzeit ausgeführt werden. Ein Plug-In, dassPreference Pages zum Umschalten von Capabilities zu der Anwendung hin-zufügt, ist schnell geschrieben. Eclipse bietet diese Präferenz-Seiten bereitsan, d.h. sie können ohne viel Aufwand eingebunden werden (siehe Quell-code 6.1). Die Ids der einzelnen Capabilities sind leicht zu ermitteln, umalle Capabilities in einer Kategorie zusammenzufassen und in den Präferenz-Seiten anzuzeigen. Die Integration des neuen Plug-Ins in die Anwendung istebenfalls kein Problem, da es nur in das plugins-Verzeichnis eingefügt werdenbraucht.

96 Teil 2 - Theorie

Quellcode 6.1: plugin.xml eines Plug-Ins, das Preference Pages für Capabili-ties einbindet<?xml version="1.0" encoding="UTF−8"?><?eclipse version="3.2"?><plugin>

...<extension point="org.eclipse.ui .preferencePages">

<pageclass="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 KimberlyHorne auf der EclipseCon 2005 zur Demonstration von Benutzerautori-sierung über Capabilities vorgestellt hat (siehe Anhang C.5). Das Projektbeinhaltet ein Anwendungs-Plug-In, das die beiden Benutzerrollen Employeeund Manager über Capabilities umsetzt. Ein Employee verfügt über wenigerViews als ein Manager. Dabei setzt die Manager-Capability die Employee-Capability voraus, d.h. alles was ein Employee darf, darf auch ein Manager.Das Beispiel veranschaulicht, wie die einzelnen Views über Id-Muster vonden beiden Capabilities ge�ltert werden. Diese Muster werden in der Form<Plug-In-Id>/<Contribution-Id> angegeben. So gehören alle Views, derenId 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 ge-schriebenes Plug-In, mit dem der Autorisierungsmechanismus umgangen wer-den kann. Dieses Plug-In wurde ohne Einblick in den Quellcode der RCP-Anwendung von Kimberly Horne entwickelt.

Zusammenfassung

Capabilities sind aus folgenden Gründen für die Benutzerautorisierung inter-essant:

• Einzelne Teile von Plug-Ins sind vor dem Benutzer verborgen oder fürihn sichtbar (nicht entweder das gesamte Plug-In oder gar nichts)


• Ge�ltert werden: Neu-, Import-, Export-Wizards; die �Show Views�-Liste; die �Open Perspective�-Liste; Werkzeugleisten-, Menü-Beiträge;Präferenz-, Eigenschafts-Seiten; Editoren; Suche; Hilfe

• Abhängigkeiten bzw. Hierarchien zwischen Capabilities sind de�nier-bar (activityRequirementBinding)

• Die Gruppierung von Capabilities in Kategorien ist möglich (catego-ryActivityBinding)

• Standardmäÿig sind alle Capabilities deaktiviert (defaultEnablement)

• Erstellungszeitpunkt erst bei der Produkt-Entwicklung

Der reine Capability-Ansatz eignet sich ohne weitere Mechanismen ausfolgenden Gründen nicht für Benutzerautorisierung:

• Bietet kaum Sicherheit, da lediglich eine Ausblendung der jeweiligen(Menü-)Einträge statt�ndet

• Capabilities sind jederzeit wieder freischaltbar, z.B. durch ein neuesPlug-In oder Preference Pages

• Einmal aktive Capabilities können nicht zurückgenommen werden

• Aktueller Zustand der Capabilities bleibt nach dem Ausschalten derAnwendung erhalten

• Rollen stehen nach der (Produkt-)Entwicklung fest, d.h. sie könnenohne in den Quellcode einzugreifen nicht verändert werden

• Nicht auf einzelne Interaktionsobjekte wie Buttons oder Textfelder an-wendbar


Autorisierungs-Ebene Actions, Views, Editoren, Wizards,usw.

Filterregel VerbotsregelGUI-Anpassung verstecken, über Capability-

MechanismusRollen-/Rechtezuordnung sehr starr, zur (Produkt-)Entwick-

lungszeit, nicht durch AnwenderAnpassung an veränderte Rechte erst nach Neustart des Clients, Update

notwendig

[Hor05a], [Hor05b], [Hor06], [HM04], [Cre04]

98 Teil 2 - Theorie

6.4 Fazit

Bei Verwendung der Plug-In-(De-)Aktivierung ist eine Trennung von Kern-Torsten Witteund rollenspezi�schen Plug-Ins, wie sie in Abschnitt 6.2 beschrieben ist,durchaus sinnvoll. Ebenso ist es wichtig, dass die Erlaubnisregel umgesetztwird, da sonst eine Umgehung der Autorisierung durch Fremd-Plug-Ins aufeinfache Weise möglich ist. Der Capability-Ansatz bietet ohne weitere Si-cherheitsmechanismen keine ausreichende Sicherheit für die Benutzerautori-sierung. Abschlieÿend darf nicht vergessen werden, dass die Autorisierunghier nur auf dem Client statt�ndet. Der Server muss ebenso stets vor unbe-rechtigtem Zugri� geschützt sein, so dass alle vertraulichen und sicherheits-relevanten Funktionen nur von autorisierten Benutzern ausgeführt werdenkönnen. Die Umsetzung der Benutzerautorisierung auf der Serverseite istbesonders wichtig, wenn die Schnittstelle (API) des Servers verö�entlichtwird und beliebig viele Clients entwickelt werden können.

Teil III

Praktischer Teil

99

100 Teil 3 - Praxis

Der dritte Teil dieser Arbeit widmet sich der Umsetzung konkreter Pro-Kai Meyer undTorsten Witte jekte, in denen Benutzerautorisierung eine Rolle spielt. Dabei werden die in

den vorherigen Kapiteln diskutierten Aspekte berücksichtigt. Bereits vorge-stellte Konzepte und Methoden werden verwendet, verbessert oder an dasjeweilige Projekt angepasst. Konsequenzen, die sich durch die Umsetzung inden jeweiligen Projekten ergeben, werden angesprochen und diskutiert.

Alle Projekte setzen auf der Eclipse Rich-Client-Platform auf und zei-gen, dass die erstellten Konzepte realisierbar sind. Begonnen wird mit demDienstplaner-Projekt, welches das Konzept der Plug-In-(De-)Aktivierung ver-folgt und die Erkenntnisse aus den Ansätzen von Berthold Daum und NeilBartlett aufgreift.Anschlieÿend wird ein Taschenrechner vorgestellt, bei dem die Benutzer nurbestimmte Operationen durchführen dürfen. Dazu wird die Security-Facadeimplementiert. Der Taschenrechner dient als Vorlage für das Control SystemStudio (CSS), welches das darauf folgende Kapitel füllt. Das Besondere amCSS-Projekt ist, dass dort eine einheitliche Infrastruktur für verschiedeneAnwendungen im CSS-Rahmen entwickelt wird. Zu diesen Anwendungenzählt das Synoptic Display Studio, welches für Entwickler und Benutzer so-genannter synoptischer Displays gedacht ist. Für die eigens erstellten Inter-aktionsobjekte innerhalb der Displays können zur Laufzeit Berechtigungenvergeben werden.

Als Abschluss dieser Arbeit wird am Ende dieses Teils nochmals auf dieKernfrage eingegangen und die erzielten Ergebnisse zusammengefasst.

Kapitel 7

Dienstplaner

Der Dienstplaner ist eine Eigenentwicklung der beiden Autoren. Das Projekt Torsten Wittebefasst sich mit der Entwicklung eines Softwaresystems für ein Alten- undP�egeheim. Die Anwendung soll bei der Erstellung der monatlichen Dienst-pläne für die Bereiche P�ege, Küche und Reinigung unterstützen. Dazu ge-hört auch die Verwaltung der einzelnen Mitarbeiter, Bewohnerzahlen, Dienst-zeiten, Ferien, Feiertage, Freistellungsanträge und nicht zuletzt der Dienst-pläne selbst. Das Personal soll an seinem jeweiligen Arbeitsplatz, z.B. demStationszimmer, jederzeit die Dienstpläne einsehen, Freistellungsanträge stel-len und Notizen hinterlegen können. Der Dienstplanersteller muss u.a. dieAnzahl der Heimbewohner, die Notizen des Personals und die von der Heim-leitung genehmigten Freistellungsanträge berücksichtigen.Die Benutzer der Anwendung schauen aus unterschiedlichen Sichten auf dieeinzelnen Dokumente wie Dienstpläne und Freistellungsanträge und dürfenjeweils nur bestimmte Teile dieser Materialien bearbeiten. Daher müssendie Benutzer für die einzelnen Aufgaben wie das Anlegen und Erstellen vonDienstplänen oder dem Genehmigen von Freistellungsanträgen autorisiertwerden. Diese Berechtigungen müssen nicht zwingend statisch sein. Es kannvorkommen, dass einem Benutzer Rechte entzogen werden oder er kurzfristigein zusätzliches Recht erhält, z.B. weil ein Kollege krank geworden ist unddessen 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. DieserPrototyp setzt den hier beschriebenen Entwurf für die Benutzerautorisierungvollständig um.

101

102 Teil 3 - Praxis

7.1 Konzept

Der Dienstplaner wurde auf Basis der Eclipse RCP entwickelt und setztTorsten Wittefür die Benutzerautorisierung das Konzept der Plug-In-(De-)Aktivierung um(siehe Abschnitt 5.1). Rechte werden also auf Plug-In-Ebene vergeben undbeziehen sich auf den Zugri� auf Plug-Ins, d.h. ein Benutzer kann sämtlicheoder gar keine Funktionen eines Plug-Ins verwenden. Bei der Entwicklungdieses Systems sind die Ansichten von Berthold Daum und Neil Bartlett miteinge�ossen. Die Eigenschaften ihrer Ansätze wurden wie in den Abschnit-ten 6.1 und 6.2 herausgearbeitet, um sie zu nutzen oder zu verbessern. Dasso entstandene Ergebnis wird in den folgenden Abschnitten vorgestellt.

7.1.1 Plug-In-Struktur

Bereits bei der Erstellung der Architektur zu dieser RCP-Anwendung wurdedas Konzept der Plug-In-(De-)Aktivierung für die Benutzerautorisierung be-rücksichtigt. So gibt es neben dem Anwendungs-Plug-In Hilfs- und Library-Plug-Ins, die von allen Benutzern verwendet werden dürfen. Diese Plug-Ins bilden die Gruppe der Kern-Plug-Ins. 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. Jedesdieser Plug-Ins ist für die Erzeugung neuer Exemplare eines Dokumentty-pes verantwortlich. Da es vorkommt, dass verschiedene Benutzer(-rollen)die selbe Ansicht auf ein Dokument besitzen, doch der eine Benutzer dasDokument bearbeiten darf und der andere nicht, sind weitere Plug-Ins inBetrachtungs- und Bearbeitungs-Plug-Ins eingeteilt. Um Logik nur einmal zuimplementieren und vorhandenen Code wiederverwenden zu können, bauendie Bearbeitungs-Plug-Ins auf den Betrachtungs-Plug-Ins auf. Dadurch sindsie eng miteinander gekoppelt. Betrachtungs-Plug-Ins können ohne entspre-chendes Bearbeitungs-Plug-In verwendet werden. Bearbeitungs-Plug-Ins ver-wenden oder erweitern jedoch einige Java-Klassen eines Betrachtungs-Plug-Ins, nämlich genau um die Editier-Funktionen. Daher können Bearbeitungs-Plug-Ins nicht ohne ihr Betrachtungs-Plug-In ausgeführt werden. In Abbil-dung 7.1 sind diese Plug-In-Abhängigkeiten am Beispiel von Dienstplänengra�sch dargestellt.In Bezug auf die Autorisierung tauchen an dieser Stelle keine Kon�ikte auf.Wenn ein Benutzer das Recht besitzt, einen Dokumenttyp (z.B. Dienstpläne)zu bearbeiten, dann darf er die Dokumente auch ansehen und lesen (zumin-dest 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 Be-trachtung und die Bearbeitung von Dokumenten gegeben oder entzogen wer-den.

Alle Plug-Ins, die von mindestens einem Benutzer verwendet werden dür-fen, sind auf einer Update-Site (siehe Abschnitt 2.5) innerhalb des lokalenNetzwerkes aufgeboten. Dabei sind alle Plug-Ins, die für die Ausführung derRCP-Anwendung unabdingbar sind und von jedem Benutzer verwendet wer-den dürfen, in einem Kern-Feature zusammengefasst. Dieses Feature decktsich mit der Gruppe der Kern-Plug-Ins. Weitere, rollenspezi�sche Plug-Inssind dagegen in separaten Features untergebracht. Diese Art der Einteilungder Plug-Ins in Features ist zwar nicht zwingend notwendig, erleichtert demAdministrator 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 erreich-bar) nach verfügbaren Updates für bereits lokal installierte Plug-Ins sowienach neuen Plug-Ins gesucht und ggf. installiert (siehe Abschnitt 2.5). An-schlieÿend muss der Benutzer sich über einen Log-in-Dialog authenti�zieren.Nach erfolgreicher Anmeldung werden die Ids aller erlaubten Plug-Ins für die-sen Benutzer ermittelt. Dies geschieht über eine Anfrage bei einer Datenbankauf dem zentralem Server. Nun werden alle Plug-Ins gestoppt und deinstal-liert, für die der Benutzer nicht berechtigt ist und die nicht von gewährtenPlug-Ins vorausgesetzt werden. Somit verbleiben auf der Plattform nur diePlug-Ins für die der Benutzer berechtigt ist und die er zu deren Ausführungbenötigt. Erst dann wird die Workbench gestartet und der Benutzer kann

104 Teil 3 - Praxis

mit seiner Arbeit beginnen. Die Abbildungen 7.2 und 7.3 zeigen Auszügevon der Benutzungsober�äche mit vollen und eingeschränkten Zugri�srech-ten. Es ist deutlich zu erkennen, dass Benutzer nur die Funktionen zu sehenbekommen, 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 Clientan-wendung nötig. Dadurch werden die einzelnen Plug-Ins und Berechtigungenaktuell gehalten. Der Benutzer verfügt immer nur über die Plug-Ins, für dieer beim Start der Anwendung autorisiert ist.

7.1.3 Benutzerverwaltung und Rechtevergabe

Abbildung 7.4 zeigt die Benutzungsober�äche für die Verwaltung von Benut-zern und deren Berechtigungen. Im Gegensatz zu RBAC (Abschnitt 4.1) sinddie Benutzer(-objekte) intern nicht über Rollen mit ihren Rechten verknüpft,obwohl die Benutzer natürlich innerhalb des Systems unterschiedliche Rol-len einnehmen. Stattdessen sind die Zugri�srechte auf die Plug-Ins direktan die Benutzer(-objekte) gebunden. Auf diese Weise ist der Administra-tor in der Lage, einem einzelnen Benutzer direkt das Zugri�srecht auf einPlug-In zu entziehen oder zu gewähren. Dadurch ist die Autorisierung auchfü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 Grundfür die direkte Anbindung ist, dass in diesem Anwendungskontext die Anzahlder Benutzer überschaubar und jeder Benutzer persönlich bekannt ist.Welche Plug-Ins ein Benutzer letztendlich verwenden darf, wird in einer zen-tralen Datenbank auf dem Server in Form der gewährten Plug-In-Ids festge-halten.

Die einfache und �exible Unterstützung der Rechtevergabe ist durch dieBildung von Rechtemustern und Benutzergruppen gegeben. Rechtemusterdienen als vorgefertigte Schablonen für die Rechtevergabe und können inAnlehnung an RBAC auch als Rollen verstanden werden. Ihre Verwendungist vorteilhaft für das Anlegen mehrerer (Einzel-)Benutzer, die ähnliche Be-rechtigungen benötigen, oder für den einfachen Wechsel von Rollen unterden Mitarbeitern des Heimes. Rechtemuster enthalten eine Menge von ge-währten Plug-Ins und können individuell erstellt und unter einem Namenabgespeichert werden. Bei der Zuweisung von Rechten an einen Benutzerkönnen diese Muster aufgerufen werden, so dass der Benutzer nur die Rechteaus dem Muster zugewiesen bekommt. Anschlieÿend können die Rechte desBenutzers unabhängig von dem verwendeten Muster jederzeit erweitert odereingeschränkt werden. Dies erleichtert dem Administrator die Arbeit, denner muss sich nicht merken, welche Rechte ein Mitarbeiter in einer Rolle erhal-ten muss und braucht ihm nicht die Berechtigung für jedes Plug-In einzelnzu geben. Die Auswahl des betre�enden Musters reicht aus. Darüber hinausvergisst der Administrator nicht, einem Benutzer den Zugri� auf Plug-Ins

106 Teil 3 - Praxis

Abbildung 7.4: Rechtevergabe im Dienstplaner

zu entziehen, wenn er dessen Berechtigungen mit Hilfe von Rechtemusternan eine andere Rolle anpasst. In Abbildung 7.4 ist für den Benutzer DonaldDuck das Rechtemuster P�egepersonal mit den entsprechenden Berechtigun-gen ausgewählt.

Neben Einzelbenutzern unterstützt das System auch Benutzergruppen.So können mehrere Benutzer gleichzeitig unter einem Gruppenbezeichner an-gemeldet sein. Zwar geht dadurch die genaue Information verloren, welcherBenutzer aus dieser Gruppe ein Dokument bearbeitet hat, aber da es sichhier nur um kleine Gruppen handelt und das jeweilige Bearbeitungsdatummit Uhrzeit im Dokument gespeichert wird, lässt sich der Bearbeiter an-hand seiner Dienstzeiten in den meisten Fällen zurückverfolgen. Dies reicht

Dienstplaner 107

innerhalb dieses Projektes aus. Am sinnvollsten ist der Einsatz von Benut-zergruppen für Benutzer, die keine Bearbeitungsrechte besitzen. Der Vorteilvon Benutzergruppen ist, dass der Administrator nicht jeden Benutzer einzelnverwalten muss. Für jedes Gruppenmitglied gelten die selben Berechtigun-gen.

Wie bei allen rollenspezi�schen Funktionalitäten ist auch die Benutzer-verwaltung in eigene Plug-Ins aufgeteilt. So hat nur ein Administrator, bzw.ein Benutzer, der autorisiert ist, Berechtigungen zu vergeben, Zugri� aufdiese Plug-Ins. Dieses Zugri�srecht kann ein Administrator auch an andereBenutzer weitergeben oder von ihnen entziehen. Dabei ist sichergestellt, dassmindestens ein Benutzer den Zugri� auf diese Plug-Ins besitzt und Rechtevergeben kann. Innerhalb dieses Projektes ist die Frage aus Abschnitt 1.7bzgl. 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 AdministratorA Benutzer B das Zugri�srecht auf das Rechtevergabe-Plug-In erteilt und Bdaraufhin anderen Benutzern weitere Rechte gibt, dann bleiben diese Berech-tigungen bestehen, auch wenn A das Recht der Rechtevergabe von B wiederentzieht.

Damit der Administrator stets den Überblick über alle verfügbaren Plug-Ins besitzt und er selbst nicht für alle Plug-Ins autorisiert sein muss, arbeitendie Plug-Ins für die Rechte- und Rechtemusterverwaltung auf der Update-Sitefür das System. Von dort werden die einzelnen Features und deren enthal-tenen Plug-Ins ausgelesen und auf der Benutzungsober�äche in Form einerBaumstruktur dargestellt. Die sinnvolle Einteilung der Plug-Ins in einzelneFeatures sorgt also für einen besseren Überblick und unterstützt den Admi-nistrator bei der Benutzerautorisierung. So kann er z.B. ohne Bedenken allenBenutzern alle Plug-Ins aus dem Kern-Feature erlauben.

Veränderungen an den Berechtigungen eines eingeloggten Benutzers wer-den zur Laufzeit des Clients nicht berücksichtigt. So kann der Benutzer seinebegonnene Arbeit zu Ende führen und bekommt erst nach erneuter Anmel-dung die neuen Berechtigungen zugewiesen. Nachdem der Administrator dieBerechtigungen eines Benutzers an neue Gegebenheiten angepasst hat, ister jedoch in der Lage, einzelne oder alle aktiven Clientanwendungen zu be-nachrichtigen und ggf. herunterzufahren. Dadurch erzwingt er eine sofortigeAktualisierung der Plug-Ins und Berechtigungen auf Clientseite. Somit kannder Administrator verhindern, dass Benutzer mit Plug-Ins arbeiten, zu denensie keine Berechtigung mehr besitzen.

108 Teil 3 - Praxis

7.2 Fazit

Die vorgestellte Architektur nutzt das vorhandene Plug-In-Konzept dazu, dieTorsten WitteAnforderungen an die Benutzerautorisierung �exibel zu erfüllen. Dadurchkann jeder Benutzer nur die ihm zugeteilten Plug-Ins an jedem Rechner inseiner Arbeitsumgebung (siehe [Z+98, S.86�]) verwenden, denn auf jedemClientrechner sind immer alle Plug-Ins installiert, die auf der Update-Siteverfügbar sind. Ein Administrator ist in der Lage, die Zugri�srechte sowohlfür bereits vorhandene als auch für neu verfügbare Plug-Ins zu vergeben undanzupassen.

Da die RCP-Anwendung o�en für Erweiterungen ist, muss sichergestelltsein, dass keine unerwünschten Fremd-Plug-Ins in die Anwendung gelangen.Durch die Umsetzung der Erlaubnisregel ist grundsätzlich die Verwendungaller (Fremd-)Plug-Ins verboten. Nutzer können zwar auf ihren Arbeitsrech-nern neue Plug-Ins in die Anwendung integrieren, z.B. durch Hineinkopie-ren in das plugins-Verzeichnis. Diese werden jedoch während des Autorisie-rungsvorgangs wieder aus der Anwendung entfernt. Ein Administrator mussexplizit die Erlaubnis für die Nutzung der Plug-Ins erteilen und sie auf derUpdate-Site bereitstellen. Durch die nötigen Neustarts der Clientanwendungbeim Benutzerwechsel und dem Zusammenspiel zwischen der Benutzerauto-risierung und der Update-Site bleibt stets eine aktuelle Autorisierung auf denClients gewährleistet.

Theoretisch ist ein Umgehen des Autorisierungsmechanismus zwar mög-lich, nämlich durch Austauschen eines bereits gewährten Plug-Ins durch ei-nes mit gleicher Id. Dies kann jedoch durch Signieren der einzelnen Plug-Insverhindert werden. Wenn sichergestellt wird, dass in der Clientanwendungnur Plug-Ins gestartet werden, die von bestimmten Personen oder Instan-zen signiert sind, können keine Fremd-Plug-Ins unter falscher Id ausgeführtwerden. 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 andereRCP-Anwendung wird durch die starke Abhängigkeit zu dem DienstplanRCP-Plug-In erschwert.

Die Information, welcher Benutzer welches Plug-In ausführen darf, kannzusätzlich auf Clientseite in einer signierten, verschlüsselten und durch einePrüfsumme gesicherten Datei festgehalten werden. So ist ein Start der An-wendung ausschlieÿlich mit den gewährten Plug-Ins auch ohne Serververbin-dung möglich. Diese Datei muss bei erneuter bestehender Serververbindungstets aktualisiert werden.

Da Eclipse standardmäÿig die letzte Kon�guration der Clientanwendungvor deren Beendigung speichert, um sie beim erneuten Start wieder herzustel-

Dienstplaner 109

len, tauchen bei einem Rollenwechsel ggf. Probleme auf. Grundsätzlich istaus gebrauchstauglicher Sicht der Software nichts gegen die Wiederherstel-lung der zuletzt verwendeten Ansicht, d.h. der zuletzt aktiven Perspektivemit allen zuletzt geö�neten Views und Editoren, einzuwenden. So �ndet derBenutzer die Anwendung stets so vor, wie er sie verlassen hat. Doch da hiermehrere Benutzer die selbe Anwendung nutzen und es nun vorkommen kann,dass ein Plug-In, das genau diese Perspektive, eine der Views oder den Editorbereitstellt, für die neu angemeldete Benutzerrolle nicht verfügbar ist, kannEclipse die Kon�guration nicht reproduzieren. So erscheint ein Hinweisfen-ster mit der Meldung, dass das zuletzt verwendete Layout der Workbenchnicht wieder hergestellt werden konnte. Um dies zu umgehen, gibt es dieeinfache Möglichkeit, die letzte Kon�guration stets zu löschen und immermit der Willkommensseite oder einer Standard-Perspektive zu starten. Ausgebrauchstauglicher Sicht ist die Variante, die zuletzt verwendete Kon�gu-ration benutzerabhängig zu speichern und wieder herzustellen allerdings diebessere Wahl.

Wenn Benutzergruppen eingesetzt und deren Berechtigungen nur sehrselten verändert werden, wird die Anzahl der wechselnden Log-ins und derdamit verbundenen Neustarts des Clients gering gehalten. So kann z.B. imStationszimmer den ganzen Tag lang ein Benutzer unter der BenutzergruppeP�ege eingeloggt sein und das gesamte P�egepersonal darunter arbeiten.

Die Entwicklung neuer Plug-Ins für den Dienstplaner ist technisch gese-hen unabhängig von dem hier verwendeten Autorisierungsmechanismus. Esmüssen bei der Entwicklung der Plug-Ins keine speziellen Java-Klassen oderErweiterungspunkte verwendet werden. Wichtig ist lediglich die Abbildungder einzelnen Arbeitsaufgaben und -abläufe auf Plug-Ins. Die Erlaubnis fürden Einsatz der Plug-Ins kann später aus der Anwendung heraus individuellvergeben werden, wenn die Plug-Ins auf der Update-Site aufgeboten werden.Die beschriebene Plug-In-Struktur verhindert darüber hinaus die Duplizie-rung von Code.

Zur weiteren Unterstützung des Administrators fehlt zum Erstellungs-zeitpunkt dieser Arbeit eine automatische Ermittlung bzw. Überprüfung derjeweils benötigten Plug-Ins bei der Rechtevergabe, wie sie aus der Startkon-�guration oder dem Update-Manager in der Eclipse-IDE bekannt ist (sieheAnhang B.2.1). Darüber wäre der Administrator in der Lage, bereits beider Vergabe von Rechten die Kon�guration der Plug-Ins zu überprüfen undherauszu�nden, ob der Benutzer für alle benötigten Plug-Ins eines gewährtenPlug-Ins ebenfalls autorisiert ist.

110 Teil 3 - Praxis

7.3 Zusammenfassung

Mit Hilfe der von der Eclipse RCP gelieferten Möglichkeiten wie dynamischeTorsten Witte(De-)Aktivierung von Plug-Ins, automatischen Updates bereits installierterPlug-Ins und Installation neuer Plug-Ins sowie Verwendung einer Update-Site, gelingt es, Benutzerautorisierung sinnvoll zu realisieren. Der hier um-gesetzte Ansatz greift zuvor diskutierte Aspekte von Berthold Daum undNeil Bartlett auf, vereint sie miteinander und nutzt deren Eigenschaften undVorteile. Damit wurde folgendes Ergebnis erreicht:


Autorisierungs-Ebene Plug-InsFilterregel ErlaubnisregelGUI-Anpassung verstecken, über Plug-In-MechanismusRollen-/Rechtezuordnung �exibel, durch Anwender kon�gurier-

barAnpassung an veränderte Rechte erst nach Neustart des Clients, Update

notwendig; Neustart des Clients kannerzwungen werden

Da die gesamte Dienstplaner-Anwendung sehr umfangreich ist, haben dieAutoren 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- Kai Meyerplementierung des in Abschnitt 5.2 vorgestellten Konzepts zur Benutzerauto-risierung (Security-Facade). Er wurde auch als funktioneller Prototyp (siehe[Z+98, 637�]) bei der Entwicklung des DESY-Projektes Control System Stu-dio (CSS) verwendet. Das Programm wurde auf Grundlage der Eclipse RCPerstellt, doch ist die Implementierung des Konzeptes unabhängig von Eclipse.Somit ist die reine Java-Implementierung auch auÿerhalb der Eclipse RCPverwendbar.

Für die im Taschenrechner umgesetzte Benutzerautorisierung lässt sichfolgender Einsatzkontext zugrunde legen:Die Schüler einer Schule dürfen einen Taschenrechner für die in ihrer Klas-senstufe (Klasse 1-4) bereits behandelten Rechenarten benutzen. Die Lehrerdürfen alle Operationen durchführen, unabhängig von der von ihnen betreu-ten Klassen. Der Administrator des Taschenrechners ist darüber hinaus inder Lage, Rechte zu vergeben bzw. zu entziehen.Der Taschenrechner bietet diverse mathematische Funktionen an. DieseFunktionen dürfen allerdings nur ausgeführt werden, wenn der aktuelle Be-nutzer die geforderten Rechte besitzt. Meldet sich ein Benutzer an, werdendie Schalt�ächen für die Rechenoperationen seinen Berechtigungen entspre-chend freigegeben.Zudem kann der Taschenrechner auftretende Ereignisse in einer eigenen Viewanzeigen. Zu diesen Ereignissen gehören Benutzerwechsel oder die Ausfüh-rung einer geschützten Funktion.Der Funktionsumfang des Taschenrechners ist erweiterbar, so können Plug-Ins von Drittanbietern zusätzliche mathematische Operationen hinzufügen.

111

112 Teil 3 - Praxis

8.1 Konzept

Die im Konzept der Security-Facade (Abschnitt 5.2) beschriebenen Kompo-Kai Meyernenten und deren Zusammenspiel werden im Taschenrechner 1:1 umgesetzt.Der Taschenrechner an sich benutzt diese Klassen, de�niert allerdings eineigenes, domänenspezi�sches Executable (OperationExecutable), das dasallgemeine AbstractTypedExecutable erweitert. Die angebotenen mathe-matischen Operationen werden als OperationExecutables realisiert und vonder SecurityFacade geschützt.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 Zi�ern, das Komma und eine Schalt-�äche, um die letzte Stelle der Eingabe zu löschen. Rechts be�ndet sich dasFeld für die Rechenoperationen. Sofern kein Benutzer angemeldet ist, sinddie Operationen nicht ausführbar und somit auch die Schalt�ächen für dieseOperationen gesperrt. Benutzerwechsel sind über bereitgestellte Menüein-träge ohne Neustart der Anwendung möglich. Wird ein Benutzer mit Hilfedes UserManagements durch Eingabe seines Benutzernamens und Passwortesauthenti�ziert, benachrichtigt es das ActivationManagement. Wie im Kon-zept beschrieben, kon�guriert das ActivationManagement bei einem Benut-zerwechsel alle registrierten Objekte gemäÿ den Rechten des Benutzers. Zuden angemeldeten Objekten gehören auch die Schalt�ächen der Operationen.Auf diese Weise werden die aktuellen Berechtigungen auf der Benutzungso-ber�äche dargestellt (Abbildung 8.1(b)).Die Abbildung 8.1 zeigt, dass im Taschenrechner die Strategie Sperren vonInteraktionsobjekten (Abschnitt 3.1.4) realisiert ist. Dies kann für andere

Taschenrechner 113

Projekte leicht durch den Austausch des verwendeten IActivationAdaptersverändert werden. Die Sperrung der Interaktionsobjekte dient hier nur dembesseren Überblick des Benutzers, damit er auf einen Blick erkennt, welcheRechenarten er durchführen darf und welche der Taschenrechner noch unter-stützt. Ob die hinter den freigegebenen Schalt�ächen liegenden Executableswirklich ausgeführt werden dürfen (oder nicht), wird zur Sicherheit jedesmalbeim Aufrufen der Funktion entschieden.

Die im Taschenrechner verwendeten Rechte werden durch den Nameneiner Gruppe und eine Rolle repräsentiert. Ein Benutzer mit dem BezeichnerUser ist z.B. in den Gruppen Class1 und Class3 in der Rolle Teacher tätig.In Class4 übernimmt er die Rolle des Administrators. So entsteht für einenBenutzer 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 einesExecutables 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 Kai Meyerdie Kern-Klassen (SecurityFacade, RightsManagement, UserManagement,ActivationManagement, ActivationAdapter, AbstractExecutable undAbstractTypedExecutable) allgemein bleiben und so mit nur wenigen Än-derungen auch in anderen Projekten verwendet werden können. Aus die-sem Grund sind die Plug-Ins des Taschenrechner-Projektes gemäÿ der Ab-bildung 8.3 strukturiert. Die Aufgaben der einzelnen Plug-Ins sind dabei:

• Das Anwendungs-Plug-In (RCP) enthält sämtliche Klassen, die für denAutorisierungsmechanismus zuständig sind. Somit ist die Security-Facade getrennt vom eigentlichen Taschenrechner.

114 Teil 3 - Praxis

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 Funktionengehört die Bereitstellung der View, der Logik für die Auswertung derOperationen sowie des OperationExecutables und der vier Grund-rechenarten. Zudem bietet es einen Erweiterungspunkt an, der dieAnbindung weiterer mathematischer Operationen regelt.

• Über den vom Calculator-Plug-In angebotenen Extension-Point in-tegrieren Extending-Plug-Ins weitere konkrete Implementierungen desOperationExecutables, um Rechenoperationen zu dem Taschenrech-ner beizutragen.

• Das Admin-Plug-In regelt die Administration und Überwachung derSecurityFacade. Dafür stellt es eine Message- und eine Rights-Viewzur Verfügung. Die Message-View stellt die von der SecurityFacade,vom RightsManagement und vom UserManagement verschickten Nach-richten dar. Die Rights-View erlaubt die Editierung der benötigtenRechte für die einzelnen Bezeichner und die Editierung der gewährtenRechte der Benutzer. Dies allerdings nur, wenn der aktuelle Benutzerdazu berechtigt ist.

Die Abbildung 8.4 zeigt die verwendeten Klassen im Überblick. Die hell-grau hinterlegten Klassen realisieren die Security-Facade und be�nden sichsomit im RCP-Plug-In. Dabei bilden die Klassen im schwarzen Rahmen dieKern-Klassen der Security-Facade. Die Klassen mit dunkelgrauem Hinter-grund sind im Calculator oder einem Extending-Plug-In enthalten.

Die SecurityFacade arbeitet auf den Schnittstellen IRightsManagement

und IUserManagement. Dies dient dem leichteren Austausch der konkretenImplementierung. Werden andere oder speziellere Implementierungen als dieim Taschenrechner angebotenen benötigt, brauchen nur die Klassen bzw. de-ren 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 genaukennen und für jeden einzelnen ein RightSet anlegen. Um den Administra-tor über die neu erstellten RightSets zu informieren, verschicken das Rights-und das UserManagement Nachrichten.Die so entstandenen RightSets enthalten allerdings keine Rechte. Was leereRightSets für die Benutzerautorisierung bedeuten, hängt von der verwende-ten IEvaluationStrategy (Strategie-Muster, siehe [GHJV95, S.373�]) ab.In der IEvaluationStrategy wird aufgrund der zum Benutzer und zumBezeichner gehörenden RightSets die Entscheidung getro�en, ob der Be-nutzer die Erlaubnis für den angeforderten Bezeichner besitzt. Das kon-krete IEvaluationStrategy-Exemplar wird in der SecurityFacade gehal-ten und dort verwendet. Mit Hilfe der IEvaluationStrategy können, wiebei XACML (Abschnitt 4.4) oder JAAS (Abschnitt 4.3), nicht nur die Rechte,sondern auch Daten des Benutzers oder des Systems in die Auswertung einbe-zogen werden. So lässt sich auch der in XACML spezi�zierte Policy DecisionPoint realisieren.Die im Taschenrechner verwendete IEvaluationStrategy erlaubt den Zu-gri�, wenn der Benutzer mindestens ein Recht besitzt, welches von dembetre�enden Bezeichner erwartet wird. Es ist aber ebenso vorstellbar, dassder Benutzer alle benötigten Rechte haben muss. In beiden Fällen würdenleere 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-

116 Teil 3 - Praxis

hält das RightSet zu einer Id, z.B. eines Executables, keine Rechte, kanndieser Bezeichner für jeden Benutzer freigegeben werden. Ist allerdings dasRightSet 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 sorgtdie Klasse RightSetIO. Sowohl das Rights- als auch das UserManagementverwenden das RightSetIO, wenn RightSets gelesen oder geschrieben wer-den sollen. Der Einfachheit halber werden hier die Daten lediglich in unver-schlüsselter Form in Textdateien auf der lokalen Festplatte gespeichert. Dieso�enbart Sicherheitslücken, die hier aber nicht weiter berücksichtigt werdensollen, da der Fokus auf der Benutzerautorisierung liegt.Da Editierungen der Textdateien durchgeführt werden können, ohne dass esder Taschenrechner bemerkt, kann es passieren, dass die Benutzungsober�ä-che nicht mehr zu 100% den tatsächlichen Berechtigungen entspricht. DieAusführung der Executables ist davon allerdings unbetro�en, 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-tieren das Interface IExecutable, wobei das AbstractExecutable im Ge-gensatz zum AbstractTypedExecutable keinerlei Eingabe- oder Ausgabe-werte hat und z.B. in der SecurityFacade bei der Persistierung der Rechteverwendet 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-bles dem aus Java bekannten Runnable. Die Ausführung des Executableskann direkt oder über die SecurityFacade erfolgen.Für die Fälle, wo Eingabe- und Ausgabewerte benötigt werden, wurde dasAbstractTypedExecutable erstellt, von der auch das OperationExecutableerbt. Diese Executables werden auf die gleiche Weise angesprochen, nur müs-sen, sofern vorhanden, beim Aufruf von execute() auch die Eingabewerte

Taschenrechner 117

übergeben werden. Der Ausgabewert mit dem im AbstractTypedExecutable

angegebenen Typ wird direkt von execute() 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 beidem 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 be-reitgestellte VISIBLE_CONTROL_ADAPTER verwendet, würde die Sicht-barkeit der Schalt�ächen angepasst. Da es sich in diesem Fall um normaleSWT-Buttons handelt, sind die Adapter recht einfach aufgebaut. Sie ru-fen an dem Button lediglich setEnabled bzw. setVisible auf. Damit dasActivationManagement korrekt arbeiten kann, ist es wichtig, dass nach derRegistrierung die im Adapter verwendete Methode nicht von anderern Stellenaus aufgerufen wird.

Die Verwendung der Standard-ActivationAdapter ist nicht zwingend er-forderlich. Es gibt ebenso die Möglichkeit, die Objekte zusammen mit einemeigenen IActivationAdapter anzumelden, der dann statt dem Standard-Adapter verwendet wird. So lässt sich die (De-)Aktivierung gezielt für ein-zelne Objekte steuern.Menü- und Toolbareinträge werden in vielen Programmen nicht nur abhängigvon den Benutzerberechtigungen gesperrt, sondern auch, wenn deren Aus-führung im momentanen Systemzustand keinen Sinn macht (z.B. Sortierungeiner Liste mit nur einem Eintrag). Daher wurde für die aus Eclipse stam-

118 Teil 3 - Praxis

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 vomKontext abhängen können, aber nur dann verfügbar werden, wenn der Be-nutzer die geforderten Rechte besitzt. Die AbstractUserDependentAction

wird im Taschenrechner z.B. innerhalb der Rights-View eingesetzt. Mit ihrwerden Aktionen realisiert, die dem selektierten RightSet ein Recht hinzu-fügen, entfernen oder alle RightSets speichern. Daher hängen die Actionsnicht nur von den Rechten ab, sondern auch davon, ob ein RightSet in derListe 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 AbstractUserDependentAction

tierten RightSet ein Recht hinzu, entfernen ein Recht oder speichern alleRightSets.

8.3 Zusammenfassung

Über die Security-Facade ist eine �exible und individuell kon�gurierbare Be-Kai Meyernutzerautorisierung mit Anbindung an die Benutzungsober�äche möglich.Durch die Activation-Adapter und den Auswertungsstrategien können vieleverschiedene Rahmenbedingungen umgesetzt werden. Aus Sicherheitsgrün-den sollte allerdings verhindert werden, dass zur Laufzeit oder durch einPlug-In eines Drittanbieters die IEvaluationStrategy beliebig verändertwerden kann. Ansonsten kann die korrekte Strategie durch eine ersetzt wer-den, die jedem Benutzer vollen Zugri� gewährt.Ein Schwachpunkt bei der Realisierung des Taschenrechners sind die Bezeich-ner der Executables. Gerade bei groÿen Anwendungen mit vielen zu schüt-zenden Code-Blöcken kann die Administration mangels Überblick schwierigsein. Dies ist allgemein ein Problem bei einer feinen Struktur der Rechte.Um dem entgegen zu wirken, bestehen die Bezeichner im Taschenrechneraus 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 ver-wechselt wird.

In dieser Beispielanwendung taucht eine bisher unberücksichtigte Schwie-rigkeit bei der Rechtevergabe auf:Es gibt (mathematische) Funktionen, die durch andere ausgedrückt werdenkönnen. So gilt für alle x, y ∈ R: x + y = x − (−y) = x − ((−1) · y) undx : y = x· 1

y. Ein Benutzer braucht also nicht unbedingt das Recht �Addition�

oder �Division� zu besitzen, sofern er berechtigt ist, zu subtrahieren und ne-gative Zahlen zu bilden bzw. zu multiplizieren und den Kehrwert einer Zahlzu bilden. Je mehr Rechenoperationen zu dem Taschenrechner hinzu kom-men, desto schwieriger wird die Verwaltung der Berechtigungen, um solche�Hintertüren� zu vermeiden. Dies kann in groÿen Anwendungen ebenso einProblem werden.Mit Hilfe der Security-Facade kann nicht verhindert werden, dass Actionsin Menüs sichtbar sind. Dies kann aber durch den Einsatz der in Ab-schnitt 6.3 beschriebenen Capabilities behoben werden. Die Aktionen wer-den als AbstractUserDependentAction realisiert, über die SecurityFacadegeschützt und mit Hilfe der Capabilities versteckt. Deren Trigger Pointskönnen bei dem ActivationManagement zusammen mit dem Bezeichner derAbstractUserDependentAction registriert werden. Auf diese Weise wärendie Actions nur sichtbar, wenn der Benutzer sie ausführen darf. Selbst wenndurch andere Instanzen, z.B. durch die im Abschnitt 6.3 vorgestellte Prefe-rence Page, die Capabilities aktiviert werden, können die sichtbar gewordenenAktionen nicht ausgeführt werden, da sie weiterhin durch die Security-Facadegeschützt sind.Mit der konkreten Implementierung der Security-Facade im Taschenrechnerwurden folgende Eigenschaften erzielt:


Autorisierungs-Ebene Code-BlöckeFilterregel �exibel (hier: Erlaubnisregel)GUI-Anpassung �exibel (hier: sperren)Rollen-/Rechtezuordnung �exibel, durch Anwender kon�gurier-

barAnpassung an veränderte Rechte unmittelbar

Das komplette Taschenrechner-Projekt be�ndet sich auf der beiliegendenCD. Dazu sei auch auf den Abschnitt C.6 im Anhang verwiesen.

Kapitel 9

Control System Studio

Ebenso wie der Taschenrechner (Kapitel 8) wird auch im Projekt ControlKai MeyerSystem Studio (CSS) [CSS] die Security-Facade eingesetzt. Das CSS-Projekt wird gemeinsam vom Deutsches Elektronen-Synchrotron

(DESY), der C1-WPS und der Universität Hamburg entwickelt. Es scha�teine generische Infrastruktur für verschiedene Kontrollsysteme zur Überwa-chung und Steuerung der unterschiedlichen Anlagen und Geräte von Teil-chenbeschleunigern. Das CSS setzt auf der Eclipse RCP auf und bietet einePlattform für verschiedene Programme an, zu denen auch das Synoptic Dis-play Studio (SDS) gehört.Das SDS ist für die Erstellung und Verwaltung von synoptischen Displaysverantwortlich und wird im Rahmen des CoEUD-Projektes (Component-based End User Development) [CoE] entwickelt. Unter synoptischen Dis-plays werden Anlagenschaubilder verstanden, die dazu dienen, Anlagen bzw.Prozesse zu überwachen. Die dargestellten Instrumente zeigen Messdatenvon bestimmten Geräten an und geben somit einen Überblick über den ak-tuellen Zustand der betrachteten Anlage bzw. des betrachteten Prozesses.Die Abbildung 9.1 zeigt so ein synoptisches Display. Über die verschiedenenSchieberegler, Schalt�ächen und Eingabefelder können Einstellungen an denrealen Geräten vorgenommen werden. Die Koordinatensysteme im oberenBereich und die diversen Textfelder zeigen die aktuellen Messdaten dieserGerä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 Hilfeder erstellten Displays die technischen Anlagen. Dabei ist es nicht zwingenderforderlich, dass sie alle Bereiche sehen bzw. Eingabewerte verändern dür-fen. 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 undsich anschlieÿend wieder abmelden. Da das CSS rund um die Uhr in Betriebist, kann kein Neustart für den Benutzerwechsel durchgeführt werden. DieGeräte vom DESY werden bereits durch eine zusätzlich Hardware-Schichtvor unzulässigen Einstellungen geschützt. Auf diese Wiese werden fehlerhafteEingaben verhindert. Daher liegt der Fokus bei der Verwendung eines Au-torisierungsmechanismus im CSS/SDS auf der Anpassung der Benutzungso-ber�äche. So beziehen sich die Rechte der Benutzer auf einzelne Widgets inden 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 beianderen Teilchenbeschleunigern eingesetzt werden sollen, ist das CSS undebenso das SDS gegenüber Anpassungen und Erweiterungen o�en. Auf dieseWeise können Entwickler beim DESY oder anderen Teilchenbeschleunigerneigene SDS-Widgets oder (Teil-)Programme in das CSS/SDS integrieren. So-mit muss der Autorisierungsmechanismus sehr �exibel und für die Entwicklereinfach 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 derEntwicklung. Somit waren einige Fragen, die die Sicherheit betre�en, nochnicht vollständig geklärt. Weil die im CSS implementierte Security-Facadeauf den für den Taschenrechner (Kapitel 8) erstellten Klassen aufbaut, wirdhier die Security-Facade nur in Auszügen behandelt.

122 Teil 3 - Praxis

9.1 Konzept

Im CSS wird für die Authenti�zierung JAAS (Abschnitt 4.3) verwendet. DieKai MeyerAutorisierung 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 aus-gerichtet sind. Diese Interaktionsobjekte setzen auf dem Graphical EditingFramework (GEF) auf. Somit bestehen die SDS-Widgets gemäÿ demModel-

View-Controller-Ansatz (siehe [SM02] oder [LR06] ab Kapitel 8) aus dreiKomponenten:

• Das Model hält die Attribute des Widgets, speichert die Werte undüberwacht Veränderungen dieser Werte.

• Die View ist für die gra�sche Repräsentation verantwortlich

• Der Controller übernimmt die Vermittlung zwischen dem Model undder View

Allerdings wurde der allgemeine MVC-Ansatz für den Einsatz im SDS an-gepasst. Wie in Abbildung 9.2(b) zu erkennen ist, haben das Model unddie gra�sche Repräsentation im Gegensatz zum reinen MVC-Ansatz keiner-lei Bezug zueinander. Dafür beobachtet der Controller ebenfalls das Modelund leitet vom Model versendete Ereignisse an die View weiter. Diese Mo-di�kation des MVC-Ansatzes scha�t klarere Aufgabenbereiche der einzelnenKomponenten.

(a) Standard-MVC [SM02] (b) SDS-MVC

Abbildung 9.2: Model-View-Controller

Die Displays be�nden sich entweder im Edit- oder im Run-Modus. ImEdit-Modus werden Displays erstellt und kon�guriert. Dazu können Widgets


in das Display integriert bzw. aus ihm entfernt werden oder sämtliche At-tribute der Widgets kon�guriert werden. Zu diesen Attributen gehören z.B.die Position, Breite, Höhe aber auch die �Permission ID�. Diese Id wird fürdie Registrierung beim Activation-Management verwendet.Wird ein Display in den Run-Modus versetzt, werden die Widgets bei demActivation-Management mit ihrer �Permission ID� angemeldet und gemäÿihrer Kon�guration, mit den realen Geräten verbunden. So können die Da-ten 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 Taschenrechnerim Abschnitt 8.1 beschrieben, durch eine Rechtematrix realisiert. Die ge-währten Rechte der Benutzer werden in einem LDAP-Verzeichnis (siehe Ab-schnitt 4.2) gespeichert. Für die geforderten Rechte wird derzeit noch eineungeschü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 Kai Meyergibt nicht ein Exemplar, das den aktuellen Benutzer hält, sondern meh-rere LoginContexte, die zu einem Benutzer noch weitere Informationen undFunktionen bereitstellen. Dieser LoginContext ist nicht der in JAAS verwen-dete, sondern wird nur innerhalb der SecurityFacade benutzt und verwaltet.Unter anderem können so Executables unter einem anderen LoginContext

ausgeführt werden. Auf diese Weise wird die geforderte kurzfristige Anmel-dung eines Benutzers realisiert.Das Rights-Management wird im CSS durch den RightsManagementService

umgesetzt. Aufgrund der Umstellungen des User-Managements liest im CSSdas RightsManagementService die Rechte eines Benutzers aus. Da derRightsManagementService sowohl die benötigten als auch die gewährtenRechte kennt, tri�t der Service direkt die Entscheidung, ob der Benutzerden Zugri� auf die hinter einem Bezeichner stehenden Objekte erhält. EineIEvaluationStrategy wurde bisher nicht umgesetzt. Die aktuelle Imple-mentierung des RightsManagementServices setzt die Verbotsregel (sieheAbschnitt 1.8) um, da sie bei einem leeren RightSet jedem Benutzer denZugri� erlaubt, auch wenn er selbst keine Rechte besitzt.

Das Activation-Management wird im CSS durch den ActivationService

realisiert. Bei der Registrierung von Objekten bei dem ActivationService

werden die Adapter nicht übergeben, sondern über den aus Eclipse stammen-

124 Teil 3 - Praxis

den AdapterManager ermittelt. Falls das übergebene Objekt das InterfaceIAdaptable implementiert, kann auch darüber der IActivationAdapter be-zogen werden. Der Quellcode 9.1 zeigt, wie der ActivationService denIActivationAdapter für das registrierte Objekt ermittelt.

Quellcode 9.1: Auszug aus dem ActivationService

private IActivationAdapter getActivationAdapter(�nal Object object) {IActivationAdapter adapter = null;if (object instanceof IAdaptable) {

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 SDS-Widgets den Enabled -Wert, was vom betre�enden Controller an die gra�-sche Repräsentation des Widgets gemeldet wird. Daraufhin wird das Er-scheinungsbild des Widgets angepasst. Was genau passiert, ist von der Im-plementierung der View und des Controllers abhängig. Theoretisch könnensämtliche Attribute des Widgets manipuliert werden. Praktisch wird es abermeist beim Sperren oder bei der Veränderungen der Sichtbarkeit bleiben.Die Executables und deren Verwendung entspricht der Beschreibung im Ta-schenrechner (Kapitel 8). Ebenso werden bisher die Rechte des Benutzersund die geforderten Rechte zu dem Bezeichner des Executables bei jeder An-frage neu ausgelesen. Dadurch wird stets auf Grundlage der aktuellen Datengearbeitet, kann aber zu erheblichem Netzwerkverkehr führen. Bisher wurdebeim DESY noch nicht ermittelt, ob der entstehende Netzwerkverkehr ver-tretbar ist, oder ob die Rechte-Matrizen in einem lokalen Speicher gehaltenwerden sollen.

9.3 O�ene Probleme und Zusammenfassung

Im CSS gibt es noch groÿe Unstimmigkeiten über den Aufbau und die Hand-Kai Meyerhabung der Permission IDs. Ein Display kann für mehrere verschiedeneaber identisch aufgebaute Bereiche der Anlagen verwendet werden. Überdie Angabe einer �Prozessvariablen� können die auszulesenden Datenströmebestimmt werden. Nun kann es vorkommen, dass Operateure aus unter-schiedlichen Bereichen verschiedene Instanzen des gleichen Displays verwen-


den, um einen Teil ihrer Anlagen zu überwachen. Das Display wird überspezi�sche Prozessvariablen auf die Bereiche eingestellt. Ob ein bestimmtesWidget aus dem Display einem Operateur zur Verfügung steht, hängt jetztnicht mehr nur von der Permission ID und den dazu hinterlegten Rechten,sondern ebenso von der verwendeten Prozessvariablen ab. Zudem wird imlaufenden System durch die hohe Anzahl an Displays, die teilweise hunderteWidgets enthalten können, die Administration sehr schwer.Die Security-Facade bietet eine einfach zu verwendende Möglichkeit, die Be-nutzungsober�äche entsprechend der Berechtigungen des Benutzers anzupas-sen. Dies ist gerade für die Entwickler beim DESY interessant. Da dieExecutables ähnlich wie die Runnables verwendet werden, bedarf es bei denEntwicklern nur einer kleinen Umstellung. Entsprechendes gilt auch für dieAbstractUserDependentAction, die anstelle der Actions Verwendung �n-det.Zurzeit werden im CSS/SDS allerdings nur die Interaktionsobjekte vor unbe-rechtigtem Zugri� geschützt. Die eigentlichen Aktion (sowohl das Auslesenals auch Verändern von Werten der Geräte) werden nicht geschützt. Diesverdeutlicht, dass die eigentlichen Aktionen unbedingt serverseitig geschütztwerden müssen, was beim DESY zumindest zum Teil durch die zusätzlicheHardware-Schicht gegeben ist.Mit der bisherigen Implementierung wurden folgende Merkmale erzielt:


Autorisierungs-Ebene Code-Blöcke, WidgetsFilterregel �exibel (hier: Verbotsregel)GUI-Anpassung �exibelRollen-/Rechtezuordnung �exibel, durch Anwender kon�gurier-

barAnpassung an veränderte Rechte unmittelbar

Aufgrund von Lizenzbedingungen und der Komplexität des Control Sy-stem Studios wurde davon abgesehen, eine CSS-Version auf der beiliegendenCD anzubieten.

[BRZ07, S.131�], [CW07]

Kapitel 10

Zusammenfassung und Ausblick

Im Rahmen dieser Arbeit wurde untersucht, ob und wie die Brücke zwischenKai Meyer undTorsten Witte Zugri�skontrolle und Benutzungsober�äche unter Berücksichtigung der be-

nutzergerechten Softwaregestaltung geschlagen werden kann. Dabei sind dieAutoren zunächst in der Diskussion um die korrekte Verwendung von In-teraktionsobjekten bei Benutzerautorisierung (Abschnitt 3.1) zu dem Ergeb-nis gekommen, dass das Verstecken der betre�enden Interaktionsobjekte dieGebrauchstauglichkeit der Software am stärksten fördert. Allerdings fehlenzu diesem Thema allgemeine Standards, die auch eingehalten werden. Mitdiesen Standards wäre eine weitere Grundlage für anwendungsübergreifendkonsistente Benutzungsober�ächen gescha�en.

Die in Kapitel 4 untersuchten Autorisierungs-Konzepte legen ihren Fokusauf Sicherheit, nehmen aber kaum Bezug zu der Benutzungsober�äche desumfassenden Softwaresystems. Im Gegensatz dazu wird im Eclipse-Umfelddie Wichtigkeit der Anbindung der Benutzungsober�äche an die Autorisie-rung berücksichtigt. Die geführten Diskussionen und entstandenen Ansätzezeigen, dass diese Anbindung möglich ist. Dabei wird ausschlieÿlich dasVerstecken von Interaktionsobjekten für nicht-gewährten Funktionen ange-wendet. Allerdings besitzen die hier vorgestellten Realisierungen noch ei-nige Schwachpunkte bzgl. der Sicherheit und der Rechtevergabe im realenEinsatz. Der von den Autoren erstellte Dienstplaner, der diese Ansätze auf-greift und weiterentwickelt, demonstriert, dass mit dem zugrunde liegendenKonzept der Plug-In-(De-)Aktivierung ein �exibler, sicherer und einfach zuhandhabender Weg für die Anbindung existiert.

Da die Plug-In-(De-)Aktivierung allerdings für manche Einsatzkontexteeine zu grobe Granularität der zu vergebenden Berechtigungen mit sich bringtoder das alleinige Verstecken von Interaktionsobjekten nicht ausreicht, ent-wickelten die Autoren die Security-Facade. Damit bewegen sich die einzel-nen Berechtigungen nicht auf Plug-In-Ebene, sondern auf Ebene von Code-

126

Zusammenfassung und Ausblick 127

Blöcken. Zudem können gezielt einzelne Interaktionsobjekte entsprechendden Berechtigungen des Benutzers angepasst werden. Dabei kommen dasVerstecken, das Sperren und andere Vorgehensweisen oder Kombinationen inBetracht. Die Security-Facade wurde anhand eines Prototypen erprobt undwird in dem Projekt Control System Studio erfolgreich eingesetzt.

Die Anforderungen an das zu realisierende System wirken sich natürlichauf die gewählte Methode aus. Generell ist zu sagen, dass Sicherheit aufallen Systemebenen gewährleistet sein muss. Somit sollte die Rechteverwal-tung von Beginn der Entwicklung an mit in die Architektur der Anwendungeinbezogen werden. Die Authenti�zierungs- und Autorisierungsdaten solltenimmer in verschlüsselter, signierter und durch Prüfsummen gesicherten Formvorliegen (sowohl auf dem Server als auch auf dem Client, falls nötig).

Die O�enheit der Eclipse RCP für Erweiterungen bildet in Bezug auf Be-nutzerautorisierung eine Sicherheitslücke, die beachtet werden muss. Wennder eingesetzte Autorisierungsmechanismus über das Erweiterungsregisterkon�gurierbar ist und keine weiteren Sicherheitsmechanismen (z.B. signiertePlug-Ins) verwendet werden, be�ndet sich voraussichtlich eine �Hintertür� indem System. Daher muss das Einbinden von (Fremd-)Plug-Ins nach demAnwendungsstart, bzw. nachdem die Authenti�zierung und Autorisierungvollzogen wurde, überwacht und ggf. verhindert werden. An dieser Stellebesteht noch Entwicklungsbedarf, auch im Eclipse RCP-Umfeld.

128

Teil IV

Anhang

129

Anhang A

Verweise

A.1 Eclipse-Newsgroups

Einstiegspunkte in die Diskussionen zu den Themen Sicherheit, Rollen-Konzept,Torsten Wittebenutzer-/rollenabhängige Benutzungsober�äche in der Eclipse Rich-Client-Platform:

• 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.


• Role Concept? (16.01.2004)http://dev.eclipse.org/newslists/news.eclipse.platform/

msg12572.html

• Hiding functionality using platform-de�ned 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 aselection?) (30.06.2004)http://dev.eclipse.org/newslists/news.eclipse.platform/

msg24036.html

130

http://dev.eclipse.org/newslists/news.eclipse.technology.equinox/msg00438.html


http://dev.eclipse.org/newslists/news.eclipse.platform/msg06453.html






http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg01778.html

http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg01778.html



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/itemsbased 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.


• Eclipse-JAAS: RCP security framework kind-of available (01.09.2005)http://dev.eclipse.org/newslists/news.eclipse.technology.


• 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.


• Limiting Access to Plugins (11.01.2007)http://dev.eclipse.org/newslists/news.eclipse.technology.


https://bugs.eclipse.org/bugs/show_bug.cgi?id=71857



http://dev.eclipse.org/newslists/news.eclipse.platform.rcp/msg02180.html




http://dev.eclipse.org/mhonarc/lists/platform-update-dev/msg00585.html

http://dev.eclipse.org/mhonarc/lists/platform-update-dev/msg00585.html















Anhang B

Eingesetzte Werkzeuge

B.1 Java

Die Programmiersprache Java wurde 1995 von Sun Microsystems (http:Torsten Witte//java.sun.com/) freigegeben. Die objektorientierte Sprache wurde ur-sprünglich für den Einsatz im World Wide Web optimiert. Daher lautetdie Java-Philosophie �Write Once, Run Anywhere�. Java-Programme werdenin Bytecode übersetzt und auf einer virtuellen Maschine, der JVM (Java Vir-tual Machine), ausgeführt, indem der Bytecode interpretiert wird. Deswegensind Java-Programme plattformunabhängig. Das zur Ausführung von Java-Programmen benötigte Java Runtime Environment ist heute für nahezu allePlattformen kostenlos erhältlich. Zur Entwicklung von Java-Programmenbietet Sun u.a. das J2SDK und das J2EE an.

B.2 Eclipse

Während in Kapitel 2 Eclipse als Grundlage für RCP-Anwendungen vorge-Torsten Wittestellt wurde, soll hier Eclipse als Entwicklungswerkzeug genauer betrachtetwerden.Die Eclipse-IDE bietet viele nützliche Funktionen zur Unterstützung des Pro-grammierers von Java-Anwendungen. Dazu zählen z.B. Vervollständigungs-und Refactoring-Funktionen, mit denen Code schnell und fehlerfrei von �star-ken Gerüchen� befreit werden kann (siehe [Fow00]). Ein komfortabler De-bugger ist ebenfalls vorhanden, der sogar Codeänderungen im laufenden Pro-gramm zulässt.Da die Eclipse-IDE selbst auf der Eclipse RCP aufsetzt, ist die Entwick-lungsumgebung über Plug-Ins erweiterbar. Die Entwicklung von Plug-Inswird u.a. durch das Plug-In Development Environment (PDE) unterstützt.

132

http://java.sun.com/




Startkon�gurationen für RCP-Anwendungen 133

Auf diese Weise kann jeder seine eigenen Funktionalitäten für die Eclipse-IDEentwickeln und nahtlos einbinden. So sind in der Community auch Plug-Insfür die Entwicklung in anderen Programmiersprachen entstanden. Eclipseist also keineswegs an Java gebunden. Die o�zielle Plug-In-Website �EclipsePlugin Central� (www.eclipseplugincentral.com) bietet mittlerweile fast1000 verschiedene Eclipse-Plug-Ins an.

B.2.1 Startkon�gurationen für RCP-Anwendungen

Der Screenshot in Abbildung B.1 zeigt, wie in der Eclipse-IDE ausgewähltwerden kann, mit welchen Plug-Ins eine (zu testende) RCP-Anwendung aus-geführt werden soll. In diesem Beispiel wird der Taschenrechner Calculatorauf dem Anwendungs-Plug-In RCP gestartet. Zusätzlich wird das Admin-Plug-In eingebunden. Im Eclipse-Workspace be�ndet sich noch das Erweiterungs-Plug-In CalculatorExtension, das weitere Rechenarten zu dem Taschen-rechner hinzufügt. Dieses ist allerdings nicht ausgewählt, so dass die hierausgeführte Anwendung nur die Grundrechenarten beinhaltet.Alle weiteren benötigten Plug-Ins lassen sich leicht über einen Klick auf AddRequired Plug-ins hinzufügen. Dazu gehören z.B. einige Kern-Plug-Insder Eclipse RCP, die sich auf der Zielplattform be�nden. Ebenso kann überValidate Plug-ins geprüft werden, ob alle Plug-In-Abhängigkeiten erfülltsind.

B.2.2 OSGi-Konsole

Ein nützliches Werkzeug zur Überwachung und Steuerung einer Eclipse Rich-Client-Platform zur Laufzeit ist die OSGi-Konsole. Jede RCP-Anwendungkann mit dem Kommandozeilenparameter -console gestartet werden. Dar-aufhin erscheint in der Konsole das osgi>-Prompt, über das Befehle an dieOSGi-Plattform gegeben werden können. Am dienlichsten ist hier das Kom-mando ss für �Short Status�. Darüber werden alle in der RCP vorhandenenPlug-Ins inklusive ihrer zugewiesenen Bundle-Id und ihrem aktuellen Zu-stand aufgelistet. Abbildung B.2 zeigt dies am Beispiel des Dienstplaners.Zu erkennen sind auch die Bundle-Ids der Fragmente, die zu einem Plug-Ingehören (z.B. Fragments = 25) und umgekehrt (z.B. Master = 26). Weitere,im Kontext dieser Arbeit wichtige Kommandos sind install, uninstall,start, stop und update. Diese Kommandos erwarten als Parameter eineURL oder die Id des in der Plattform eingebundenen Bundles. Alle übrigenzulässigen Kommandos werden über die Eingabe von help angezeigt.

[ML06, S.455]

www.eclipseplugincentral.com

134 Anhang

Abbildung B.1: Eclipse Startkon�guration 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 Au- Torsten Wittethentication and Authorization Service erstellen und bearbeiten. Das Toolist standardmäÿig in der Installation des Java Development Kits und desJava Runtime Environments im folgenden Verzeichnis enthalten:<JDK- oder JRE-Verzeichnis>\bin\policytool.exe

Anhang C

CD-Inhalt

C.1 Java

Das Java-Verzeichnis enthält das JRE und das J2SDK in Version 6 (Up-Torsten Wittedate 1) für Windows. Die jeweils aktuellste Version, auch für andere Platt-formen, ist unter http://www.java.com/de/ bzw. http://java.sun.com/erhältlich.

C.2 Eclipse

Im Eclipse-Verzeichnis der CD ist Eclipse in der Version 3.2.2 zu �nden.Torsten WitteDie jeweils aktuellste Version steht unter www.eclipse.org zum Downloadbereit.

C.3 Ausführbare Beispiele zu JAAS

Die CD enthält ein Verzeichnis JAAS-Examples. Dabei handelt es sich um einTorsten WitteEclipse-Projekt, das in den Eclipse-Workspace importiert werden kann. DasProjekt umfasst zwei Beispiele. Eines, das lediglich einen Benutzer authenti-�ziert, und eines, das nach einer erfolgreichen Authenti�zierung benutzerab-hängige Aktionen durchführt. Um die beiden Beispiele auszuführen, brauchtlediglich die MainClass aus dem jew. Paket (authenticationExample oderauthorizationExample) 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

http://www.java.com/de/


www.eclipse.org

Ausführbares Beispiel zu Eclipse-JAAS 137

C.4 Ausführbares Beispiel zu Eclipse-JAAS

Im Verzeichnis EclipseJAAS-Example be�nden sich die beiden Kern-Plug-Ins Torsten Wittenet.sourceforge.eclipsejaas und net.sourceforge.eclipsejaas.util

des Eclipse-JAAS-Frameworks von Neil Bartlett [Eclc]. Zusätzlich ist eineBeispiel-Anwendung vorhanden, die aus den Plug-Ins

• net.sourceforge.eclipsejaas.sample,

• net.sourceforge.eclipsejaas.samplelogin,

• net.sourceforge.eclipsejaas.sampleauth1 und

• net.sourceforge.eclipsejaas.sampleauth2

besteht. Das sample-Plug-In ist das RCP-Plug-In und de�niert das fertigeProdukt, während das samplelogin-Plug-In das JAAS LoginModule hin-zufügt und die Benutzerautorisierung übernimmt. Die beiden sampleauthX-Plug-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, alsoauch das sampleauth2-Plug-In von sampleauth1 abhängig ist. Beide Plug-Ins sind nur in einer bestimmten Rolle verfügbar.

Um das Beispiel ausführen zu können, müssen alle sechs Plug-In-Projektein den Eclipse-Workspace importiert werden. Anschlieÿend müssen die bei-den 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 demangegebenen Verzeichnis ein weiteres Unterverzeichnis plugins, welches wie-derum 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 Startkon�guration (siehe Anhang B.2.1) fürdas Produkt aus net.sourceforge.eclipsejaas.sample angelegt werden.Wichtig ist dabei, dass auf dem Reiter Main unter Program to run die Op-tion Run a product mit dem Wert net.sourceforge.eclipsejaas.sam-

ple.sampleProduct ausgewählt ist.Bei den VM Arguments auf dem Reiter Arguments muss der Pfad zu denbeiden exportierten Plug-Ins (als URL und mit abschlieÿendem Slash) ange-geben sein:-Declipsejaas.util.pluginLocation=�le:/C:/EclipseJAAS-Test/plugins/In der Startliste auf dem Reiter Plug-ins dürfen nur die Plug-Ins

138 Anhang

• 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 net.source-forge.eclipsejaas.sampleauthX-Plug-Ins 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ältEclipse einige Registereinträge im Zwischenspeicher, die nur für bestimmteBenutzer sichtbar sein sollen.

Beim Starten der Anwendung erscheint ein einfacher Log-in-Dialog, derlediglich einen Benutzernamen abfragt. Hier kann grundsätzlich alles einge-geben werden. Namen, die mit �Evil� beginnen, erhalten keinen Zugangin das System. Namen, die als Teilwort �Bob� enthalten, verfügen überbeide sampleauthX-Plug-Ins und somit auch über beide Views. Alle wei-teren Namen haben Zugang in die Anwendung, verfügen aber nicht über diesampleauthX-Plug-Ins.

Darüber hinaus be�ndet sich in dem selben CD-Verzeichnis das vom Au-tor dieses Abschnittes entwickelte eclipsejaas.evil.authorization-Plug-In. Wird die Beispielanwendung zusätzlich mit diesem Plug-In ausgeführt,erhält jeder authenti�zierte Benutzer Zugri� auf die beiden sampleauthX-Plug-Ins.

Eine weitere Variante, die Benutzerautorisierung zu umgehen, bietet dieOSGi-Konsole (siehe Anhang B.2.2). Dazu muss die Anwendung mit demKommandozeilenparameter -console ausgeführt werden. Nach dem Einlog-gen mit einem beliebigen Namen, braucht in der Konsole nur das Kommandoinstall file:/C:/EclipseJAAS-Test/plugins/net.sourceforge.ecli-

psejaas.sampleauth1_1.0.0.jar angegeben werden. Daraufhin erscheinteine Bundle-Id, unter der das Plug-In in der OSGi-Plattform erreichbar ist.Nach der Eingabe von start <Bundle-Id>mit dieser Bundle-Id ist das Plug-In innerhalb der Anwendung aktiv und die Test View 1 kann geö�net wer-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 WitteseCon2005.KCH.AuthDemo-Projekt, das Kimberly Horne auf der Eclipse-Con 2005 zur Demonstration von Benutzerautorisierung über Capabilitiesvorgestellt hat. Dieses Projekt braucht lediglich in den Eclipse-Workspaceimportiert und kann anschlieÿend als RCP-Anwendung ausgeführt werden.Das Einloggen als Manager ist mit dem Benutzernamen khorne und gleichlautendem Passwort möglich. Für die Rolle als Employee kann der Benutzer-name und das Passwort you gewählt werden. Weitere Log-in-Daten be�ndensich in der authtable-Datei des Projektes.Zusätzlich be�ndet sich in dem selben Verzeichnis das Projekt EvilPlugin.Wird die Demo-Anwendung von Kimberly Horne mit diesem Plug-In gestar-tet, be�ndet sich in der Menüleiste ein weiteres Menü, mit dem es möglichist, die Authenti�zierung und Autorisierung zu umgehen.

C.6 Taschenrechner

Auf der CD be�ndet sich im Verzeichnis Taschenrechner der in Kapitel 8 Kai Meyerbeschriebene Taschenrechner. Um die vollständige Anwendung starten zukönnen, müssen die Plug-Ins RCP, Calculator, CalculatorExtension undAdmin in den Eclipse-Workspace importiert werden. In der Startkon�gu-ration des Taschenrechners muss mindestens RCP-Plug-In und Calculator

ausgewählt sein (siehe Anhang B.2.1). Die Plug-Ins CalculatorExtensionund Admin sind optional. CalculatorExtension fügt dem Taschenrechnerweitere Rechenoperationen hinzu, während das Admin-Plug-In die Überwa-chung der Security-Facade und die Editierung von Rechten ermöglicht.Die Dateien user.txt, roles.txt und rights.txt enthalten die Daten fürdie Authenti�zierung und Autorisierung. Sie be�nden sich im RCP-Plug-Inunter �les.

Direkt nach dem Start der Anwendung ist kein Benutzer angemeldet unddaher auch keine Operation verfügbar. Für die An- bzw. Abmeldung einesBenutzers existieren im Menü File die Einträge Log-In und Log-Out. Wiein der user.txt festgehalten, können sich die Benutzer Tick, Trick, Track,Daisy und Donald anmelden. Das Passwort entspricht dabei dem Namen desjeweiligen Benutzers. Donald und Daisy gehören der Teacher -Rolle an, wobeiDaisy zusätzlich als Admin tätig ist. Tick, Trick und Track sind in der Pupil -Rolle. Je nach angemeldetem Benutzer werden verschiedene Operationenverfügbar.

140

Abbildungsverzeichnis

2.1 Erweiterbare Anwendung vs. Plattform [ME05, S.4] . . . . . . 242.2 Eclipse-Plattform [Dau05a, S.347] . . . . . . . . . . . . . . . . 252.3 Lebenszyklus von Bundles [ML06, S.460] . . . . . . . . . . . . 282.4 Plug-In-Abhängigkeiten . . . . . . . . . . . . . . . . . . . . . 302.5 Erweiterungen [ML06, S.21] . . . . . . . . . . . . . . . . . . . 39

3.1 Interaktionsobjekte (Windows XP) . . . . . . . . . . . . . . . 513.2 Interaktionsobjekte (Mac OSX) . . . . . . . . . . . . . . . . . 51

4.1 Core RBAC Elemente [Ame03, S.8] . . . . . . . . . . . . . . . 624.2 Hierarchical RBAC Elemente [Ame03, S.10] . . . . . . . . . . 624.3 SSD Elemente [Ame03, S.13] . . . . . . . . . . . . . . . . . . . 634.4 DSD Elemente [Ame03, S.14] . . . . . . . . . . . . . . . . . . 644.5 Authenti�zierung mit JAAS - Sequenzdiagramm . . . . . . . . 684.6 Autorisierung mit JAAS - Sequenzdiagramm . . . . . . . . . . 714.7 XACML-Daten�uss [SNL06, S.419] . . . . . . . . . . . . . . . 75

5.1 Komponenten der Security-Facade . . . . . . . . . . . . . . . . 805.2 Security-Facade-Daten�uss . . . . . . . . . . . . . . . . . . . . 825.3 Security-Facade-Daten�uss mit Activation-Management . . . . 83

7.1 Dienstplaner: Plug-In-Struktur . . . . . . . . . . . . . . . . . 1037.2 Dienstplaner: Menüleiste . . . . . . . . . . . . . . . . . . . . . 1047.3 Dienstplaner: Kontextmenü . . . . . . . . . . . . . . . . . . . 1057.4 Rechtevergabe im Dienstplaner . . . . . . . . . . . . . . . . . 106

8.1 Benutzungsober�äche des Taschenrechners . . . . . . . . . . . 1128.2 Rechtematrix für einen Benutzer im Taschenrechner . . . . . . 1138.3 Plug-In-Struktur des Taschenrechners . . . . . . . . . . . . . . 1148.4 Klassenübersicht des Taschenerechners . . . . . . . . . . . . . 1158.5 Verhalten einer gewährten AbstractUserDependentAction . . 118

9.1 SDS-Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

141

142 Abbildungsverzeichnis

9.2 Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . 122

B.1 Eclipse Startkon�guration von RCP-Anwendungen . . . . . . . 134B.2 OSGi-Konsole . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Literaturverzeichnis

[Ame03] American National Standards Institute, Inc.: Ameri-can National Standard for Information Technology � RoleBased Access Control. http://csrc.nist.gov/rbac/

rbac-std-ncits.pdf. Version:April 2003. � Letzter Zu-gri�: 24.09.2007

[Bar05] Bartlett, Neil: Eintrag in den Eclipse-Newsgroupsam 01.09.2005. http://dev.eclipse.org/newslists/

news.eclipse.technology.equinox/msg01132.html.Version: September 2005. � Letzter Zugri�: 24.09.2007

[Bar07] Bartlett, Neil: Secure Desktop Applications with EclipseRCP. http://www.eclipsecon.org/2007/index.php?page=

sub/&id=3889. Version:März 2007. � Letzter Zugri�:24.09.2007

[Bea05] Beaton, Wayne: What is a Rich Client? http://wbeaton.

blogspot.com/2005/12/what-is-rich-client.html.Version:Dezember 2005. � Letzter Zugri�: 24.09.2007

[BG03] Birnthaler, Thomas ; Gottschalk, Hermann: OpenLDAPLightweight Directory Access Protocol. http://www.ostc.de/

LDAP-12.pdf. Version: Juli 2003. � Letzter Zugri�: 24.09.2007

[Bol03] Bolour, Azad: Notes on the Eclipse Plug-in Architecture.In: Eclipse Corner Article (2003), Juli. http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_

architecture.html. � Letzter Zugri�: 24.09.2007

[Bru04] Brunnstein, Klaus (Hrsg.) ; Universität Hamburg, Fachbe-reich Informatik (Veranst.): Gestaltbarkeit und Beherrschbarkeitvon Informatiksystemen (GBI). 2004

143

http://csrc.nist.gov/rbac/rbac-std-ncits.pdf

http://csrc.nist.gov/rbac/rbac-std-ncits.pdf



http://www.eclipsecon.org/2007/index.php?page=sub/&id=3889

http://www.eclipsecon.org/2007/index.php?page=sub/&id=3889

http://wbeaton.blogspot.com/2005/12/what-is-rich-client.html

http://wbeaton.blogspot.com/2005/12/what-is-rich-client.html

http://www.ostc.de/LDAP-12.pdf

http://www.ostc.de/LDAP-12.pdf

http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html



144 Literaturverzeichnis

[BRZ07] Bleek, Wolf-Gideon (Hrsg.) ; Raasch, Jörg (Hrsg.) ; Züllig-hoven, Heinz (Hrsg.): Software Engineering 2007 - Fachtagungdes GI-Fachbereichs Softwaretechnik. Gesellschaft für Informa-tik, 2007

[Bur05] Burnette, Ed: What is a Rich Client? http:

//www.eclipsezone.com/eclipse/forums/t59350.html.Version:Dezember 2005. � Letzter Zugri�: 24.09.2007

[CoE] Component based End User Development (CoEUD) - Homepage.http://www.coeud.org. � Letzter Zugri�: 24.09.2007

[Cre04] Creasey, Tod: Scaling Large Eclipse ApplicationsProgressively. www.eclipsecon.org/2004/EclipseCon_

2004_TechnicalTrackPresentations/05_Creasey.pdf.Version: Februar 2004. � Letzter Zugri�: 24.09.2007

[CSS] Control System Studio (CSS) - Homepage. http://css.desy.

de. � Letzter Zugri�: 24.09.2007

[CW07] C1-WPS: Synoptic Display Studio Developers Guide. Juni 2007

[Dau] Berthold Daum - Homepage. http://www.bdaum.de. � LetzterZugri�: 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 undLösungen für Eclipse-spezi�sche Probleme. 1. dpunkt.verlag,2006

[Dud02] Dudenredaktion: Duden - Die deutsche Rechtschreibung.Weltbild Verlag GmbH, 2002

[ebX] ebXML auf Sourceforge. http://sourceforge.net/projects/ebxmlrr/. � Letzter Zugri�: 24.09.2007

[Ecla] Eclipse - Homepage. www.eclipse.org. � Letzter Zugri�:24.09.2007

http://www.eclipsezone.com/eclipse/forums/t59350.html

http://www.eclipsezone.com/eclipse/forums/t59350.html

http://www.coeud.org

www.eclipsecon.org/2004/EclipseCon_2004_TechnicalTrackPresentations/05_Creasey.pdf

www.eclipsecon.org/2004/EclipseCon_2004_TechnicalTrackPresentations/05_Creasey.pdf

http://css.desy.de

http://css.desy.de

http://www.bdaum.de

http://sourceforge.net/projects/ebxmlrr/

http://sourceforge.net/projects/ebxmlrr/

www.eclipse.org


[Eclb] Eclipse-JAAS - Homepage. http://www.integility.com/

eclipse_jaas. � Letzter Zugri�: 02.07.2007

[Eclc] Eclipse-JAAS auf Sourceforge. http://sourceforge.net/

projects/eclipse-jaas. � Letzter Zugri�: 24.09.2007

[Ecld] EclipseCon - Homepage. http://www.eclipsecon.org. � Letz-ter Zugri�: 24.09.2007

[Ecl06] Eclipse: Eclipse-Platform-Whitepaper. http:

//www.eclipse.org/articles/Whitepaper-Platform-3.

1/eclipse-platform-whitepaper.pdf. Version: 2006. �Letzter Zugri�: 24.09.2007

[Eng93] Engusser, Hermann: Duden Informatik - Ein Fachlexikon fürStudium und Praxis. Duden Verlag, 1993

[Equ] Equinox - Homepage. http://www.eclipse.org/equinox/. �Letzter Zugri�: 24.09.2007

[ER05] Edgar, Nick ; Rapicault, Pascal: Developing for theRich Client Platform. http://www.eclipsecon.org/2005/

presentations/EclipseCon2005_Tutorial26Final.pdf.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 Designvorhandener Software verbessern. 1. Addison-Wesley, 2000

[GHJV95] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlis-sides, John: Entwurfsmuster - Elemente wiederverwendbarerobjektorientierter Software. Addison-Wesley, 1995

[HM04] Horne, Kimberly ; McLaren, Chris: Activities Support inEclipse 3.0. http://dev.eclipse.org/viewcvs/index.cgi/

platform-ui-home/activities/activities.html?view=co.Version:Mai 2004. � Letzter Zugri�: 24.09.2007

http://www.integility.com/eclipse_jaas

http://www.integility.com/eclipse_jaas

http://sourceforge.net/projects/eclipse-jaas

http://sourceforge.net/projects/eclipse-jaas

http://www.eclipsecon.org

http://www.eclipse.org/articles/Whitepaper-Platform-3.1/eclipse-platform-whitepaper.pdf



http://www.eclipse.org/equinox/

http://www.eclipsecon.org/2005/presentations/EclipseCon2005_Tutorial26Final.pdf

http://www.eclipsecon.org/2005/presentations/EclipseCon2005_Tutorial26Final.pdf

www.evansdata.com

http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf

http://dev.eclipse.org/viewcvs/index.cgi/platform-ui-home/activities/activities.html?view=co

http://dev.eclipse.org/viewcvs/index.cgi/platform-ui-home/activities/activities.html?view=co


[Hor05a] Horne, Kimberly: A Context, a Capability, and a Per-spective Walk Into a Bar. http://eclipse.pookzilla.

net/2005/12/context-capability-and-perspective.php.Version:Dezember 2005. � Letzter Zugri�: 24.09.2007

[Hor05b] Horne, Kimberly: Addressing UI Scalability in Eclipse- What to Do When Your Application is Too Compli-cated. http://www.eclipsecon.org/2005/presentations/

EclipseCon2005_7.1Scalability.pdf. Version:März 2005. �Letzter Zugri�: 24.09.2007

[Hor06] Horne, Kimberly: A Context, a Capability, and a PerspectiveWalk Into a Bar: Capabilities. http://eclipse.pookzilla.

net/2006/10/context-capability-and-perspective.php.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. 131�143

[ISO] ISO - Homepage. www.iso.org. � Letzter Zugri�: 24.09.2007

[ISO94] ISO: Information technology - Open Systems Interconnec-tion - Basic Reference Model: The Basic Model. http:

//standards.iso.org/ittf/PubliclyAvailableStandards/

s020269_ISO_IEC_7498-1_1994(E).zip. Version: 2, Novem-ber 1994. � Reference Number: ISO/IEC 7498-1:1994(E) -Letzter Zugri�: 24.09.2007

[ITW07] ITWissen: Identi�kation. http://www.itwissen.info/

definition/lexikon//__identification_identifikation.

html. Version: 2007. � Letzter Zugri�: 24.09.2007

[Jav07a] JavaSun: JAAS Authentication Tutorial. http://java.sun.

com/javase/6/docs/technotes/guides/security/jaas/

tutorials/GeneralAcnOnly.html. Version:Mai 2007. �Letzter Zugri�: 24.09.2007

[Jav07b] JavaSun: JAAS Authorization Tutorial. http:

//java.sun.com/javase/6/docs/technotes/guides/

security/jaas/tutorials/GeneralAcnAndAzn.html.Version:Mai 2007. � Letzter Zugri�: 24.09.2007

http://eclipse.pookzilla.net/2005/12/context-capability-and-perspective.php


http://www.eclipsecon.org/2005/presentations/EclipseCon2005_7.1Scalability.pdf

http://www.eclipsecon.org/2005/presentations/EclipseCon2005_7.1Scalability.pdf



www.iso.org

http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip



http://www.itwissen.info/definition/lexikon//__identification_identifikation.html



http://java.sun.com/javase/6/docs/technotes/guides/security/jaas/tutorials/GeneralAcnOnly.html



http://java.sun.com/javase/6/docs/technotes/guides/security/jaas/tutorials/GeneralAcnAndAzn.html




[Jav07c] JavaSun: JAAS Reference Documentation. http://java.

sun.com/products/jaas/reference/docs/index.html.Version:Mai 2007. � Letzter Zugri�: 24.09.2007

[Jav07d] JavaSun: Java Authentication and Authorization Ser-vice (JAAS) Reference Guide for the Java SE DevelopmentKit 6. http://java.sun.com/javase/6/docs/technotes/

guides/security/jaas/JAASRefGuide.html. Version:Mai2007. � Letzter Zugri�: 24.09.2007

[KB06] Klinkert, Thomas ; Bertschler, Mario: Die Eclipse Rich-Client-Platform (RCP). http://www.saboracaferestaurant.

com/mb/document.pdf. Version:Mai 2006. � Letzter Zugri�:24.09.2007

[Khe04] Khelifi, Ines: How to Use the Activities Edi-tor. http://dev.eclipse.org/viewcvs/index.cgi/

platform-ui-home/activities/tools/activityTool.html?

view=co. Version: Juni 2004. � Letzter Zugri�: 24.09.2007

[LR06] Lahres, Bernhard ; Raýman, Gregor: Praxisbuch Objektori-entierung - Von den Grundlagen zur Umsetzung. 1. GalileoComputing, 2006

[MA06] Moran, John ; Ackerman, Laura: Second AnnualEclipse Global Enterprise Survey Points To Rapid AdoptionOf Eclipse Rich Client Platform. In: EclipsePress (2006),September. http://www.eclipse.org/org/press-release/

20060905rcp.php. � Letzter Zugri�: 24.09.2007

[McA05] McAffer, Je�: Eintrag in den Eclipse-Newsgroupsam 11.09.2005. http://dev.eclipse.org/newslists/

news.eclipse.technology.equinox/msg01141.html.Version: September 2005. � Letzter Zugri�: 24.09.2007

[ME05] Mätzel, Kai-Uwe ; Eicher, Tom: Contributing to Eclipse:Understanding and Writing Plug-ins. http://www.eclipsecon.org/2005/presentations/EclipseCon2005_Tutorial1.pdf.Version:März 2005. � Letzter Zugri�: 24.09.2007

[MG03] Melhem, Wassim ; Glozic, Dejan: PDE Does Plug-ins. In: Eclipse Corner Article (2003), September. http:

//www.eclipse.org/articles/Article-PDE-does-plugins/

PDE-intro.html. � Letzter Zugri�: 24.09.2007

http://java.sun.com/products/jaas/reference/docs/index.html

http://java.sun.com/products/jaas/reference/docs/index.html

http://java.sun.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html

http://java.sun.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html

http://www.saboracaferestaurant.com/mb/document.pdf

http://www.saboracaferestaurant.com/mb/document.pdf

http://dev.eclipse.org/viewcvs/index.cgi/platform-ui-home/activities/tools/activityTool.html?view=co



http://www.eclipse.org/org/press-release/20060905rcp.php

http://www.eclipse.org/org/press-release/20060905rcp.php



http://www.eclipsecon.org/2005/presentations/EclipseCon2005_Tutorial1.pdf

http://www.eclipsecon.org/2005/presentations/EclipseCon2005_Tutorial1.pdf

http://www.eclipse.org/articles/Article-PDE-does-plugins/PDE-intro.html




[Mit] Mitlinx LDAP - Homepage. http://www.mitlinx.de/ldap/. �Letzter Zugri�: 24.09.2007

[ML06] McAffer, Je� ; Lemieux, Jean-Michel: eclipse Rich ClientPlatform - Designing, Coding, and Packaging Java Applications.Addison-Wesley, 2006

[Mol01] Molander, Mark: Reducing 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. � LetzterZugri�: 24.09.2007

[OSG] OSGi - Homepage. www.osgi.org. � Letzter Zugri�: 24.09.2007

[RF06] Rosenthal, Jay ; Flaherty, Matthew: Eclipse RCP Ap-plications and Enterprise Security. http://www.eclipsecon.

org/2006/Sub.do?id=451. 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. RolfSchmidt, 2005

[Sch06] Schneider, Wolfgang: Grundsätze der Dialoggestaltung DINEN ISO 9241-110. http://www.ergo-online.de/site.aspx?

url=html/software/grundlagen_der_software_ergon/

grundsaetze_der_dialoggestalt.htm. Version:Oktober2006. � Letzter Zugri�: 24.09.2007

[Shn82] Shneiderman, Ben: The Future of Interactive Systems and theEmergence of Direct Manipulation. Behaviour and InformationTechnology. 1982

[Shn83] Shneiderman, Ben: Direct Manipulation: A Step beyond Pro-gramming Languages. In: IEEE Computer (1983), August

[Shn87] Shneiderman, Ben: Designing the User Interface: Strategiesfor E�ective Human-Computer Interaction. Addison-Wesley,1987

[Sie06] Siemens, AG: Authenti�zierung. http://www.networks.

siemens.de/solutionprovider/_online_lexikon/5/

f009705.htm. Version: 2006. � Letzter Zugri�: 24.09.2007

http://www.mitlinx.de/ldap/

http://www-128.ibm.com/developerworks/web/library/us-reduce/

http://www-128.ibm.com/developerworks/web/library/us-reduce/

http://www.openldap.org

www.osgi.org

http://www.eclipsecon.org/2006/Sub.do?id=451

http://www.eclipsecon.org/2006/Sub.do?id=451

http://www.ergo-online.de/site.aspx?url=html/software/grundlagen_der_software_ergon/grundsaetze_der_dialoggestalt.htm



http://www.networks.siemens.de/solutionprovider/_online_lexikon/5/f009705.htm




[SM02] Sun Microsystems, Inc: Java BluePrints: Model-View-Controller. http://java.sun.com/blueprints/patterns/

MVC-detailed.html. Version: 2002. � Letzter Zugri�:24.09.2007

[SNL06] Steel, Christopher ; Nagappan, Ramesh ; Lai, Ray: coreSecurity Patterns - Best Practices and Strategies for J2EE, WebServices, and Identity Management. PRENTICE HALL PTR,2006

[Sun] XACML Kit auf Sourceforge. http://sunxacml.sourceforge.net/. � Letzter Zugri�: 24.09.2007

[Ull06] Ullenboom, Christian: Java ist auch eine Insel - Program-mieren mit der Java Standard Edition Version 6. 6. GalileoComputing, 2006

[Unb06] Unbekannt: Eclipse RCP weiter auf dem Vormarsch. In: Ja-vaMagazin (2006), September. http://javamagazin.de/itr/

news/psecom,id,30709,nodeid,367.html. � Letzter Zugri�:24.09.2007

[Uni03] University of California, Berkeley: Role BasedAccess Control. http://groups.sims.berkeley.edu/

doc-eng/projects/ROLES/research/RBAC_review.doc.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). http://www.gaudior.net/alma/johnny.pdf. � Letzter Zugri�: 24.09.2007

[Z+98] Züllighoven, Heinz u. a.: 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

http://java.sun.com/blueprints/patterns/MVC-detailed.html

http://java.sun.com/blueprints/patterns/MVC-detailed.html

http://sunxacml.sourceforge.net/

http://sunxacml.sourceforge.net/

http://javamagazin.de/itr/news/psecom,id,30709,nodeid,367.html

http://javamagazin.de/itr/news/psecom,id,30709,nodeid,367.html

http://groups.sims.berkeley.edu/doc-eng/projects/ROLES/research/RBAC_review.doc

http://groups.sims.berkeley.edu/doc-eng/projects/ROLES/research/RBAC_review.doc

http://www.gaudior.net/alma/johnny.pdf

http://www.gaudior.net/alma/johnny.pdf

150

Abkürzungsverzeichnis

ACL Access Control ListAPI Application Programming InterfaceASCII American Standard Code for Information InterchangeCoEUD Component-based End User DevelopmentCSS Control System StudioDAC Discretionary Access ControlDAP Directory Access ProtocolDESY Deutsches Elektronen-SynchrotronDSD Dynamic Seperation of DutyGEF Graphical Editing FrameworkGUI Graphical User InterfaceHAL Hardware Abstraction LayerHTML Hypertext Markup LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentINCITS InterNational Committee for Information Technology StandardsIP Internet ProtocolISO International Organization for StandardizationIT Information TechnologyITU International Telecommunication UnionJ2EE Java 2 Enterprise EditionJ2SDK Java 2 Standard Edition Development KitJ2SE Java 2 Standard EditionJAAS Java Authentication and Authorization ServiceJDK Java Development KitJNDI Java Naming and Directory InterfaceJRE Java Runtime EnvironmentJVM Java Virtual MachineLDAP Lightweight Directory Access ProtocolMAC Mandatory Access ControlMVC Model-View-Controller

151

152 Abkürzungsverzeichnis

OASIS Organization for the Advancement of Structured InformationStandards

OSGi Open Service Gateway InitiativeOSI Open Systems InterconnectionPAP Policy Administration PointPDE Plug-In Development EnvironmentPDP Policy Decision PointPEP Policy Enforcement PointPIN Persönliche Identi�kationsnummerPIP Policy Information PointRBAC Role Based Access ControlRCP Rich-Client-PlatformSAML Security Assertion Markup LanguageSDS Synoptic Display StudioSSD Static Seperation of DutySSO Single Sign-OnSWT Standard Widget ToolkitTCP Transmission Control ProtocolUI User InterfaceURL Uniform Resource LocatorWAM Werkzeug- und Material-AnsatzXACML eXtensible Access Control Markup LanguageXML eXtensible Markup Language

Index

Dateien

.exsd . . . . . . . . . . . . . . . . . . . . . . . . . . . 37actionSets.exsd . . . . . . . . . . . . . . . 37feature.xml . . . . . . . . . . . . . . . . . . . . 40fragment.xml . . . . . . . . . . . . . . . 39, 40manifest.mf . . . . . . . . . . . . . 32, 33, 37plugin.xml 32, 33, 37�39, 86, 87, 89site.xml . . . . . . . . . . . . . . . . . . . . . . . . 41

A

Access Control List . . . . . .siehe ACLACL . . . . . . . . . . . . . . . . . . . . . . . . . 14, 65Activation-Adapter . . . . . . 81�83, 118Activation-Management . 81�83, 123American Standard Code for Infor-

mation Interchange . . . .sieheASCII

Anwender . . . . . . . . . . . . . . . . . . . . . . . . 9Anwendungs-Plug-In . 26, 34, 86, 87,

89, 96, 102, 113, 133API . . . . . . . . . . . . . . . . . . . . . . 20, 94, 98Application Programming Interface

siehe APIASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Attribute . . . . . . . . . . . . . . . . . . . . . . . . 74aufgabenangemessen . . . . . . . . . . . . . 12Authenti�zierung . . . 2, 4, 13, 14, 54,

55, 57, 60, 65�68, 72, 76, 80,83, 91, 122, 127, 136, 139

Autorisierung . . . . . . . . . i, 2�4, 12, 14,18, 46, 47, 54�58, 60, 61, 66,67, 70�74, 76�80, 83�85, 91�93, 96�98, 102, 104, 108�110,

113, 119, 121, 122, 125�127,139

B

Bediener . . . . . . . . . . . . . . . . . . . . . . . . . . 9Benutzer . . . . . . . . . . . . . . . . . . . . . . 9, 61Benutzerauthenti�zierung . . . . . 1, 92Benutzerautorisierung . . . . . . . i, 1, 3,

5, 18, 46, 47, 51, 53, 54, 56,59, 64, 78, 85, 93, 96�98, 100�102, 107, 108, 110, 111, 115,116, 118, 126, 127, 137�139

Benutzungsmodell . . . . . . . . . . . . . . . 10Benutzungsober�äche . . . . . . . . . . . . 10Bundle-Activator . . . . . . . . . 27, 32�34

C

Capability .4, 36, 55, 56, 93�98, 119,139

CoEUD . . . . . . . . . . . . . . . . . . . . . . . . 120Component-based End User Develop-

ment . . . . . . . . . . . . . . . . . . sieheCoEUD

Condition . . . . . . . . . . . . . . . . . . . . . . . 74Control System Studio . . . siehe CSSCore RBAC . . . . . . . . . . . . . . . . . .61, 62CSS . . . . . . 4, 100, 111, 120�125, 127

D

DAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16DAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65DESY . . . . . . .111, 120, 121, 124, 125

153

154 Index

Deutsches Elektronen-Synchrotronsiehe DESY

Directory Access Protocol . . . . . sieheDAP

Discretionary Access Control . . sieheDAC

DSD . . . . . . . . . . . . . . . . . . . . . . . . . 61, 64Dynamic Seperation of Duty . . siehe

DSD

E

Eclipse-IDE 23, 25, 56, 94, 109, 132,133

Eclipse-JAAS . . . . . .4, 56, 58, 72, 79,91�93, 137

Eclipse-Newsgroups . .54, 58, 95, 130EclipseCon . . . . . . . . . . 54�56, 96, 139Eclipse RCP . . . . . . . . . . . . . . i, 2�4, 8,

18, 19, 22�29, 38, 43, 46, 47,54�56, 58, 59, 72, 78, 79, 84,85, 91, 92, 100, 102, 110, 111,120, 127, 130, 132, 133

Eclipse 3�5, 19, 23�28, 31�33, 35�37,39, 40, 42, 54�59, 66, 78, 85,91, 93�95, 108, 109, 111, 117,123, 126, 132�134, 136�139

Endbenutzer . . . . . . . . . . . . . . . . . . . . . . 9Equinox . . . . . . . . . . . . . . . . . . 23, 55, 58Erlaubnisregel . . . . . . . . . . . . . . . . . . . 18erwartungskonform . . . . . . . . . . . . . . 12Erweiterung . . . . . . . . siehe ExtensionErweiterungspunkt . . . . . . . . . . . . siehe

Extension-PointErweiterungsregister . . . . . . . . . . siehe

Extension-RegistryExecutable . . . . 80�83, 112, 113, 116,

118, 123�125eXtensible Access Control Markup

Language . . . . siehe XACMLeXtensible Markup Language . siehe

XML

Extension-Point Schema . . . . . . . . . 37Extension-Point . . . . . . 28�30, 33, 34,

36�39, 56, 58, 86, 89, 91, 94,109, 114, 124

Extension-Registry . . . 26�29, 37, 38,58, 78, 79, 85, 89, 127

Extension . 28, 29, 31, 37�39, 57, 58,91, 92, 95, 127

F

Fassade . . . . . . . . . . . . . . . . . . . . . . . . . .31Fat-Client . . . . . . . . . . . . . . . . . . . 19, 20Feature . . . . . . . . . . . . . . . . . . . . . . 26, 40Fragment . . . . . . . . . . . . . . . . . . . . 26, 39

G

Gebrauchstauglichkeit 11, 12, 47, 48,52, 53, 57, 126

GEF . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Genehmigung . . . . . . . . . . . . . . . . . . . .62gra�sche Benutzungsschnittstellen 10Graphical Editing Framework . siehe

GEFGraphical User Interface . siehe GUIGUI 2, 10, 22, 52, 54, 60, 72, 76, 84,

95

H

HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Hardware Abstraction Layer . . siehe

HALHierarchical RBAC . . . . . . . . . . .61�63HTML . . . . . . . . . . . . . . . . . . . . . . . 19, 20HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Hypertext Markup Language . .siehe

HTMLHypertext Transfer Protocol . . siehe

HTTP

Index 155

I

IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Identi�zierung . . . . . . . . . . . . . . . .12�14Identity-Management . . . . .12, 13, 76INCITS . . . . . . . . . . . . . . . . . . . . . . . . . 61individualisierbar . . . . . . . . . . . . . . . . 12Information Technology . . . .siehe ITIntegrated Development Environ-

ment . . . . . . . . . . . . . . . . . . sieheIDE

Interaktionsobjekte . . . . . . . . . . . . . . 10InterNational Committee for In-

formation Technology Stan-dards . . . . . . . . . . . . . . . . . sieheINCITS

International Organization for Stan-dardization . . . . . . . . . . . .sieheISO

International TelecommunicationUnion . . . . . . . . . . . . siehe ITU

Internet Protocol . . . . . . . . . . siehe IPIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65ISO . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 65IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9ITU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

J

J2EE . . . . . . . . . . . . . . . . . . . . . . . 55, 132J2SDK . . . . . . . . . . . . . . . . .66, 132, 136J2SE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55JAAS 2, 4, 55, 56, 58, 60, 66�68, 71,

72, 84, 91, 92, 115, 122, 123,135�137

Java 2 Enterprise Edition . . . . . sieheJ2EE

Java 2 Standard Edition siehe J2SEJava 2 Standard Edition Develop-

ment Kit . . . . . . . . . . . . . . sieheJ2SDK

Java Authentication and Authoriza-tion Service . . . . . . . . . . . sieheJAAS

Java Development Kit . . . siehe JDKJava Naming and Directory Interface

siehe JNDIJava Runtime Environment . . . siehe

JREJava Virtual Machine . . . siehe JVMJDK . . . . . . . . . . . . . . . . . . . . . . . . . 2, 135JNDI . . . . . . . . . . . . . . . . . . . . . . . . 66, 67JRE . . . . . . . . . . . . . . . . . . 132, 135, 136JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

L

LDAP . . . . . 4, 60, 65, 66, 81, 84, 123Lightweight Directory Access Proto-

col . . . . . . . . . . . . . . . . . . . . sieheLDAP

Log-in . 12�14, 48, 49, 55, 72, 84, 89,91, 103, 109, 136, 138, 139

M

MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Mandatory Access Control . . . . siehe

MACModel-View-Controller . .siehe MVCMVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

N

Nutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

O

OASIS . . . . . . . . . . . . . . . . . . . . . . . . 2, 73Open Service Gateway Initiative

siehe OSGiOpenSource . . . . . . . . . . . . . . . 4, 65, 76Open Systems Interconnection siehe

OSI

156 Index

Operation . . . . . . . . . . . . . . . . . . . . . . . 62Organization for the Advancement of

Structured Information Stan-dards . . . . . . . . . . . . . . . . . sieheOASIS

OSGi . .22, 23, 26, 27, 32, 34, 35, 40,58, 79, 133, 138

OSGi-Konsole . . 28, 79, 93, 108, 133,134, 138

OSGi-Manifest . . . . . . . . . . . . . . . 32, 33OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

P

PAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74PDE . . . . . . . . . . . . . . . . . . . . 31, 42, 132PDP . . . . . . . . . . . . . . . . .73, 75�77, 115PEP . . . . . . . . . . . . . . . . . . . . . .73, 75�77Persönliche Identi�kationsnummer

siehe PINPIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14PIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Plug-In Development Environment

siehe PDEPlug-In . . . . . . . . . . . . . . . . . . . . . . . . . . 4,

20�42, 55�59, 78, 79, 84�87,89, 91�98, 102�105, 107�111,113, 114, 118, 119, 126, 127,132, 133, 137�139

Plug-In-(De-)Aktivierung . . . . . 4, 59,78�80, 84, 98, 100, 102, 103,126

Plug-In-Klasse . . . . . . . . . . . . . . . . . . . 34Plug-In-Manifest . . . . . . . . . . . . . 32, 33Policy Administration Point . . .siehe

PAPPolicy Decision Point . . . .siehe PDPPolicy Enforcement Point siehe PEPPolicy Information Point . siehe PIPPolicySet . . . . . . . . . . . . . . . . . . . . . . . . 74Preference Page . . . . . . . . . 94�97, 119

R

RBAC . 2, 4, 13, 60�64, 84, 104, 105RCP-Anwendung . . . . . . . . . . . . . . . 26,

34, 36, 78, 79, 85, 91�93, 96,102, 103, 108, 132�134, 139

RCP . . . . 2�4, 22, 23, 25, 55, 58, 133RCP-Plug-In . . . . . . . . . . . . 26, 93, 137Rich-Client-Anwendung . i, 1, 22�25,

28, 31, 56Rich-Client-Platform . . . . siehe RCPRich-Client 1�3, 8, 19�22, 46, 60, 64,

66, 72, 76, 77, 83, 92Right-Set . . . . . . . . . . . . . . . . . . . . . . . . 81Rights-Management . . . . . 80, 81, 123Role Based Access Control . . . . siehe

RBACRolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74

S

SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . 76SDS . . . . . . . . . 100, 120�122, 124, 125Security-Facade 78, 80�84, 100, 111�

114, 118�122, 125�127, 139Security Assertion Markup Language

siehe SAMLSingle Sign-On . . . . . . . . . . .siehe SSOSingleton . . . . . . . . . . . . . . . . . . . . . . . . 34Sitzung . . . . . . . . . . . . . . . . . . . . . . . . . . 62Sourceforge . . . . . . . . . . . . . . . . . . 56, 76SSD . . . . . . . . . . . . . . . . . . . . . .61, 63, 64SSO . . . . . . . . . . . . . . 13, 18, 55, 67, 76Standard Widget Toolkit siehe SWTStatic Seperation of Duty siehe SSDSWT . . . . . . . . . . . 22, 23, 43, 117, 122Synoptic Display Studio . siehe SDS

T

Target . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Index 157

Taschenrechner . . . . . . . . . . . . . . . . . 111TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Thin-Client . . . . . . . . . 1, 2, 19, 20, 83Transmission Control Protocol siehe

TCPTrigger Point . . . . . . . . . . . .94, 95, 119

U

UI . . . . . . . . . . . . . . . . 22, 30, 37�39, 56Uniform Resource Locator . . . . siehe

URLUpdate-Site . . . . 40�43, 103, 107�110URL . . . . . . . . . . . . . . . 41, 92, 133, 137Usability . . . . . . . . . . . . . . . . . . . . .11, 53User-Management . . . . . . . 80, 81, 123User Interface . . . . . . . . . . . . . siehe UI

V

Verbotsregel . . . . . . . . . . . . . . . . . . . . . 18Verzeichnis . . . . . . . . . . . . . . . . . . . . . . 65Verzeichnisdienst . . . . . . . . . . . . . . . . 65

W

WAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Werkzeug- und Material-Ansatz siehe

WAM

X

X.500 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65XACML . . . . 2, 4, 60, 73�76, 84, 115XML . . . . . . 31, 33, 37, 73, 74, 81, 93

158

Erklärung

Ich versichere, dass ich die vorstehende Arbeit selbstständig und ohne fremdeHilfe angefertigt und mich anderer als der im beigefügten Verzeichnis ange-gebenen Hilfsmittel nicht bedient habe. Alle Stellen, die wörtlich oder sinn-gemäÿ aus Verö�entlichungen entnommen wurden, sind als solche kenntlichgemacht.Ich bin mit einer Einstellung in den Bestand der Bibliothek des Fachbereichseinverstanden.


Unterschrift

Erklärung

Ich versichere, dass ich die vorstehende Arbeit selbstständig und ohne fremdeHilfe angefertigt und mich anderer als der im beigefügten Verzeichnis ange-gebenen Hilfsmittel nicht bedient habe. Alle Stellen, die wörtlich oder sinn-gemäÿ aus Verö�entlichungen entnommen wurden, sind als solche kenntlichgemacht.Ich bin mit einer Einstellung in den Bestand der Bibliothek des Fachbereichseinverstanden.


Unterschrift

Date post:	29-Aug-2019
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Benutzerautorisierung mit Anbindung an die ... · Zusammenfassung Diese Arbeit scha t eine...

Documents