Entwicklung und Implementierung einer ... - GeoBranchen

FAKULTÄT FÜR INFORMATIK
DER TECHNISCHEN UNIVERSITÄT MÜNCHEN
Entwicklung und Implementierung einer
raumbezogenen Zugriffskontrolle für
Geo Web Services
Diplomarbeit im Fach Informatik
vorgelegt von
Jan Herrmann
Abgabedatum 15.03.2005

2
Entwicklung und Implementierung einer
raumbezogenen Zugriffskontrolle für
Geo Web Services
Diplomarbeit im Fach Informatik
vorgelegt von
Jan Herrmann
Aufgabensteller:
Prof. Dr. Johann Schlichter
Betreuer:
Dipl. Ing. Andreas Matheus
Beginn der Arbeit: 15.09.2004
Abgabe der Arbeit: 15.03.2005

3
Kurzreferat
Bei der Nutzung eines Geo Web Services können beliebige Aktionen auf den vom Dienst angebotenen
geographischen Daten ausgeführt werden. Ein gewünschtes Ziel dieser Interaktion
ist, dass ausschließlich autorisierte Zugriffe auf den Geo Web Service genehmigt werden.
Hierfür muss ein Zugriffskontrollsystem eingesetzt werden, in dem Vorschriften zu definieren
sind, unter welchen Umständen ein Subjekt eine gewünschte Aktion auf dem Geo Web Service
ausführen darf. Das Zugriffskontrollsystem nutzt diese Vorschriften, um die Kommunikation
zwischen Nutzer und Dienst inhaltlich zu überprüfen. Da es sich bei den ausgetauschten
Informationen zwischen einem Nutzer und einem Geo Web Service vorwiegend um Daten zu
geographischen Objekten handelt und diese als besonderes Merkmal einen Raumbezug und
eine Ausdehnung haben, ist in diesem Zusammenhang eine spezielle Art der inhaltsabhängigen
Zugriffskontrolle möglich. Es kann unter anderem in Abhängigkeit der Ausdehnung und
Lage eines geographischen Objektes festgelegt werden, ob der Zugriff auf die zugehörigen
Daten genehmigt oder abgelehnt werden soll. Durch diese raumbezogene Zugriffskontrolle ist
es auf einfache Weise möglich, komplexe Autorisationen im Zugriffskontrollsystem zu definieren.
Bisher fehlen Konzepte, wie raumbezogener Zugriffsschutz in einem Zugriffskontrollsystem
für Geo Web Services erreicht werden kann. An dieser Stelle setzt die vorliegende Diplomarbeit
an. Sie beschreibt den Entwurf und die prototypische Implementierung eines Zugriffskontrollsystems,
mit dem eine mächtige, feingranulare, inhaltsabhängige und raumbezogene
Zugriffskontrolle möglich ist.
Zunächst werden gängige Konzepte und Mechanismen zur Realisierung von Zugriffskontrolle
diskutiert. Im Anschluss wird das auf XACML basierende Modell, mit dem lesender und modifizierender
Zugriff auf XML/GML-kodierte geographische Datenobjekte in Abhängigkeit
ihrer Inhalte kontrolliert werden kann vorgestellt. Zuletzt wird die prototypische Implementierung
des herausgearbeiteten Modells beschrieben. Das umgesetzte Zugriffskontrollsystem
wurde am Beispiel des Web Feature Services mit Testdaten und -regeln experimentell validiert
und ist einsatzbereit.

4
FAKULTÄT FÜR INFORMATIK
DER TECHNISCHEN UNIVERSITÄT MÜNCHEN
Aufgabenstellung
Entwicklung und Implementierung einer
raumbezogenen Zugriffskontrolle
für Geo Web Services
Ausgangssituation
Bei einem Geo Web Service handelt es sich um einen Dienst im Internet, der den Zugriff auf
geographische Daten (Geodaten) ermöglicht. Dieser Zugriff kann u.a. folgender Art sein: Einfügen,
Schreiben, Lesen und Löschen. Geht man von einer objektartigen Strukturierung der
Geodaten aus, so kann der Zugriff auf jedes geographische Objekt durch individuelle
Zugriffsrechte gesteuert werden. Ein geographisches Objekt kann einen Raumbezug und eine
Ausdehnung haben, die in einem bestimmten Raumbezugsystem (Spatial Reference System –
SRS) beschrieben sind. Somit kann der Zugriff auf geographische Objekte durch Zugriffsrechte
eingeschränkt werden, die sich auf den Raumbezug der Objekte stützen. Hierzu werden
beispielsweise zweidimensionale Gebiete definiert, für die eine bestimmte Zugriffsbeschränkung
gilt. Eine Zugriffsbeschränkung definiert hier, welches Subjekt (z.B. ein Nutzer) mit
welcher Operation (hier Einfügen, Schreiben, Lesen und Löschen) auf bestimmte Objekte in
diesem Gebiet zugreifen darf. Betrachtet man eine Leseoperation auf dem Geo Web Service,
so wird ein Ergebnis berechnet, das an den Benutzer zurückgegeben werden soll. Die Antwort
auf die Web Service Anfrage besteht aus einer Menge geographischer Objekte, die vom
Zugriffskontrollsystem auf erforderliche Berechtigungen überprüft werden muss, bevor sie an
den Nutzer gesendet werden kann.
Die auf der eXtensible Markup Language (XML) basierende Access Control Markup Language
(XACML) ist ein Standard von OASIS. Sie ermöglicht die Deklaration von Zugriffsrechten,
die den Zugriff auf Ressourcen durch Subjekte festlegen. Sofern von einem XMLkodierten
und daher strukturierten Web Service Anfrage- und Antwortformat ausgegangen
werden kann, erlaubt XACML die Deklaration von inhaltsabhängigen Zugriffsbeschränkun-

5
gen auf Element- und Attributebene. Geographische Objekte, die durch Sachdaten und georeferenzierte
geometrische Objekte definiert sind, können in der Geographic Markup Language
(GML) – einer standardisierten XML Anwendung des Open GIS Consortiums – beschrieben
werden.
Aufgabe der Diplomarbeit
Geographische Informationsobjekte, auch räumliche Features genannt, sollen durch ein GML
Anwendungsschema definiert sein. Basierend auf dieser XSD können Zugriffsrechte an
1. Featuretypen,
2. Featureinstanzen und
3. den Raumbezug der Features gebunden sein.
Die Aufgabe der Diplomarbeit ist es, zum einen ein einfaches Modell einer Zugriffskontrolle
zu entwerfen, das die Optionen 1. bis 3. unterstützt. Insbesondere sollen die raumbezogenen
Zugriffsrechte an zweidimensionale Flächen gebunden werden. Des weiteren sollen die
Zugriffsbeschränkungen für die prototypische Realisierung in XACML formuliert werden.
Die Implementierung soll anhand der in XACML vorgestellten Struktur mit „Policy Enforcement
Point“ (PEP) und „Policy Decision Point“ (PDP) erfolgen. Ein „Policy Administration
Point“ (PAP) soll nicht implementiert werden. Weil XACML keine Sprachelemente und
Funktionen bereitstellt, die Zugriffsrechte basierend auf Raumbezug und Geometrie ermöglichen,
muss eine entsprechende Erweiterung beschrieben werden.
Zur Überprüfung der Implementierung soll ein Web Feature Service (WFS), der räumliche
Abfragen unterstützt, durch einen PEP mit einer Zugriffskontrolle versehen werden. Für diesen
Geo Web Service sollen verschiedene Testszenarien erstellt werden, welche die Implementierung
überprüfen.
Die Realisierung soll in Java erfolgen und die Erweiterungen der Sprache XACML sollen auf
Grundlage von SUNXACML (XACML Implementierung der Firma SUN) umgesetzt werden.
Zur Berechnung raumbezogener Relationen und Operationen soll die Java Topology Suite
verwendet werden.

6
Erklärung
Ich versichere, dass ich diese Diplomarbeit ohne fremde Hilfe selbstständig verfasst und nur
die angegebenen Quellen und Hilfsmittel verwendet habe.
10.03.2005
....................................................................................
Datum Unterschrift

7
Inhalt
Seite
Verzeichnis der Abbildungen...................................................................................................................9
Verzeichnis der Tabellen..........................................................................................................................9
Liste der Abkürzungen...........................................................................................................................10
Verzeichnis der Begriffe und Definitionen ............................................................................................12
1 Einleitung ............................................................................................................................................16
1.1 Motivation ....................................................................................................................................16
1.2 Zielsetzung ...................................................................................................................................18
1.3 Konventionen zum Schriftsatz......................................................................................................18
1.4 Aufbau der Arbeit.........................................................................................................................18
2 Grundlagen..........................................................................................................................................20
2.1 XML Technologien ......................................................................................................................20
2.1.1 XML und XML Schema ........................................................................................................20
2.1.2 Adressierung per XPath und Transformation mit XSL..........................................................21
2.2 Geodaten und GML......................................................................................................................22
2.3 Web Service..................................................................................................................................27
2.4 Geo Web Service..........................................................................................................................28
2.5 Web Feature Service.....................................................................................................................29
3 Zugriffskontrolle .................................................................................................................................33
3.1 Grundlegende Begriffe und Konzepte..........................................................................................33
3.1.1 Subjekt, Aktion und Objekt ...................................................................................................33
3.1.2 Konzepte und Strategien für Zugriffskontrolle bei Web Services .........................................35
3.2 Klassifizierung von Zugriffskontrollmechanismen ......................................................................41
3.2.1 Built-in Ansatz – Integration der Zugriffskontrolle in das DBMS ........................................42
3.2.2 Instance-Tagging Ansatz........................................................................................................43
3.2.3 View-basierte Umsetzung der Zugriffskontrolle ...................................................................44
3.2.4 Statischer Analyseansatz........................................................................................................45
3.2.5 Pre-Processing Ansatz............................................................................................................46
3.2.6 Post-Processing Ansatz..........................................................................................................49
3.3 Eignung der Zugriffskontrollmechanismen für Geo Web Services..............................................52
3.3.1 Eignung des Pre-Processing Ansatzes – evalQuery(merge(Q, R), D) ...................................52
3.3.2 Eignung des Post-Processing Ansatzes – evalRule(R, evalQuery(Q, D)) .............................55
3.3.3 Der Hybridansatz ...................................................................................................................56
3.3.4 Fazit .......................................................................................................................................59
4 Zugriffskontrolle mit XACML............................................................................................................60
4.1 XACML – eXtensible Access Control Markup Language...........................................................60
4.1.1 Was ist XACML? ..................................................................................................................60
4.1.2 Das Sprachmodell des Regelwerkes ......................................................................................63
4.1.3 Der XACML Request und Response Context .......................................................................66
4.2 Zugriffskontrolle für XML Dokumente mit XACML..................................................................68
4.2.1 Die vom PEP generierte globale Zugriffsentscheidungsanfrage............................................69
4.2.2 Varianten zur Weiterleitung der globalen Zugriffsentscheidungsanfrage zu einer
hierarchischen Ressource durch den Context Handler an den PDP.......................................70
4.2.3 Auswertung der individuellen Zugriffsentscheidungsantworten im PEP ..............................74
4.2.4 Modellierung rekursiven Regelverhaltens .............................................................................75
4.2.5 Erweiterung der Mechanismen zur Referenzierung von Attributen aus XACML
Regeln....................................................................................................................................76

8
4.3 Modellierung unterschiedlicher Regeltypen für Geo Web Services ............................................76
4.3.1 Festlegen von Zugriffsregeln auf den Featuretyp ..................................................................77
4.3.2 Deklarieren von Zugriffsregeln für bestimmte Features........................................................82
4.3.3 Fazit .......................................................................................................................................83
5 Raumbezogene Zugriffskontrolle mit XACML ..................................................................................85
5.1 Raumbezogene Zugriffsregeln......................................................................................................86
5.2 Auswerten der topologischen Relationen .....................................................................................93
5.3 Erweiterungen von XACML zur Unterstützung raumbezogener Zugriffskontrolle.....................95
5.3.1 Erweiterung der XACML Attributtypen................................................................................95
5.3.2 Erweiterung der XACML Funktionen ...................................................................................96
5.3.3 Aufbau einer Raumregel ........................................................................................................97
5.3.4 Der RaumInstanz Regeltyp ....................................................................................................99
5.4 Pre-Processing mit XACML.......................................................................................................101
5.4.1 Die Einfügeoperation ...........................................................................................................101
5.4.2 Die Update-Operation..........................................................................................................103
5.4.3 Die Löschoperation..............................................................................................................104
5.4.4 Die Leseoperation ................................................................................................................106
6 Prototypische Implementierung eines Zugriffskontrollsystems für Geo Web Services....................109
6.1 SUNXACML..............................................................................................................................109
6.2 Erweiterungen von SUNXACML ..............................................................................................111
6.2.1 Der Spatial Attributtyp.........................................................................................................111
6.2.2 Topologische und räumliche Funktionen.............................................................................112
6.2.3 Funktionen zum Auflösen der Referenzen in den Regeln auf Daten im XACML Request
Context.................................................................................................................................114
6.2.4 Das Resource Finder Modul zur Unterstützung hierarchischer Resourcen .........................115
6.3 Der PDP......................................................................................................................................117
6.3.1 Implementierung des PDP ...................................................................................................117
6.3.2 Instanzieren der georeferenzierten geometrischen Objekte .................................................118
6.3.3 Auswertung der raumbezogenen Funktionen ......................................................................119
6.3.4 Koordinatensystemüberprüfung und Transformation der Koordinaten...............................120
6.4 Der PEP ......................................................................................................................................121
6.4.1 Generierung der globalen Zugriffsentscheidungsanfrage ....................................................121
6.4.2 Modifikation der Web Service Antwort beim Post-Processing ...........................................123
6.4.3 Erweiterung der Web Service Anfrage beim Pre-Processing ..............................................125
6.5 Validierung der Implementierung...............................................................................................126
7 Zusammenfassung, Evaluierung und Ausblick.................................................................................127
7.1 Zusammenfassung der Arbeit.....................................................................................................127
7.2 Evaluierung und Ausblick ..........................................................................................................128
Literaturverzeichnis..............................................................................................................................130
Anhang A Anwendungsszenario – Die Schweizer Bank .....................................................................136
Anhang A.1 Das den Geodaten zugrundeliegende Datenmodell .....................................................136
Anhang A.2 Beispielanfrage an und Antwort vom WFS .................................................................139
Anhang A.3 Das Regelwerk der Schweizer Bank ............................................................................141
Anhang B Verwendbarkeit topologischer Relationen .........................................................................145
Anhang C Organisiation der XACML PolicySets, Polices und Regeln...............................................147
C.1 Vorgeschaltete Überprüfung inhaltsunabhängiger Zugriffsregeln.............................................147
C.2 Grobstruktur des Regelwerkes bei Web Services ......................................................................148
C.3 Feinstruktur des Regelwerkes ....................................................................................................152
C.4 Organisation der SSOs...............................................................................................................152
C. 5 Regelwerk für die Verwaltung der Zugriffsgesetze der Anwendung .......................................153
C.6 Designprinzipien bei der Deklaration von Zugriffsegeln für XML Dokumente .......................154

9
Verzeichnis der Abbildungen
Abbildung 2.1 Datenfluss bei der Nutzung eines Web Services........................................................... 27
Abbildung 2.2 Nachrichtenfluss bei lesendem Zugriff auf einen WFS................................................ 31
Abbildung 3.1 Schema des Built-in Ansatzes....................................................................................... 42
Abbildung 3.2 Schema des View-basierten Ansatzes........................................................................... 44
Abbildung 3.3 Schema des statischen Analyseansatzes........................................................................ 45
Abbildung 3.4 Schema des primitiven Pre-Processing Ansatzes.......................................................... 47
Abbildung 3.5 Schema des QFilter Ansatzes........................................................................................ 48
Abbildung 3.6 Schema des YFilter Ansatzes........................................................................................ 49
Abbildung 3.7 Schema des evalQuery(Q, D) ∩ evalRule(R, D) Ansatzes........................................... 51
Abbildung 4.1 Datenfluss in einem XACML-basierten Zugriffskontrollsystem.................................. 61
Abbildung 4.2 Klassendiagramm der Sprache XACML...................................................................... 64
Abbildung 5.1 Zwei Geometrien, welche die equals Relation erfüllen................................................ 88
Abbildung 5.2 Zwei Geometrien, welche die disjoint Relation erfüllen............................................... 88
Abbildung 5.3 Zwei Geometrien, welche die intersects Relation erfüllen............................................ 89
Abbildung 5.4 Zwei Geometrien, welche die touches Relation erfüllen...............................................89
Abbildung 5.5 Zwei Geometrien, welche die crosses Relation erfüllen............................................... 90
Abbildung 5.6 Zwei Geometrien, welche die overlaps Relation erfüllen............................................. 90
Abbildung 5.7 Zwei Geometrien, welche die within Relation erfüllen.................................................91
Abbildung 5.8 Zwei Geometrien, welche die contains Relation erfüllen............................................. 91
Abbildung 5.9 „intersection“ Matrix für zwei sich überlappende Polygone......................................... 94
Abbildung A.1 Gebäude-, Straßen- und Bankautomat-Objekte der Schweizer Bank in Zürich......... 138
Verzeichnis der Tabellen
Tabelle 3.1 Vor- und Nachteile des Pre-Processing Ansatzes............................................................... 55
Tabelle 3.2 Vor- und Nachteile des Post-Processing Ansatzes............................................................. 56
Tabelle 3.3 Vor- und Nachteile des Hybridansatzes.............................................................................. 58

10
Liste der Abkürzungen
ACID
ACL
ACT
API
DAC
DBMS
DE-9IM
DES
DTD
FGAC
GIS
GML
GML-QL
HTML
IPSEC
JTS
KNF
MAC
MD5
NFA
OASIS
OGC
PAP
PDP
PEP
PGP
PIP
RDBMS
RSA
SET
SOAP
SQL
SRS
SSL
SSO
UDDI
URL
W3C
WFS
Atomicity Consistency Isolation Durability
Access Control List
Access Control Table
Application Programmers Interface
Discretionary Access Control
DataBase Management System
Dimensionally Extended Nine-Intersection Matrix
Data Encryption Standard
Document Type Definition
Fine-Grained Access Control
Geographic Information System
Geographic Markup Language
GML Query Language
HyperText Markup Language
IP Security Protocol
Java Topology Suite
Konjunktive NormalForm
Mandatory Access Control
Message Digest 5 (Algorithmus von Ron Rivest)
Nondeterministic Finite Automaton
Organization for the Advancement of Structured Information Standards
Open GIS Consortium
Policy Administration Point
Policy Decision Point
Policy Enforcement Point
Pretty Good Privacy
Policy Information Point
Relational DBMS
asym. Datenverschlüsslungsalgorithmus nach Rivest, Shamir, Adelmman
Secure Electronic Transactions
Simple Object Access Protocol
Structured Query Language
Spatial Reference System
Secure Socket layer
System Security Officer
Universal Description, Discovery and Integration
Universal Resource Locator
World Wide Web Consortium
Web Feature Service

11
WSDL
XACML
XML
XPath
XSD
XSL(T)
Web Service Description Language
eXtensible Access Control Markup Language
eXtensible Markup Language
XML Path Language
XML Schema Definition
eXtensible Stylesheet Language (Transformations)

Verzeichnis der Begriffe und Definitionen
12
Autorisation
Jemandem das Recht geben, etwas zu tun oder zu haben (Opincaru 2004).
Datenbasis
Der Begriff Datenbasis stellt eine Abstraktion dar, die stellvertretend für alle zu schützenden
Daten steht. Mit Datenbasis kann eine Menge an statisch vorliegenden XML Dokumenten
und/oder alle Werte einer Datenbank gemeint sein, die verwendet werden, um dynamisch
XML Dokumente zu erzeugen.
Feature
Eine Gruppe von räumlichen Elementen, die zusammen eine Einheit der realen Welt repräsentieren.
Oft synonym mit dem Ausdruck Objekt verwendet. Kann auch zu komplexen Features
(Objekten) zusammengesetzt werden, die aus mehr als einer Gruppe von räumlichen E-
lementen bestehen (nach GI-Lexikon; siehe auch 2.2).
Feingranulare Zugriffskontrolle (fine-grained Access Controll – FGAC)
(siehe 3.1.2)
Geodaten
„Geodaten sind Daten über Gegenstände, Geländeformen und Infrastruktur an der Erdoberfläche,
wobei als wesentliches Merkmal ein Raumbezug vorliegen muss…“ (Schilcher GeoInf1;
siehe auch 2.2).
Geographische Information
(siehe Geodaten)
Geographisches Informationssystem (GIS)
Ein GIS ist „… eine organisierte Zusammenstellung von Computer-Handware, Software,
geographischen Daten und Personal, entworfen um jede Art geographisch referenzierter
Informationen effizient aufzunehmen, zu speichern, instand zu halten, zu aktualisieren, zu
manipulieren, zu analysieren und anzuzeigen.“ (GI-Lexikon).
Geography Markup Language (GML)
Standardisierte Sprache des Open GIS Consortiums für die Kodierung objektstrukturierter
Geodaten auf Basis von XML (siehe auch 2.2).
Georeferenzierung
Die Festsetzung der Beziehung zwischen den ebenen Koordinaten einer Karte und den bekannten
Koordinaten eines geodätischen Bezugssystems (GIS-Glossar, S. 57).

13
Geo Web Service
Ein Geo Web Service ist ein internetbasierter Dienst, der über seine Dienstschnittstelle Funktionalitäten
für die Nutzung von Geodaten () bereitstellt. Die Nutzung von Geodaten umfasst
den Zugriff auf sowie die Erfassung, Manipulation, Transformation und Präsentation
von Geodaten. (nach GI-Lexikon; siehe auch 2.4). Synonyme für den Begriff Geo Web Service
sind Geodienst, Web GIS oder Internet GIS.
Identitätsbasierte Zugriffskontrolle
(siehe 3.1.2)
Inhaltsabhängige Zugriffskontrolle (engl. content dependant access control)
(siehe 3.1.2)
Interoperabilität
Bedeutung nach GI-Lexikon:
“1. Kunstwort, das die Fähigkeit von Rechnern verschiedener Hersteller beschreibt, mit Hilfe
unterschiedlicher Protokolle zusammenarbeiten zu können.
2. Interoperabilität bezeichnet auch die Möglichkeit, verschiedenartige Daten in einen einzelnen
Arbeitsablauf zu integrieren. Dies setzt voraus, dass Syntax und Semantik der Daten dem
Anwender in einheitlicher Form zur Verfügung gestellt wird. Interoperabilität erlaubt den
transparenten Zugang zu mehreren raumbezogenen Daten- und Verarbeitungsressourcen innerhalb
eines einzigen Arbeitsablaufes, ohne sie in einen Datenbestand zu überführen.“
Kontextabhängige Zugriffskontrolle
(siehe 3.1.2)
Namensraum (engl. Namespace)
Ein Mittel, um Elemente und Attribute unterschiedlicher XML Vokabulare zu unterscheiden,
die den selben Namen haben (O’Reilly 2002).
Prädikat
Eine Aussage zu Attributen, die auf Wahrheit geprüft werden kann (XACML Spec 1.1).
Raumbezogene Zugriffskontrolle (engl. spatial access control)
(siehe 3.1.2)
Raumbezugssystem
oder: räumliches/geodätisches Bezugssystem (engl. Spatial Reference System – SRS)
Summe von Definitionen (Koordinatensystem, Passpunkte, Blattschnitte), welche die Semantik
des Lagebezuges räumlicher Objekte in einem GIS ordnen (GIS-Glossar, S. 92; oder vgl.
Definition nach ISO19111).

14
Räumliche Analyse (engl.: Spatial analysis)
Räumliche Analyse stellt in dieser Arbeit einen Oberbegriff dar, mit dem sowohl topologische
Operationen () als auch räumliche Operationen () auf raumbezogene Daten gemeint sind.
Räumliche Operation
In dieser Arbeit wurde definiert, dass zur Gruppe der räumlichen Operationen die folgenden
Funktionen zählen:
• die Funktion zur Berechnung des Flächeninhalts eines Polygons (area)
• die Funktion zur Berechnung der Länge eines Linienzuges (length)
• die Funktion zur Berechnung des räumlichen Abstands (distance)
• sowie die Funktion isWithinDistance
(Details siehe 5.1)
Regelbasierte Zugriffskontrolle (engl. Rule Set Based Access Control – RSBAC)
(siehe 3.1.2)
Rollenbasierte Zugriffskontrolle
(siehe 3.1.2)
Sichere Anfrage
Eine sichere Anfrage (engl. secure Query) ist eine Anfrage an einen Web Service bzw. an eine
Datenquelle, deren Auswertung nur noch rechtmäßig zugängliche Daten liefert (d.h. der
Zugriff auf diese Daten verstößt gegen keine Zugriffsbeschränkungsregel).
System Security Officer (SSO)
Ein Administrator, der dafür zuständig ist, den Zugriff auf die Daten oder die Dienste des
Web Services zu regulieren.
Topologische Operation
Topologische Operationen sind boolesche Methoden, die überprüfen, ob zwischen zwei Geometrien
eine bestimmte topologische Relation besteht (siehe auch 5.1). In dieser Arbeit werden
die folgenden topologischen Operationen betrachtet:
equals, disjoint, intersects, touches, crosses, overlaps, within und contains.
Web Service
siehe 2.3
WFS
siehe 2.5

15
XACML Request Context
XACML-kodierte Zugriffsentscheidungsanfrage
XML
siehe 2.1.1
XML Schema
Ein XML Vokabular, um den erlaubten Inhalt von XML Dokumenten festzulegen (O’Reilly
2002; siehe auch 2.1.1). Eine XML Schemadefinition wird in so genannten XSD Dateien gespeichert.
XPath
Eine nicht-XML Syntax, die von XPointer und XSLT genutzt wird, um Teile eines XML Dokumentes
zu identifizieren (O’Reilly 2002; siehe auch 2.1.2).
XSLT
Eine XML Anwendung, die Transformationen von einem Dokument in ein anderes beschreibt
(O’Reilly 2002; siehe auch 2.1.2).
Zugriffskontrolle (engl. Access control)
Die Zugriffskontrolle prüft, ob ein Anwender, der die Zugangskontrolle passiert hat, berechtigt
ist, mit bestimmten Daten zu arbeiten (GI-Lexikon; siehe auch Kapitel 3).
Zugriffskontrollliste (engl. Access Control List – ACL)
Eine computerimplementierte Liste, die Regeln für einen Zugriffsmechanismus enthält. Damit
kann beispielsweise der Zugriff auf Daten auf bestimmte Nutzergruppen eingeschränkt werden
(GI-Lexikon; siehe auch 3.1.1).
Zugriffsrecht (engl.: permission, authorization, access right und privilege)
Die gezielte Vergabe von Rechten für Benutzer, damit diese die freigegebenen Daten und
Ressourcen im Netzwerk benutzen können (GI-Lexikon; siehe auch 3.1).

16
1 Einleitung
1.1 Motivation
In der heutigen Gesellschaft besteht aufgrund der stetig wachsenden Menge an Informationen
und dem immer weiter voranschreitenden Prozess der Globalisierung ein zunehmender Bedarf
an Informationsaustausch. Durch die Entstehung des Internets ist eine ansprechende Plattform
geschaffen worden, die in vielen wirtschaftlichen und gesellschaftlichen Bereichen zum Austausch
von Daten genutzt werden kann. Technologische Fortschritte im Bereich der Datenübertragung
sowie die Entwicklung von standardisierten Datenformaten, Protokollen und
Softwarekomponenten haben zu einer rasanten Verbreitung und Weiterentwicklung dieses
neuen Kommunikationsmediums geführt.
Zur Kodierung der über das Internet ausgetauschten Informationen hat sich die eXtensible
Markup Language (XML 1 ) als der quasi Standard etabliert. Ein Hauptgrund für die weltweite
Akzeptanz von XML ist die Möglichkeit, mit XML Inhalt und Struktur von Daten standardisiert
zu kodieren, wodurch eine automatisierte, rechnergestützte Verarbeitbarkeit ermöglicht
wird.
Auf Basis dieses universellen Datenaustauschformates ist mit den so genannten Web Services
eine neue Generation von Anwendungen entstanden. Web Services sind ein standardisiertes
Konzept, mit dem Ziel, das Anbieten von interoperablen Daten und Diensten zu erleichtern.
Die Vorteile dieses Konzeptes haben zur Entwicklung vieler, zum Teil verbundener Web Services
geführt, die – sofern erwünscht – für eine breite Masse nutzbar sein können. Die steigende
Anzahl an Diensten im Netz zieht viele neue Nutzer an. Dies wiederum impliziert, dass
es ständig zur Entwicklung neuer Dienste kommt. Dieser Kreislauf wird aber derzeit noch
immer durch fehlende oder nicht ausreichend mächtige Konzepte im Informationsverarbeitungssektor
gebremst (Opincaru 2004). Als Beispiel sind Sicherheitsaspekte bei Web Services
zu nennen.
Da Nutzer und Web Services über das Internet miteinander kommunizieren, läuft der Nachrichtenaustausch
über ein unsicheres Medium. Daher sind Web Services bzw. die Informationsflüsse
zwischen Dienst und Nutzer zahlreichen Bedrohungen wie unautorisierten Zugriffen
(z.B. Abhören, Modifikation oder Löschen), Maskerade, Denial-of-Service, IP-spoofing,
man-in-the-middle Attacke etc. ausgesetzt. Dem gegenüber steht der zunehmende Bedarf an
Sicherheit und Schutz von sensiblen und privaten Daten bzw. Diensten im Netz, für den eine
sichere Kommunikation eine Vorraussetzung ist. Gewünschte Eigenschaften eines sicheren
Datenaustausches sind die Autorisation sowie die Authentifizierung, die Geheimhaltung und
die Nachrichtenintegrität. Abgesehen von der Autorisation sind die geforderten Eigenschaften
1 Eine Liste aller verwendeten Abkürzungen sowie ein Verzeichnis mit Begriffsdefinitionen findet sich auf Seite
10-15.

17
inzwischen durch Verfahren und Systeme wie SSL, IPSec, RSA, DES, MD5, Kerberos, PGP
etc. zufriedenstellend gelöst und für Geo Web Services nutzbar. Es kann daher die Existenz
eines sicheren Datenkanals mit korrekter Authentifizierung des Nutzers vorausgesetzt werden,
wovon auch in dieser Arbeit ausgegangen wird.
Die Autorisationsproblematik dagegen wurde bislang nur sehr rudimentär gelöst, obwohl sie
ebenfalls Voraussetzung für die sichere Nutzung von Web Services ist. Ausschließlich aktionsgebundener
Zugriffschutz auf Dateiebene (z.B. beim Apache Web Server) oder ähnlich
grobgranulare Konzepte, sind für die heutigen XML-basierten Anwendungen nicht mehr ausreichend
mächtig. Begünstigt durch das strukturierte Datenmodell von XML sind neue Autorisationskonzepte
möglich und erforderlich, um auf feingranularer Ebene Zugriffe auf vertrauliche
Daten inhaltsabhängig regulieren zu können. Weiterentwicklungen von Web Services
beschäftigen sich daher unter anderem mit der Umsetzung eines Konzeptes für eine flexible
und effiziente Autorisation, die auf der Sicherheitsschicht aufsetzt.
An diesem Punkt setzt auch die vorliegende Diplomarbeit an. Bislang existieren nur wenige
Konzepte für die Umsetzung einer feingranularen Zugriffskontrolle für XML Dokumente
bzw. Web Services. Für die im Fokus dieser Arbeit stehenden Geo Web Services kommt aufgrund
der speziellen Anforderungen im Geodatenmarkt bezüglich Datenschutz des weiteren
erschwerend hinzu, dass viele dieser Ansätze wegen mangelnder Flexibilität oder Mächtigkeit
unbrauchbar sind. Es existiert derzeit noch kein umfassendes Konzept feingranularer, raumbezogener
Zugriffskontrolle für Geo Web Services bzw. für Geodaten.
Dieser Mangel ist angesichts der flächendeckenden Verfügbarkeit qualitativ hochwertiger
Geodaten, ausgereifter Technik von Geoinformationssystemen und der steigenden Bedeutung
der Nutzung von Geoinformation in Wirtschaft, Verwaltung und Politik besonders unerfreulich
(Schilcher et al. 2004, S. 5). Festzuhalten ist daher, dass trotz der großen Fortschritte im
Geoinformatiksektor weiterer Forschungsbedarf im Bereich der Geo Web Services gegeben
ist. Wie Professor J. Frankenberger und Professor M. Schilcher im Abschlussbericht des Forschungsprojektes
Geoportal (Schilcher et al. 2004, S. 6) betonen, sind vor allem Untersuchungen
zur Zugriffskontrolle für Geo Web Services von besonderer Dringlichkeit.
Hinzu kommt, dass viele Anbieter von Web Services kommerzielle Interessen verfolgen und
daher die Abrechnung von Diensten eine wichtige Rolle spielt. Auch für diesen Bereich kann
durch ein Autorisationssystem, das den Dienstkonsumenten nur die zugänglichen Daten – d.h.
die Daten, für die bezahlt wurde – zur Verfügung stellt, ein Grundstein gelegt werden.

18
1.2 Zielsetzung
Diese Diplomarbeit versucht den Missstand mangelnder Autorisationskonzepte für Geo Web
Services zu beheben, indem das im Rahmen dieser Arbeit entwickelte Konzept für raumbezogene
Zugriffskontrolle und seine prototypische Implementierung vorgestellt wird.
Es werden Lösungsansätze für eine feingranulare, inhaltsabhängige und raumbezogene
Zugriffskontrolle vorgestellt und diskutiert, die als Leitfaden bei der Umsetzung eines mächtigen
Zugriffskontrollsystems für Geo Web Services genutzt werden können.
Hierdurch soll ein Beitrag zum quantitativen und qualitativen Ausbau der Geodateninfrastruktur
erbracht werden. Ziel ist es, den vorhandenen Geodatenbestand für neue Nutzer- und
Dienstanbietergruppen zu erschließen, so dass sich das Marktpotential von Geodaten und
GIS-Technologien besser entfalten kann.
1.3 Konventionen zum Schriftsatz
Zur besseren Lesbarkeit dieser Arbeit wurden Klassennamen, Funktionsnamen, Bezeichner
von XML Knoten, XPath-Ausdrücke etc. in Schreibmaschinenschrift gesetzt. Um
besondere Sachverhalte hervorzuheben, wird zur Betonung fettgedruckte Schrift verwendet.
Literaturangaben werden durch runde Klammern gekennzeichnet und in der Form (Autor
Jahreszahl, Seite) dargestellt.
Um dem Leser eine vertraute Form und Darstellung einer wissenschaftlichen Arbeit zu bieten,
wurden für die Gestaltung dieser Diplomarbeit die Konventionen aus Scholz 2001 verwendet,
die den entsprechenden DIN-Normen genügen.
1.4 Aufbau der Arbeit
Um aufzuzeigen, wie raumbezogene Zugriffskontrolle realisiert werden kann, wurde die vorliegende
Arbeit wie folgt gegliedert.
Abschnitt 2 führt für die Arbeit relevante Begriffe und Technologien aus der (Geo-) Informatik
ein.
Abschnitt 3 geht auf den Prozess der Zugriffskontrolle ein. Es werden gängige Ansätze und
Vorgehensweisen zur Definition und Durchsetzung von Zugriffsregeln be-

19
schrieben und deren Eignung für den Anwendungsfall Geo Web Services analysiert.
Abschnitt 4 widmet sich der konzeptionellen Strukturierung eines Zugriffskontrollsystems.
Auf Basis einer standardisierten Sprache zur Beschreibung von Regelwerken
(eXtensible Access Control Markup Language – XACML) wird gezeigt, wie
inhaltsabhängige Zugriffskontrolle für dynamisch generierte XML Dokumente
bzw. objektartig strukturierten Geodaten erreicht werden kann. Im Fokus dieses
Abschnittes stehen Autorisationen für lesende Zugriffe auf einen Geo Web
Service.
Abschnitt 5 betrachtet, wie raumbezogene Zugriffsregeln festgelegt werden können. Da
XACML hierfür keine ausreichende Funktionalität bietet, wird an dieser Stelle
eine Erweiterung der Sprache zur Unterstützung raumbezogener Zugriffskontrolle
beschrieben. Abschließend wird darauf eingegangen, wie Zugriffskontrolle
für modifizierende Aktionen (einfügen, löschen, updaten) auf einen Geo
Web Service erreicht werden kann.
Abschnitt 6 gibt Einblick in die verwendeten Techniken zur Umsetzung des im Rahmen
dieser Arbeit entwickelten Zugriffskontrollsystems. Es wird gezeigt, wie das
vorgestellte Konzept zur Realisierung raumbezogener Zugriffskontrolle implementiert
werden kann.
Abschnitt 7 fasst die Ergebnisse dieser Arbeit zusammen und gibt einen Ausblick auf mögliche
Weiterentwicklungen.
Anhang A
Anhang B
Anhang C
beschreibt ein fiktives aber realistisches Anwendungsszenario. Im Hauptteil
der Arbeit vorgestellte Lösungsansätze werden durch Beispiele ergänzt, die
sich auf diesen Anwendungsfall beziehen. Dies soll dem besseren Verständnis
der Ausführungen in dieser Arbeit dienen. Zudem finden sich hier weitere Beispiele
auf die an den entsprechenden Stellen der Arbeit verwiesen wird.
gibt Hinweise zur Verwendung topologischer Operationen bei der Definition
von raumbezogenen Zugriffsregeln.
enthält einen Vorschlag, wie ein Regelwerk für Geo Web Services zu definieren
und zu strukturieren ist.

20
2 Grundlagen
2.1 XML Technologien
In diesem Abschnitt wird ein knapper Überblick zur Struktur und zu den Eigenschaften der
eXtensible Markup Language gegeben. XML ist ein vom World Wide Web Consortium 2
(W3C) verabschiedeter, weltweit akzeptierter Standard. Das normative Dokument zu XML
1.0 ist die XML Spezifikation (W3C XML 1.0).
Des weiteren werden in diesem Abschnitt XML Schema und die XML Technologien XPath
und XSLT, die in dieser Arbeit zu tragen kommen, vorgestellt.
2.1.1 XML und XML Schema
XML ist eine mächtige Meta-Auszeichnungssprache und dient zur syntaktischen Repräsentation
von strukturierten Dokumenten. Der Inhalt der Dokumente, die Daten, werden durch so
genannte Tags (Markup) umschlossen, welche die Daten beschreiben und hierarchisch strukturieren.
Dateneinheiten werden durch so genannte Elemente und Attribute ausgezeichnet.
Durch die Schachtelung von Elementen können hierarchisch strukturierte Dokumente aufgebaut
werden. XML Dokumente können als ein Baum von Knoten (z.B. Element-, Attributoder
Textknoten) angesehen werden. Wichtige Konzepte von XML sind die Wohlgeformtheit,
die Erweiterbarkeit, und die Validierbarkeit.
Durch die XML Spezifikation wird unter anderem eine Grammatik festgelegt, die beschreibt,
wie Tags zu verwenden sind. Zusätzlich wird definiert, welchen syntaktischen Anforderungen
die Tags genügen müssen. XML Dokumente, die der XML Spezifikation genügen, werden als
wohlgeformt bezeichnet. Wohlgeformte XML Dokumente sind, da sie der normierten Syntax
genügen, von Parsern lesbar. Diese zerlegen das XML Dokument in seine Basiseinheiten (Elemente,
Attribute usw.) und übergeben diese an weiterverarbeitende Programme.
Unter Erweiterbarkeit versteht man, dass bei der Erstellung von XML Dokumenten ein beliebiges
Vokabular an Elementen und Attributen verwendet und erweitert werden kann. Für bestimmte
Anwendungen kann allerdings – beispielsweise aus Interoperabilitätsgründen – vereinbart
werden, dass nur eine fest vorgegebene Menge an Tags verwendet werden darf. Diese
Menge an Tags wird als XML Anwendung bezeichnet (O’Reilly 2002, Kap. 1.1) und definiert
eine Klasse von XML Dokumenten (z.B. GML oder MathML). Welches Markup in einer
XML Anwendung erlaubt ist, wird durch ein Schema beschrieben. Dokumente, die dem
Schema genügen, werden als gültig oder valide (engl. valid) bezeichnet. Zur Deklaration des
2 eines der führenden Standardisierungsgremien für Internettechnologien

21
Schemas stehen unterschiedlich mächtige XML Schemasprachen zur Verfügung (z.B. Document
Type Definition (DTD) oder W3Cs XML Schema). Durch diese Sprachen wird die
Struktur des XML Dokuments und neue Datentypen, die im Schema verwendbar sein sollen,
beschrieben (Details siehe W3C XML Schema). Konkreter ausgedrückt bedeutet dies, dass
festgelegt wird, welche Elemente und Einheiten an welcher Stelle auftauchen dürfen und wie
deren Inhalt auszusehen hat. Ob eine XML Dokumentinstanz einer Dokumentklasse bzw. einer
bestimmten XML Anwendung angehört, kann über so genannte validierende Parser abgefragt
werden. Diese überprüfen neben der Wohlgeformtheit, ob die XML Dokumentinstanz
unter dem Schema der Dokumentklasse als gültig bezeichnet werden kann. Die Validierbarkeit
von XML Dokumenten macht es möglich, dass der Empfänger eines Dokumentes überprüfen
kann, ob dessen Struktur und Inhalte seinen Erwartungen entsprechen.
Da XML ein einfaches, standardisiertes, automatisiert lesbares und neutrales (d.h. plattformund
sprachenunabhängiges) Dokumentformat ermöglicht, eignet es sich besonders zur Speicherung
und zum Austausch von textbasierten Daten. Die Erstellung von Werkzeugen, welche
XML Daten lesen, schreiben und verarbeiten können, ist aufgrund der Standardisierung,
Textbasiertheit und der Verfügbarkeit von Parsern leicht möglich.
2.1.2 Adressierung per XPath und Transformation mit XSL
Aufbauend auf XML haben sich zahlreiche weitere Standards entwickelt. Dazu zählen die
XML Path Language (XPath) und die eXtensible Stylesheet Language Transformations
(XSLT), die aufgrund ihrer Relevanz für die Arbeit kurz vorgestellt werden sollen.
XPath ist eine nicht XML-basierte Sprache mit der man Teile des hierarchisch aufgebauten
XML Dokumentes adressieren kann. Aus Sicht von XPath ist das XML Dokument ein Baum
mit Knoten. Man unterscheidet zwischen sieben verschiedenen Knotenarten (Element-, Attribut-,
Text-, Kommentar-, Verarbeitungsanweisungs- und Namensraumknoten). Durch so genannte
Lokalisierungspfade – auch XPath-Ausdrücke genannt – kann man beliebig im XML
Dokumentbaum navigieren und Knotenmengen adressieren. Ein Lokalisierungspfad besteht
aus mehreren Lokalisierungsschritten. Durch Prädikate je Lokalisierungsschritt kann man die
selektierten Knotenmengen weiter verfeinern oder Funktionen auf diesen ausführen.
Weiter Informationen zu XPath sind beispielsweise unter W3C XPath 2.0 oder O’Reilly
2002, Kap. 9 zu finden.
Mit XSLT können Regeln zur Transformation von XML Dokumenten, z.B. die Umwandlung
eines XML Dokuments in ein HTML Dokument oder in ein strukturell unterschiedliches
XML-Dokument beschrieben werden. Ein anderer Anwendungsfall für XSLT ist beispielsweise,
eine gewisse Teilmenge an Daten aus einem XML Dokument zu extrahieren.

22
Ein XSLT Dokument, auch Stylesheet genannt, besteht aus einer Liste von Schablonenregeln
(template rules). Jede Schablonenregel enthält ein Muster (per XPath-Ausdruck spezifiziert),
durch das gekennzeichnet ist, für welche Knoten es greift, und zusätzlich Anweisungen zur
Erzeugung einer Ausgabe. Ein XSLT Prozessor liest ein XML Dokument ein und arbeitet das
Stylesheet ab. Wenn der Prozessor im Eingabedokument eine Übereinstimmung mit dem
Muster einer Schablonenregel des Stylesheets erkennt, wird eine Ausgabe gemäß der Anweisung
der Schablonenregel erstellt.
Weiterführende Informationen finden sich beispielsweise unter W3C XSLT 1.0 oder
O’Reilly 2002, Kap. 8.
2.2 Geodaten und GML
Geographische Informationen bzw. geographische Daten – kurz Geodaten (d.h. die datenverarbeitungstechnische
Form von Geoinformation) beschreiben Gegenstände, Geländeformen
und Infrastruktur auf der Erdoberfläche, wobei als wesentliches Merkmal ein Raumbezug vorliegen
muss (vgl. Schilcher GeoInf1, S.2 f). Geodaten bestehen demnach aus
Geometriedaten 3 (geometrische Form und Lage eines Objektes im Raum) und zusätzlich gegebenenfalls
aus Sachdaten (nicht-räumliche Eigenschaften der Objekte). Die räumlichen Eigenschaften
sind durch Angabe eines geodätischen Bezugssystems, auch Raumbezugssystem
genannt (engl. Spatial Reference System – SRS) eindeutig verortet. Ein SRS ist eine mathematische
Methode, um einem Ort auf der Erde Koordinaten zuzuordnen. Es existieren zahlreiche
Raumbezugssysteme (z.B. World Geodetic System (WGS84), Gauss-Krüger Koordinatensystem,
Universale Transverale Mercatorprojektion etc.), die durch einige Parameter, wie
z.B. die Referenzfläche sowie die geodätische Abbildung, vollständig und eindeutig bestimmt
sind. Die Systeme unterscheiden sich indem sie bestimmte Gebiete auf der Erdoberfläche unterschiedlich
gut annähern und dadurch in Abhängigkeit der Lage eines Objektes unterschiedlich
genaue Koordinatenangaben ermöglichen. Ursache für diese Differenzen ist die Tatsache,
dass die Erde mathematisch gesehen ein recht unrundes Gebilde ist, das über unterschiedliche
Ellipsoide angenähert werden kann. Beispielsweise stellt WGS84, das im Jahr 1984 für das
Global Positioning System (GPS) entwickelt wurde, weltweit gesehen die größtmögliche Annäherung
an die Form der Erde dar.
Koordinaten, die sich auf ein bestimmtes SRS beziehen, können durch komplexe Transformationsalgorithmen
exakt in ein anderes System umgerechnet werden, wenn das Ein- bzw. Ausgangssystem,
deren Projektionen und die verwendeten Ellipsoide bekannt sind. Detaillierte
Informationen zu Raumbezugssystemen und geodätischen Transformationen finden sich in
Schilcher GeoInf1, S. 7-13 und Huber 2002, S. 205-214.
3 auch räumliche Eigenschaft(en) oder Rauminformation genannt

23
In dieser Arbeit wird davon ausgegangen, dass das den Geodaten zugrunde liegende Datenmodell
objektbasiert ist. Die Welt wird demnach als eine Oberfläche angesehen, die von unterscheidbaren
Objekten welche einer Objektklasse angehören (z.B. Gebäude, Straßen usw.)
bedeckt ist. Ferner wird angenommen, dass die Geometrien der räumlichen Objekte ausschließlich
zweidimensional sind und in vektororientierter Form vorliegen. In Vektordarstellung
angegebene Geometrien lassen sich auf Linien bzw. Punkte zurückführen und sind somit
allein durch die Angabe der so genannten Führungspunkte vollständig charakterisiert (Bungartz
1996, S.6). Führungspunkte sind durch die Angabe ihrer Koordinaten in einem Raumbezugssystem
eindeutig definiert.
Effizienter Austausch von geographischer Information ist nur dann möglich, wenn sich die
Anwendungen (z.B. geographische Informationssysteme – kurz GIS) an Standards und Normen
im Bereich Geodaten halten. Nur so ist Datenaustausch ohne umständliche Konvertierungen
möglich. Leider existiert noch kein allumfassender Standard zur Beschreibung bzw.
zum Austausch von Geodaten. Beispiel für gängige interoperable Formate zur Speicherung
und zum Austausch von Geodaten sind die Geography Markup Language (GML – eine XML
Anwendung), shape oder tiff Dateien. Für objektorientiert modellierte Geodaten hat sich
GML als quasi Standard zur Kodierung der geographischen Information etabliert. Durch die
dadurch bekannte Struktur der Daten ist es möglich feingranular – d.h. auf Knotenebene – den
Zugriff auf die Daten kontrollieren zu können. Aus diesem Grund wird in dieser Arbeit davon
ausgegangen, dass Geodaten in GML-kodierter Form vorliegen.
Die von OGC standardisierte Geography Markup Language (für diese Arbeit verwendete
Version: OGC GML 2.1.2) ist eine XML Anwendung zur Beschreibung und Kodierung geographischer
Information. Zur Modellierung von Phänomenen auf der Erde wird in der GML
Spezifikation (wie auch in OGC SFS 1.1, JTS Tech Spec 1.4, OGC Filter Spec 1.0) der
Begriff Feature verwendet. Unter einem Feature versteht man die digitale Repräsentation eines
Gegenstandes, einer Geländeform oder einer Infrastruktur auf der Erdoberfläche. Jedes
Feature hat einen Typ, der dem Begriff der Klasse in objektorientierter Ausdrucksweise entspricht.
Der Zustand eines Features ist durch eine Menge an „Eigenschaften“ (engl. properties
4 ) definiert. Eine „Eigenschaft“ kann als ein {Name, Typ, Wert} Tripel betrachtet werden.
Unter einem geographischen Feature versteht man ein Feature, das mindestens eine räumliche
Eigenschaft und beliebig viele nicht-räumliche Eigenschaften (die Sachdaten zu dem Feature)
besitzt. Man spricht von einfachen geographischen Features, wenn die Geometrien, welche
die raumbezogenen Eigenschaften definieren, zweidimensional sind und Kurven in linear interpolierter
Form vorliegen (OGC GML 2.1.2, S. 4). Da beide Bedingungen gemäß der Aufgabenstellung
stets erfüllt sind, werden demnach in dieser Arbeit ausschließlich einfache geographische
Features betrachtet. Zur Verbesserung der Lesbarkeit wird allerdings der Zusatz
einfaches geographisches Feature im Folgenden weggelassen.
4 Der englische Begriff properities wurde bewusst nicht als Attribut übersetzt, um die Verwechslung mit XML
oder XACML Attributen zu vermeiden.

24
Im Kern wird GML durch zwei XML Schemata beschrieben: Das „geometry“ Schema und
das „feature“ Schema (OGC GML 2.1.2, S. 49-62). Die GML Spezifikation bietet ein Framework,
das genutzt werden kann, um benutzerdefinierte XML/GML Anwendungsschemata
zu deklarieren. Technisch gesehen wird dies durch Einbinden der Schemata in feature.xsd,
geometry.xsd und ggf. xlinks.xsd im Schema einer Anwendung des Nutzers erreicht. Dadurch
stehen dem Nutzer standardisierte Basiseinheiten zur Verfügung, mit denen er unter Berücksichtigung
einiger Regeln ein konkretes Anwendungszenario in GML modellieren kann.
In GML werden die Lage und Form der räumlichen Eigenschaften eines Features als zweidimensionale
Geometrien in einem Raumbezugssystem ausgedrückt. Zur Beschreibung der
Geometrien stehen die Datentypen Punkt, Multipunkt, Linenzug, Multilinienzug, Polygon,
Multipolygon oder die heterogene Geometry Collection zur Verfügung, die über einfache
standardisierte Tags umgesetzt sind. In allen Fällen ist zur Geometrie immer das SRS, auf
welches sich die Angaben beziehen, zu spezifizieren.
Punkt:
Ein Punkt ist eine 0-dimensionale Geometrie und repräsentiert genau einen Ort im Raum. Er
wird durch eine X- und Y-Koordinate sowie durch Angabe eines Raumbezugssystems eindeutig
beschrieben. Die Kodierung eines Punktes kann mittels GML wie folgt dargestellt werden:
280,300
Der Wert des srsName Attributes definiert, auf welches Koordinatensystem sich die im coordinates
5 Element angegebenen Koordinaten beziehen. Die Attribute decimal und cs
legen fest, welche Zeichen zur Darstellung des Dezimalpunktes und zum Trennen einzelner
Koordinatenwerte verwendet wurden.
Multipunkt:
Ein Multipunkt ist eine Menge von nicht verbundenen Punkten.
In GML werden homogene Mengen von Geometrien mittels eines MultiGeometrietyp
Elementes kodiert. Dessen Kinder sind eine Menge an geometrietypMember Elementen,
in denen die Geometrien vom Typ geometrietype definiert sind (siehe Codebeispiel für Menge
an Punkt Geometrien).
5 Alternativ könnte auch das coord Element verwendet werden, was in dieser Arbeit allerdings vernachlässigt
wurde.

25
...
...
...
Linienzug:
Ein Linienzug ist eine lineare Interpolation zwischen Punkten. Er wird durch eine geordnete
Menge an verbundenen Punkten beschrieben. Ein Sonderfall eines Linienzuges ist ein linearer
Ring. Bei diesem ist der Start- und Endpunkt des Linienzuges identisch. Ähnlich zum Punkt
werden Linienzüge in GML wie folgt kodiert:
120,280 200,200 320,240 320,300 240,300 240,340
Durch das ts Attribut wird das Zeichen angegeben, das zum Trennen der einzelnen Koordinatentupel
(entsprechend den Punkten, die den Linienzug definieren) verwendet wurde.
Multilinienzug:
Ein Multilinienzug ist eine Menge an nicht verbundenen Linienzügen (Kodierung in GML
siehe Multipunkt).
Polygon:
Ein Polygon ist eine planare Fläche, die durch eine äußere und beliebig viele innere Grenzen
– repräsentiert durch lineare Ringe – definiert ist. Innere Grenzen stellen Löcher im Polygon
dar. Ein Sonderfall eines Polygons ist ein Rechteck, das als so genannte Box bezeichnet werden
kann. Eine Box ist durch die Angabe zweier diagonal liegender Eckpunkte eindeutig bestimmt.
Die Definition eines Polygons mittels GML erfolgt durch Angabe seines äußeren und seiner
inneren Ränder:
140,180 140,240 200,260 220,200 180,180 140,180

26
160,220 180,220 160,200 160,220 160,220
Multipolygon:
Ein Multipolygon ist eine Menge an unabhängigen Polygonen (Kodierung in GML siehe
Multipunkt).
Geometry Collection:
Eine Geometry Collection ist eine heterogene Menge an geometrischen Objekten. Sie kann
aus beliebig vielen Punkten, Multipunkten, Linenzügen, Multilinienzügen, Polygonen und
Multipolygonen bestehen. Die Kodierung in GML kann beispielsweise wie folgt aussehen:
280,300
120,280 200,200 320,240 320,300 240,300 240,340
Wie ersichtlich wird, sind Geometrien bzw. die räumlichen Eigenschaften eines Features, die
mittels GML kodiert worden sind, eindeutig und vollständig definiert. Neben dem Raumbezugssystem,
den Koordinaten und den Trennzeichen ist über die Elemente zugleich der Typ
der Geometrie angegeben.
Im Anhang A wird ein Beispielszenario eingeführt, anhand dessen die in dieser Arbeit vorgestellten
Konzepte exemplarisch demonstriert werden. Unter A.1 findet sich ein kleines Beispiel
für die praktische Nutzung von GML zur Kodierung der Geodaten des Beispielszenarios.
Dort wird durch UML Klassendiagramme das Anwendungsschema vorgestellt und ergänzend
ist unter A.2 eine dem Schema genügende Dokumentinstanz abgedruckt.

27
2.3 Web Service
Das World Wide Web Consortium (W3C) definiert das Konzept Web Service wie folgt:
(W3C DefWS, Abschnitt 1.1):
„A Web Service is a software system identified by a Unified Resource Identifier (URI), whose public
interfaces and bindings are defined and described using XML. Its definition can be discovered
by other software systems. These systems may then interact with the Web service in a manner prescribed
by its definition, using XML based messages conveyed by Internet protocols.”
Web Services fördern das Anbieten und Nutzen von Daten und Diensten in verteilten Umgebungen,
da sie unabhängig von einer Plattform, einem Betriebssystem und einer Programmiersprache
verwendbar sind. Zusätzlich ist von Vorteil, dass Web Services standardisierte
IT-Infrastruktur wie Protokolle, Datenformate, Sicherheitskonzepte etc. verwenden können.
Bei der Nutzung eines Web Services können drei Basiskomponenten identifiziert werden
(vgl. Abbildung 2.1).
Verzeichnisdienst
1. Publizieren 2.Suchen
3. Ergebnis
(WSDL)
Dienstanbieter
4. Anfrage
(SOAP)
5. Antwort
Dienstkonsument
Abbildung 2.1 Datenfluss bei der Nutzung eines Web Services (angelehnt an Hauser 2004, S. 16)
Der Dienstanbieter entwickelt eine Web Service Applikation und publiziert diese bei einem
Verzeichnisdienst („Gelbe Seiten“ für Web Services), damit der Dienst von Suchdiensten gefunden
werden kann.
Ein Verzeichnisdienst stellt eine zentrale Vermittlungsplattform zum Bereitstellen und Auffinden
von Web Services dar. Er ermöglicht den Dienstkonsumenten einen Service nach bestimmten
Kriterien zu suchen.
Der Dienstkonsument (z.B. eine Person oder ein Softwareagent) möchte einen Dienst nutzen.
Hierzu muss er zunächst den gewünschten Service beim Verzeichnisdienst suchen. Vorausgesetzt
er findet einen Dienst mit der benötigten Funktionalität, erhält er vom Verzeichnisdienst

28
Informationen zum Dienst – beispielsweise die Adresse des Dienstanbieters in Form einer
URL. Bei der Nutzung des Dienstes kann dadurch eine direkte Kommunikation zwischen
Dienstkonsument und Dienstanbieter stattfinden, die auf standardisierten Anfragen und Antworten
(in der Regel XML-kodiert) basiert. Der Dienst ist aus Sicht des Nutzers eine Black
Box. Er kennt lediglich die zur Nutzung der Funktionalität benötigten Schnittstellen.
Zur Kommunikation zwischen Dienstanbieter, Dienstkonsument und Verzeichnisdienst sind
standardisierte Protokolle und Nachrichtenformate nötig. Zum Austausch der Anfragen und
Antworten hat sich das auf XML basierende SOAP (Simple Object Access Protocol) durchgesetzt.
Die Beschreibung der Dienste samt ihrer Schnittstellen erfolgt mit der Web Services
Description Language (WSDL). Als Standard für die Methoden des Verzeichnisdiensts zum
Registrieren und Wiederauffinden der Dienste hat sich UDDI (Universal Description, Discovery
and Integration) durchgesetzt. Durch die Festlegung auf herstellerunabhängige Standards
(SOAP, WSDL und UDDI) wird das Nutzen von Web Services sowie die Integration vorhandener
Web Services in neue Anwendungen erleichtert.
2.4 Geo Web Service
Eine besondere Klasse der Web Services sind die so genannten Geo Web Services. Ein Geo
Web Service kann als Geodatenvermittler, -aufbereiter und/oder -verarbeiter angesehen werden.
Geo Web Services bieten unter anderem die Möglichkeit, Geodaten mittels räumlicher
Funktionen (distanz, länge, berührt etc.) abzufragen, zu analysieren oder zu bearbeiten (z.B.
Anfordern aller Daten zu geographischen Objekten, die innerhalb Bayerns liegen).
Das OpenGIS-Consortium (OGC) ist ein Zusammenschluss von Behörden, Universitäten sowie
führenden Herstellern, Anbietern und Anwendern von Geoinformationssystemen und
Geodaten. OGC schafft offene Industriestandards, um Standardisierung und Interoperabilität
im Geodaten- und GIS-Bereich voranzutreiben. Die OGC Spezifikationen (z.B. Web Feature
Service oder Web Map Service Spezifikation) legen unter anderem Schnittstellen und Protokolle
für Geo Web Services fest, die Basis für die Interoperabilität von Geodaten bzw. Geo
Web Services mit anderen Anwendungen sind. Durch die Web Service Technologie sowie die
standardisierten Interfaces der OGC Web Services und GML ist ein einfaches Arbeiten mit
Geodaten im Netz ermöglicht worden. Der zuvor praktizierte Weg der Datenintegration mit
aufwendigen Datenformatkonvertierungsprozessen und Aktualisierungsroutinen gehört seit
dem Einsatz von Geo Web Services der Vergangenheit an.
Besondere Herausforderungen, die ein Geo Web Service zu bewältigen hat, sind:
• die performante Unterstützung räumlicher Anfragen oder Analysen
• die Heterogenität der Geodatenformate (Shape, GML, SDO, TIFF etc.)

29
• die Kopplung der Geodaten an unterschiedliche Raumbezugssysteme
• das Datenvolumen sowie
• die Verteiltheit der geographischen Daten
Mit der Verteiltheit der Geodaten ist gemeint, dass diese in vielen räumlich getrennt liegenden
staatlichen oder privaten Verwaltungseinheiten (z.B. Landesvermessungsämter, Kommunen,
Telekom) erzeugt, gehalten und gepflegt werden. Nur so kann die Aktualität und Qualität
der Geodaten gewährleistet werden. Daher müssen Geo Web Services in der Regel mehrere
heterogene (z.B. RDBMS, XML-DB, Web Service…) und verteilt liegende Datenquellen für
die Bearbeitung der Anfragen „konsultieren“.
Zu den vielfältigen Einsatzmöglichkeiten von Geo Web Services gehören, um nur einige beispielhaft
zu nennen (angelehnt an Leitfaden GIS 2003, S. 12-14):
• Umweltschutz, Katastrophenschutz
• Infrastrukturplanung, Ressourcenmanagement, Raumordnung
• Auskunftsdienste einer Kommune (Gewerbeinformation, Liegenschaftsauskunft etc.)
• Bauleitplanung (z.B. Bebauungsplan, Flächennutzungsplan)
• Ver- und Entsorgung (z.B. Wasser-, Kanalkataster)
• Ökologie (z.B. Bodenqualität, Emission)
• Location-based Services
• ...
Allen Anwendungsbereichen gemein ist, dass Informationen mit Bezug zur Örtlichkeit –
Raumbezug –vorliegen.
2.5 Web Feature Service
Als Beispiel für einen von OGC standardisierten Geo Web Service soll in dieser Arbeit der
Web Feature Service (WFS) betrachtet werden. Ein Web Feature Service ist ein zustandsloser
Dienst, der über das http Netzwerkprotokoll und standardisierte Schnittstellen das Abfragen,
Einfügen, Modifizieren und Löschen von Geodaten, modelliert als GML-kodierte Features
(vgl. 2.3 Geodaten und GML) ermöglicht. Anfragen an den WFS können sich dabei auf beliebige
Eigenschaften der Features stützen, wodurch raumbezogene Selektion von Objektinstanzen
bzw. teilen von Objektinstanzen möglich ist.
Auf eine korrekt formulierte Anfrage (spezifiziert als XML Dokument oder über eine URL)
bearbeitet der WFS die gewünschten Daten zu den Features in seiner zugrunde liegenden Datenbasis
oder extrahiert selektierte Daten, sofern es sich um eine lesende Anfrage handelt und

30
liefert diese z.B GML-kodiert an den Servicekonsumenten zurück. In der WFS Spezifikation
(OGC WFS 1.0.0, S. 3) wird zwischen zwei Klassen des Web Feature Services unterschieden
– Basic WFS und Transactional WFS.
Ein Basic WFS muss die GetCapabilities-, DescribeFeatureType- und GetFeature-
Operationen (s.u.) unterstützen. Durch diese Operationen ist es dem Nutzer des Dienstes möglich,
lesend auf die angebotenen Geodaten zuzugreifen.
Zusätzlich zu den Funktionen des Basic WFS unterstützt der Transactional WFS, wie der
Name schon sagt, auch die Transaction-Operationen (s.u.). Dadurch können über den Dienst
neue Geodaten in die Datenbasis aufgenommen und vorhandene Daten verändert oder gelöscht
werden.
GetCapabilities
Der WFS muss in der Lage sein, seine Fähigkeiten und sein Datenangebot XML-basiert im so
genannten WFS Capabilities Dokument beschreiben zu können, das als Antwort auf die Get-
Capabilities Anfrage an einen WFS generiert wird. In diesem sind unter anderem Informationen
zum Dienst (Version, Name, Beschreibung etc.), zu den verwendbaren Funktionen sowie
allgemeine Informationen zu den bereitgestellten Features (z.B. Name, Titel, Beschreibung,
Koordinatensystem) enthalten. Ein WFS Nutzer weiß anhand der Antwort auf die GetCapabilities
Anfrage, wie er den Web Service ansprechen kann.
DescribeFeatureType
Die DescribeFeatureType Operation dient dem Abrufen detaillierter Informationen zu einem
(oder mehreren) vom WFS unterstützten Feature(s). Der WFS liefert auf eine DescribeFeatureType
Anfrage eine (oder mehrere) GML Schema Definition(en) (XSD Datei), in der die
Struktur der angefragten Featuretypen definiert ist. Dadurch weiß der Web Service Nutzer,
welche Daten zu einem Featuretyp vorhanden sind und auf welche Eigenschaften eines Featuretyps
er seine Anfrage stützen kann. Zudem ist die Struktur der Antwort bekannt, wodurch
die automatisierte Weiterverarbeitbarkeit der Antwort des WFS ermöglicht wird.
GetFeature
Über die GetFeature Anfrage werden gewisse Features oder Teile von diesen aus der Datenbasis
des WFS selektiert und an den Nutzer zurückgegeben. Durch sie wird lesender Zugriff
auf die vom WFS zur Verfügung gestellten Daten ermöglicht. Der Aufbau der Anfrage ist
stark an die SQL Syntax angelehnt. In der Anfrage muss spezifiziert werden, auf welchen
Featuretyp sich die Anfrage bezieht (SQL – z.B. from Gebäude). Zudem kann angegeben
werden, welche Eigenschaften dieses Featuretyps abgerufen werden sollen (SQL – z.B. select
Besitzer, Baujahr ). Durch die zusätzliche Deklaration von Filtern (vgl. OGC Filter
Spec 1.0) werden nur bestimmte Features des angefragten Typs für die Generierung der Antwort
berücksichtigt (SQL – z.B.: where Besitzer=“Schweizer Bank“). In den Filtern können
komplexe logische, arithmetische, vergleichende und räumliche Operatoren gegebenenfalls
kombiniert verwendet werden. Im Anhang A.2 ist exemplarisch eine GetFeature Anfrage auf

31
den WFS des Beispielszenarios abgedruckt. Zusätzlich findet sich dort die auf die Anfrage resultierende
Antwort des Dienstes.
Transaction
Durch die Transaktionsoperationen sind Änderungen an der Geodatenbasis durchführbar. Mit
Hilfe entsprechender Transaktionen können Datenobjekte zu geographischen Features erzeugt,
Daten zu diesen geändert oder gelöscht werden. Als Ergebnis erhält der Nutzer ein so
genanntes WFS_TransactionResponse Dokument, das einen kurzen Statusreport zur abgesetzten
Transaktionsoperation darstellt.
LockFeature
Im Transactional WFS können durch die LockFeature Operation einzelne Features für die
Dauer der Transaktion mit einer Veränderungssperre (Lock) versehen werden. Dadurch können
parallel ablaufende und länger andauernde, modifizierende Aktionen (einfügen, schreiben
und löschen) auf dem WFS koordiniert werden. Die LockFeature Operation ist für die Gewährleistung
des Transaktionsparadigmas (ACID) im Transactional WFS unverzichtbar.
Das unten abgebildetem UML Sequenzdiagram (vgl. Abbildung 2.2) zeigt den Nachrichtenfluss
zwischen dem Nutzer und dem WFS wenn dieser besipielsweise eine GetFeature Operation
auf dem WFS ausführen möchte.
WFS
Abbildung 2.2 Nachrichtenfluss bei lesendem Zugriff auf einen WFS
Aus Sicht eines Zugriffskontrollsystems sind die Operationen GetCapabilities sowie DescribeFeatureType
uninteressant. Sie fragen nur Metadaten vom WFS ab, die keine sensiblen Da-

32
ten enthalten. Sie werden daher im weiteren vernachlässigt. Erwähnt sei allerdings, dass es
zum Schutz vor Denial-of-Service Attacken dennoch sinnvoll sein kann, diese Aktionen auf
Autorisation zu prüfen.
Detailliertere Informationen zum WFS, sowie Beispiele zu den einzelnen Anfragen sind in
der Web Feature Service Implementation Specification (OGC WFS 1.0.0) zu finden.
Zur Illustration des WFS und als Grundlage für sämtliche Beispiele in dieser Arbeit wird im
Anhang A ein Anwendungsszenario vorgestellt. Neben der Beschreibung des Beispielszenarios
und des GML Anwendungsschemas (A.1) ist dort exemplarisch eine GetFeature Anfrage
an den WFS des Anwendungsfalls und die entsprechenden WFS Antworten abgedruckt (A.2).

33
3 Zugriffskontrolle
Unter Zugriffskontrolle versteht man den Prozess der Entscheidungsfindung, ob eine Aktion
auf ein Objekt gewährt oder abgelehnt werden soll. Zugriffskontrolle hat zur Folge, dass ausschließlich
autorisierter Zugriff auf die Objekte stattfinden kann. Durch die Zugriffspolice
wird im Zugriffskontrollsystem die Semantik der Zugriffsrechte festgelegt. Sie steuert das Ergebnis
der Zugriffskontrolle. Auf welche Art und Weise Zugriffsrechte definiert werden können,
ist von dem Konzept der Zugriffskontrolle abhängig. Durch den Zugriffskontrollmechanismus
wird der Zeitpunkt sowie die Technik zur Durchsetzung der Zugriffskontrolle definiert.
In Kapitel 3.1 wird ein Überblick über die wesentlichen Begriffe und Konzepte im Zusammenhang
mit Zugriffskontrolle gegeben. Danach werden in 3.2 verschiedene Zugriffskontrollmechanismen
vorgestellt. Parallel dazu werden die Stärken und Schwächen der Ansätze
aufgeführt. Im Anschluss werden die Mechanismen hinsichtlich ihrer Eignung zur Umsetzung
von Zugriffskontrolle für Geo Web Services betrachtet.
3.1 Grundlegende Begriffe und Konzepte
3.1.1 Subjekt, Aktion und Objekt
Der erste Schritt beim Entwurf eines Zugriffskontrollsystems ist die Identifikation der zu
schützenden Objekte (auch Ressourcen genannt), die Identifikation der Aktionen (z.B. lesen,
modifizieren, löschen) auf den Objekten sowie die Identifikation der Subjekte (aktive Elemente
im System; z.B. Personen, Softwareagenten, Prozesse etc.), die Aktionen auf den Objekten
ausführen. In Abhängigkeit des Anwendungsgebietes können diese Basiseinheiten verschiedenster
Art sein. Im Kontext von Betriebssystemen können Objekte beispielsweise Dateien
oder Prozesse, bei Datenbanken dagegen Tabellen oder ihre Felder sein. Da in dieser
Arbeit Zugriffskontrolle für Geo Web Services betrachtet wird, handelt es sich bei den zu
schützenden Objekten um XML/GML Dokumente (genauer: um durch XPath spezifizierte
Knotenmengen der dynamisch generierten Dokumente – siehe 3.1.2).
Im Zugriffskontrollsystem gilt es Zugriffsrechte festzulegen. Diese drücken aus, wann welches
Subjekt welche Aktion auf welchem Objekt ausführen darf.
Eine Möglichkeit, diese Zugriffrechte konzeptuell zu beschreiben, ist das Zugriffsmatrixmodell.
Das zuerst von Lampson (Lampson 1974, S. 18-24) im Kontext von Betriebssystemen
vorgeschlagene Modell dient zur Festlegung aller in einem Zugriffskontrollsystem existieren-

34
den Autorisationen. Es wurde später von Graham und Denning verfeinert und von Harrison,
Ruzzo und Ullmann (HRU Modell) (Summers 1997) weiter formalisiert.
Wie der Name Zugriffsmatrixmodell schon sagt, werden die Zugriffsmodi in einer Matrix gespeichert.
Die Konfiguration des Zugriffskontrollsystems wird durch ein Dreiertupel (S, O, A) beschrieben.
S steht dabei für die Menge an Subjekten, die Aktionen ausführen können. O stellt die
Menge an zu schützenden Objekten dar. A ist die Zugriffskontrollmatrix, in der eine Zeile ein
Subjekt und eine Spalte ein Objekt repräsentiert. Ein Eintrag in dieser Matrix A[s,o] drückt
die Zugriffsmodi von s 6 auf o 6 aus.
Beispiel einer Zugriffskontrollmatrix:
Datei A Datei B Programm XY
Eva lesen, schreiben ausführen
Max
lesen, schreiben
Paul
lesen
Obwohl das Matrixmodell ein gutes Konzept für ein Zugriffskontrollsystem darstellt, ist es
für Implementierungen nicht direkt geeignet, da der dafür nötige zweidimensionale Array
groß ist und zugleich viele leere Felder enthält. Praktische Implementierungen sind daher:
Autorisationstabelle (engl. Access Control Table - ACT):
Man speichert vorliegende Autorisationen in einer Tabelle mit drei Spalten (Subjekt, Aktion,
Objekt).
Subjekt Aktion Objekt
Eva lesen Datei A
Eva schreiben Datei A
Eva ausführen Programm XY
Max lesen Datei B
Max schreiben Datei B
Paul lesen Datei A
Zugriffskontrollliste (engl. Access Control List - ACL):
In einer ACL wird die Matrix spaltenweise gespeichert. Dies bedeutet, dass zu jedem Objekt
eine Liste gehalten wird, in der zu den jeweiligen Subjekten die Aktionen gespeichert werden,
6 ein Element der entsprechenden Menge

35
die das entsprechende Subjekt auf diesem Objekt ausführen darf (s.u.). Dieses Verfahren wird
beispielsweise in Unix/Linux Betriebssystemen verwendet (Gallagher 1987).
Datei A
Eva
lesen
schreiben
Paul
lesen
nil
Capability Lists:
Die Matrix wird zeilenweise gespeichert. Das heißt, dass je Subjekt eine Liste verwaltet wird,
in der zu jedem Objekt die für ihn ausführbaren Aktionen gespeichert werden.
Eva
Datei A
lesen
schreiben
Programm XY
ausführen
nil
Welche der oben genannten Speichervarianten für die Zugriffskontrollmatrix zu verwenden
ist, hängt vom Anwendungsfall ab. Sowohl die ACLs als auch die Capability Lists haben ihre
Vor- und Nachteile. Mit ACLs können schnell die Autorisationen je Objekt herausgefunden
werden. Möchte man allerdings sämtliche Autorisationen zu einem Subjekt abfragen, dann
müssen zuerst alle ACLs durchsucht werden. Die umgekehrte Situation liegt bei den Capability
Lists vor. Hier sind alle Autorisationen je Subjekt direkt auffindbar. Zur Bestimmung der
Zugriffsrechte zu einem Objekt müssen allerdings alle Capabilities durchsucht werden.
Wie Kapitel 3.1.2 zeigen wird, ist das Matrixmodell allerdings nicht mächtig genug, um Autorisationen,
die in einem Zugriffskontrollsystem für Geo Web Services benötigt werden, beschreiben
zu können.
3.1.2 Konzepte und Strategien für Zugriffskontrolle bei Web Services
Aufgabenstellung dieser Arbeit ist es, ein Konzept zur Realisierung raumbezogener Zugriffskontrolle
für Geo Web Services zu entwickeln. In diesem Kontext handelt es sich bei den zu
schützenden Objekten um dynamisch generierte XML/GML Dokumente, da davon ausgegan-

36
gen wird, dass der Geo Web Service XML als Anfrage- und Antwortformat unterstützt. Ein
GML/XML Dokument ist ein hierarchisches Objekt, das aus vielen Bausteinen – den Knoten
– besteht. Seitens eines Zugriffskontrollsystems kann das Objekt (die XML Datei) unterschiedlich
granular behandelt werden. Man muss zwischen Performance bzw. Administrierbarkeit
und möglichst feingranularer Rechtevergabe abwägen. Je differenziertere die
Zugriffskontrolle umso eher kann ein Nutzer unnötig Zugriff bekommen oder aber der Zugriff
verweigert werden obwohl er ihn benötigt. Demgegenüber werden bei grob granularer
Zugriffskontrolle unnötige Zugriffsrechte vergeben. Idealer weise sollten bei der Festlegung
der Zugriffsrechte ein minimalistisches Prinzip verfolgt werden. Nutzer sollen nur minimale
Zugriffsrechte haben d.h nur zu dem autorisiert sein was sie auch wirklich benötigen und dürfen.
In dieser Arbeit sollen Objekte so detailliert wie möglich geschützt werden, wodurch minimale
Privilegien umsetzbar sind. Das bedeutet für das im Folgenden vorgestellte Zugriffskontrollsystem,
dass für jeden Knoten des dynamisch generierten Dokumentes Zugriffsrechte
deklariert werden können. Man spricht in diesem Zusammenhang von feingranularer
Zugriffskontrolle.
Wie die Zugriffsrechte für die Knoten eines dynamisch generierten XML/GML Dokumentes
beschrieben werden können, hängt davon ab, welches Konzept das Zugriffskontrollsystem
verfolgen soll. Gängige Ansätze sind:
Kontextabhängige Zugriffskontrolle
Unter kontextabhängiger bzw. -basierter Zugriffskontrolle versteht man die Vergabe von
Zugriffsrechten, die abhängig vom Ausführungskontext sind. Der Kontext entspricht dem Zustand
des Systems zum Zeitpunkt des Zugriffs sowie den vorangegangenen Ereignissen. Kontextabhängige
Zugriffsrechtdeklarationen sind beispielsweise:
• Ein Bankangestellter darf nur zwischen 9 und 18 Uhr auf die Kundendaten zugreifen
• Ein Auszubildender einer Bank darf nur 100 Überweisungen pro Tag durchführen
Inhaltsabhängige Zugriffskontrolle
Inhaltsabhängige Zugriffskontrolle ist ein Mittel, um Zugriff von Nutzern auf Objekte in Abhängigkeit
deren Inhalts kontrollieren zu können. Dadurch können gezielt sensible Daten der
Datenquelle geschützt werden. Ein Beispiel für inhaltsabhängige Zugriffsrechtevergabe ist
folgende Autorisation:
Ein Bankangestellter darf den Kontostand der Kunden sehen, wenn er kleiner 10 Millionen
Euro ist.
Der Preis für die Mächtigkeit und Flexibilität inhaltsabhängiger Zugriffskontrolle ist, dass bei
der Zugriffskontrolle die Daten zu allen von der Interaktion betroffenen Objekten gelesen
werden müssen, um eine Zugriffsentscheidung treffen zu können. Außerdem können kompli-

37
zierte Zugriffsrechte ausgedrückt werden, wodurch der Verwaltungsaufwand der Zugriffsrechte
im System ansteigt.
Raumbezogene Zugriffskontrolle
Eine Zugriffskontrolle für Geo Web Services erfordert ebenso die Deklaration von raumbezogenen
Autorisationen. Diese sind ein Sonderfall der inhaltsbezogenen Zugriffskontrolle. Sofern
die zu schützenden Objekte raumbezogene Daten enthalten, können zum Schutz der Daten
zu den Objekten raumbezogene Zugriffsrechte spezifiziert werden, die sich auf die raumbezogenen
Eigenschaften der Objekte stützen. Beispielsweise könnte man festlegen, dass für
Nutzer XY alle Daten zu Gebäudeobjekten, die innerhalb Deutschlands liegen, lesend zugreifbar
sind.
Identitätsbasierte Zugriffskontrolle
Bei der identitätsbasierten Zugriffskontrolle legt ein System Security Officer 7 (SSO) Zugriffsrechte
für alle Subjekt fest. In der Praxis ergibt sich allerdings häufig das Problem, dass es für
den SSO kaum möglich ist zu wissen, was für jeden einzelnen Nutzer erlaubt sein soll, geschweige
denn die Zugriffsrechte dementsprechend zu konfigurieren und aktuell zu halten.
Der Ansatz eignet sich daher eher für die Spezifikation von Zugriffsrechten auf grobgranularer
Ebene. Darunter wird verstanden, dass die durch Zugriffsrechte zu schützenden Objekte
„atomare“ Abstraktionen von Datenmengen darstellen. Das Objekt sind nicht die Knoten des
XML Dokumentes, sondern die XML Datei. Daher existieren in einem grobgranularen
Zugriffskontrollsystem nur wenige Objekte.
Eine Erweiterung der identitätsbasierten Zugriffskontrolle ist das Konzept der Nutzergruppen.
Gruppen stellen hierbei eine hierarchisch organisierte Abstraktion individueller Subjekte dar,
müssen nicht disjunkt sein und können geschachtelt sein. Sie vereinfachen die Verwaltung der
Autorisationen, da eine Autorisation für eine Gruppe den einzelnen Autorisationen für jedes
Mitglied entspricht. Das Konzept der Nutzergruppen kann in analoger Weise auf Objekte und
Aktionen angewendet werden.
Rollenbasierte Zugriffskontrolle
Bei dieser Art der Zugriffskontrolle werden die Zugriffsrechte über Rollen vergeben. Für eine
Rolle wird der Zugriff auf bestimmte Objekte durch gewisse Aktionen festgelegt. Indem jedem
Nutzer einzeln beliebige Rollen zugewiesen werden, bekommt dieser die Zugriffsrechte
der entsprechenden Rollen übertragen. Damit lassen sich die Zugriffsrechte hierarchisch organisieren.
Der Unterschied einer Rolle gegenüber einer Gruppe ist, dass eine Gruppe eine
Menge von Subjekten, eine Rollen dagegen eine Menge an Zugriffsrechten darstellt. Dadurch
7 Ein Administrator, der dafür zuständig ist, den Zugriff auf die Daten oder die Dienste des Web Services zu
regulieren.

38
ergibt sich im Vergleich zur identitätsbasierten Zugriffskontrolle ein Vorteil für die Verwaltung
der Zugriffsrechte, da beim rollenbasierten Ansatz die Zugriffsrechte einer Rolle (z.B.
die Auszubildenden einer Firma) stabiler sind als die Zugriffsrechte eines bestimmten Auszubildendens,
der bei jeder Beförderung mehr Zugriffsrechte bekommt.
Um Ausnahmen in Rollen auszudrücken, müssen neue Rollen festgelegt werden. Je feiner und
komplexer das Regelwerks sein soll, umso mehr verkompliziert sich die Verwaltung der Rollen.
Für detailliertere Informationen zu rollenbasierter Zugriffskontrolle siehe z.B. RBAC
1996.
Regelbasierte Zugriffskontrolle
Ein Regelwerk, auch Police genannt, ist eine Menge an Regeln, welche die Zugriffsrechte eines
Subjekts auf ein Objekt unter gewissen Bedingungen beschreibt (z.B. Ein Bankangestellter
darf den Kontostand der Kunden sehen, wenn er kein Auszubildender ist). Eine Zugriffsregel
ist durch folgendes Tupel definiert:
(Effekt, Subjekt, Aktion, Objekt, Bedingung)
• Effekt (auch Vorzeichen der Regel genannt)
o „Zugriff verboten“ (entspricht negativer Autorisation/Regel, Ablehnung oder engl.
deny)
o „Zugriff erlaubt“ (entspricht positiver Autorisation/Regel, Erlaubnis oder engl.
permit)
o „nicht auswertbar“ bzw. unbestimmt (engl. indeterminate)
• Für welches Subjekt (bzw. für welche Rolle oder welchen Nutzer) gilt die Regel?
• Für welche Aktion gilt die Regel (z.B. lesen, schreiben oder einfügen)?
• Welche Objekte soll die Regel schützen (z.B. Elementknoten im XML Baum)?
• Beliebige Bedingungen (kontextabhängig, inhaltsabhängig etc.), die erfüllt sein müssen,
wenn die Regel angewendet werden soll
Für Regelbeispiele in den Ausführungen dieses Kapitels wird eine Pseudosyntax zur syntaktischen
Repräsentation der Autorisationen verwendet, die dem obigen Tupel entspricht – z.B.
(+, Eva, lesen, /Objekt/Gebäude, falls Werktag). Zur Vereinfachung wird allerdings der Subjekt
und Aktion Teil weggelassen, da er für die Beispiele irrelevant ist.
Zu jeder Aktion eines Subjekts muss in einem regelbasierten Zugriffskontrollsystem zunächst
geprüft werden, ob passende Regeln existieren. Diese müssen dann ausgewertet werden und
je nach Effekt der Regeln kann man die Zugriffsentscheidung bestimmen. Sofern zu einer Aktion
mehrere Regeln greifen, müssen die Effekte der anwendbaren Regeln durch einen zu spezifizierenden
Algorithmus (z.B. deny-overrides, fist-applicable etc.; eine Auflistung mit ausführlicher
Beschreibung findet sich beispielsweise in Jajodia 2001, S. 22 und 23 oder
XACML Spec 1.1, S. 124-132) kombiniert werden, um die Zugriffsentscheidung bestimmen
zu können.

39
Tritt bei der Auswertung einer Regel ein Fehler auf (z.B. eine Bedingung der Regel kann aufgrund
fehlender Informationen nicht ausgeführt werden), so ist der Effekt der Regel „nicht
auswertbar“.
Aus Sicht einer zugriffsgeschützten XML Dokumentinstanz gibt es für jeden Knoten eine
Menge an Regeln, die sich auf diesen beziehen. Andererseits kann sich eine Regel auf einen
oder mehrere Knoten in dem vom Web Service Nutzer angeforderten XML Dokument beziehen.
Regeln werden in einer eindeutig definierten Sprache spezifiziert, die ausreichend mächtig
sein muss, um die benötigten Autorisationen einfach ausdrücken zu können. Neben der Sprache
zur Beschreibung des Regelwerkes muss ein Zugriffskontrollmechanismus zur Durchsetzung
des Regelwerkes existieren. Dieser ist dafür zuständig, bei Aktionen der Subjekte den
Prozess der Zugriffskontrolle, d.h. die Identifikation der relevanten Regeln sowie deren Auswertung,
einzuleiten.
Diskrete und verpflichtende Zugriffskontrolle
Ein weiteres Charakteristikum zur Klassifizierung eines Zugriffskontrollsystems ist die Art
und Weise wie Zugriffsrechte im System vergeben werden. Man unterscheidet zwischen der
Vergabe von Rechten durch die Nutzer bzw. die Eigentümer der Daten (diskrete Zugriffskontrolle
– engl. Discretionary Access Control – DAC) und der systemglobalen Vergabe (verpflichtende
Zugriffskontrolle – engl. Mandatory Access Control – MAC) (vgl. z.B. Gallagher
1987). Bei der DAC Strategie wird die Steuerung des Zugriffs auf die Daten dem Eigentümer
selbst überlassen. Ein bekanntes Beispiel für DAC sind Linux Dateisysteme. Der Besitzer einer
Datei kann den Zugriff auf diese nach Belieben regulieren. Bei der MAC Strategie haben
die Nutzer nicht die Möglichkeit, die Police zu ändern. Ein oder mehrere SSOs legen für das
gesamte System eine verpflichtende Zugriffssemantik fest, die immer erfüllt sein muss. Subjekte
dürfen ihre Zugriffsrechte nicht an andere Subjekte weitergeben (siehe hierzu z.B. Tannenbaum
2002, Eckert 2002, ITSEC 2001).
Regelwerke müssen aber keineswegs entweder die MAC oder die DAC Strategie verfolgen.
Oft bietet es sich an, einen Teil des Regelwerkes verpflichtend – also durch MAC – abzubilden
und den Rest über DAC auszudrücken. Konsequenz der Koexistenz verpflichtender und
diskreter Regeln ist es, dass erstere vorrangig zu behandeln sind, um die MAC Strategie tatsächlich
gewährleisten zu können. In einem regelbasierten Zugriffskontrollsystem sind beispielsweise
sowohl die MAC als auch die DAC Strategie umsetzbar. Zur Koordination der
Vergabe der Zugriffsrechte ist allerdings ein zweites Regelwerk nötig. Dessen Regeln drücken
aus, welche Subjekte welche Zugriffsregeln – dies sind die zu schützenden Objekte – für
die Datenobjekte spezifizieren oder modifizieren dürfen.

40
Neben dem Konzept für das Zugriffskontrollsystem gilt es festzulegen, welches Verhalten ein
Zugriffskontrollsystem, das feingranulare Zugriffskontrolle ermöglicht, bei teilweise unautorisierten,
lesenden Zugriffen eines Nutzers auf Objekte zeigt. Es stehen zwei Alternativen zur
Auswahl, welches Ergebnis ein Zugriffskontrollsystem für einen Web Service an den Servicenutzer
zurückliefern soll, wenn dieser nicht ausreichende Zugriffsrechte besitzt.
1. „So viel wie geht“ Prinzip
Bei einer lesenden Aktion erhält der Nutzer die Schnittmenge aus angefragten und rechtlich
zugreifbaren Daten.
2. „Alles oder nichts“ Prinzip
Als Antwort auf die lesende Aktion erhält der Nutzer eine schlichte Fehlermeldung:
„Zugriff verboten“
Zur Verdeutlichung der Prinzipien folgendes kleines Beispiel:
Ein Bankangestellter will über einen WFS die Daten zu Bankautomaten abrufen. Er ist allerdings
nicht autorisiert die Eigenschaft „kameraüberwacht“ der Bankautomaten Instanzen abzufragen.
Möchte der Bankangestellte nun alle Daten zu den Bankautomaten sehen, so würde
die Zugriffskontrolle nach dem „So viel wie geht“ Prinzip alle Eigenschaften außer „kameraüberwacht“
anzeigen. Bei der „Alles oder nichts“ Alternative dagegen wäre der komplette
Datensatz zu den Bankautomaten zugriffsbeschränkt.
Prinzip 1 stellt im Vergleich zu Prinzip 2 eine Obermenge an Herausforderungen für das
Zugriffskontrollsystem dar. Zudem kann jedes Zugriffskontrollsystem, das Prinzip 1 realisieren
kann, ebenfalls Prinzip 2 unterstützen. Daher wird in dem in dieser Arbeit vorgestellten
Zugriffskontrollsystem das Prinzip 1 gefordert.
Wie die unterschiedlichen Konzepte zeigen, ist das in 3.1.1 vorgestellte Matrixmodell nicht
ausreichend mächtig, um die Zugriffsrechte, die durch regelbasierte Zugriffskontrolle ausgedrückt
werden können (z.B. inhaltsabhängige oder raumbezogene Autorisationen), zu beschreiben.
Mit dem Konzept der regelbasierten Zugriffskontrolle ist es möglich, sowohl kontextabhängige
als auch inhaltsabhängige bzw. raumbezogene Zugriffsrechte zu beschreiben.
Der Bezug zum Kontext oder Inhalt eines Objektes kann in den Bedingungen der Regeln ausgedrückt
werden (z.B. wenn die Aktion von Nutzer XY zwischen 9 und 18 Uhr stattgefunden
hat, dann ist ihm der Zugriff auf ein Objekt A gestattet). Zudem kann die Rechtevergabe zentral
oder dezentral (MAC vs. DAC Strategie) erfolgen. Des weiteren kann mittels regelbasierter
Zugriffskontrolle eine identitätsbasierte oder rollenbasierte Zugriffskontrolle erreicht werden.
Das Subjekt ist dann je nach Ansatz ein Nutzer, eine Gruppe oder eine Rolle. Zur Vereinfachung
der Formulierungen in dieser Arbeit ist stets von Nutzern die Rede. Es ist allerdings
problemlos möglich den Begriff Nutzer mit dem Begriff Rolle oder Gruppe zu ersetzen.

41
Aufgrund der Mächtigkeit regelbasierter Zugriffskontrolle basiert das in dieser Arbeit entwickelte
Zugriffskontrollsystem für Geo Web Services auf diesem Konzept. Neben dem Konzept
des Zugriffskontrollsystems muss ein Mechanismus festgelegt werden, der vorgibt wann
und wie die Zugriffsrechte bzw. –regeln überprüft werden. Hierfür stehen zahlreiche Mechanismen
zur Verfügung, die im folgenden Abschnitt diskutiert werden sollen.
3.2 Klassifizierung von Zugriffskontrollmechanismen
Für das in dieser Arbeit entwickelte Zugriffskontrollsystem wird regelbasierte Zugriffskontrolle
zum Schutz der dynamisch generierten XML/GML Dokumente verwendet. Wie das
Zugriffskontrollsystem die im Regelwerk beschriebenen Autorisationen im Anwendungsszenario
Geo Web Service überprüfen kann, wird durch den Zugriffskontrollmechanismus festgelegt.
Da zahlreiche Zugriffskontrollmechanismen zur Verfügung stehen, sollen zunächst die
populärsten Mechanismen vorgestellt werden.
Bei der Durchführung der Zugriffskontrolle für Web Services sind drei unabhängige Begriffe
von entscheidender Bedeutung.
1. Die Anfrage (engl. Query) Q – diese stellt die Anfrage des Nutzers dar und beschreibt,
welche Datenobjekte von der Interaktion betroffen sind.
2. strukturierte Daten D – z.B. Knoten im XML Dokument
3. Regeln R, welche die Zugriffskontrolle definieren.
Betrachtet man diese drei Begriffe als die Operanden, so kann man dazu drei mögliche Operationen
festlegen (AC Mech 2004, S.6).
• D’ = evalQuery(Q, D)
Der „evalQuery“ Operator stellt die Evaluation einer Anfrage Q auf eine Datenquelle D
dar. Handelt es sich um einen sicheren Query (Definition: seine Auswertung liefert nur
zugreifbare Daten) oder sind D ausschließlich zugreifbare Daten, so sind in D’ nur zugreifbare
Daten.
• D’ = evalRule(R, D)
Der „evalRule“ Operator stellt die Auswertung einer Regelmenge R auf die Datenquelle
D dar. Ergebnis ist eine Datenmenge D’. Dadurch wird die für einen Nutzer zugängliche
Datenmenge beschrieben.
• Q’ = merge(Q, R)
Der „merge“ Operator modifiziert den Query in der Art, dass er nur mehr zugreifbare Daten
zurückliefert. Q’ liefert also eine Datenmenge, die einer Schnittmenge aus angeforderten
und rechtlich zugänglichen Daten entspricht.

42
Diese Operatoren können durch gewöhnliche Mengenoperationen in beliebiger Weise verknüpft
bzw. verschachtelt werden.
Durch dieses syntaktische Beschreibungsmittel kann nun leicht die Grundidee hinter den einzelnen
Varianten der Zugriffskontrollmechanismen beschrieben werden.
Zur Einordnung der unterschiedlichen Mechanismen wird folgende Klassifizierung eingeführt
(angelehnt an AC Mech 2004, S 7):
1. evalQuery(Q, evalRule(R, D)) – Auswertung von Q auf der zugreifbaren Datenmenge
2. evalQuery(merge(Q, R), D) – Erzeugung eines sicheren Q und Auswertung auf D
3. evalRule(R, evalQuery(Q, D) – Überprüfung der Regeln auf den angefragten Daten
4. evalQuery(Q, D) ∩ evalRule(R, D) – Schnitt der zugreifbaren und angefragten Daten
3.2.1 Built-in Ansatz – Integration der Zugriffskontrolle in das DBMS
Query
Web Service
autorisierte Daten
DBMS mit Unterstützung feingranularer,
inhaltsabhängiger
Zugriffskontrolle
Abbildung 3.1 Schema des Built-in Ansatzes 8
Geht man davon aus, dass Web Services ihre Daten in einem DBMS halten, so ist in diesem
die Umsetzung der Zugriffskontrolle möglich. Die Zugriffsrechte werden in ACTs (vgl. 3.1.1)
gespeichert, die im DBMS verwaltet werden. Die Idee ist, jeden Knoten eines XML Dokumentes
– d.h. ein Datenfeld in der DB – mit einer ACT zu verknüpfen. Die Komplexität dieses
Ansatzes steckt zum einen in der Verwaltung der ACTs (ändert sich der Nutzerbestand,
der Datenbestand oder die Zugriffsrechte, so müssen die ACTs erneuert werden), zum anderen
kommt bei jeder Anfrageauswertung ein zusätzlicher Aufwand durch die Auswertung der
relevanten ACTs hinzu. Ungeklärt ist, wie Vererbung von Zugriffsrechten zwischen den Knoten
des XML-Baumes organisiert werden soll oder wie eine Verwaltung der Zugriffsrechte
durch mehrere SSOs realisiert werden kann. Eine detaillierte Ausführung dieser Probleme
8 Für alle Graphiken in diesem Abschnitt wurde eine einheitliche Farbwahl verwendet. Rot markiert auf
Zugriffsrechte zu überprüfende Anfragen bzw. Daten. Blau wurde für Einheiten der Zugriffskontrolle verwendet.
Grün stellt autorisierte Elemente dar.

43
findet sich in Twig Queries 2002. Es stellt sich die Frage, ob Datenbanken eine inhaltsabhängige,
feingranulare Zugriffskontrolle für XML Daten effizient verwalten und unterstützen
können. Bis dato gibt es noch keine kommerziell verfügbaren XML Datenbanken, die eine
umfassende Zugriffskontrolle ermöglichen (AC Mech 2004, S.8).
Ferner ist dieser Ansatz für Web Services aus zwei weiteren Gründen ungeeignet:
1. Es kann nicht davon ausgegangen werden, dass alle (Geo)Daten eines (Geo) Web Services,
ausschließlich aus Datenquellen stammen, die eine integrierte Zugriffskontrolle besitzen.
2. Zugriffsregeln für Web Services beziehen sich auf alle vom online Dienst angebotenen
Daten. Da Dienste oft mehrere Datenbanken verwenden, müssen in jeder eingebundenen
Datenbank alle für den Dienst deklarierten Zugriffsregeln bekannt sein. Bei Datenbanken
einer fremden Organisation ist dies nicht umsetzbar. Es kann daher der Schluss gezogen
werden, dass die Zugriffsregeln auf Web Service Ebene gehalten, gepflegt und umgesetzt
werden müssen.
Gemäß der oben eingeführten Klassifizierung kann man diesen Ansatz der Klasse (1):
evalQuery(Q, evalRule(R, D))
zuordnen.
3.2.2 Instance-Tagging Ansatz
Unter der Vorraussetzung, dass die Zugriffsregeln und XML Daten am gleichen Ort vorliegen,
können die Element- und Attributknoten der XML Dokumente direkt um Sicherheits-
Markup erweitert werden. Ergänzend oder alternativ kann man das XML Schema, welches
den XML Dokumenten zugrunde liegt, ausnutzen, um darin Zugriffsrechte per Sicherheitsmarkup
9 zu deklarieren (Damiani 2001, S. 3). Dadurch sind Autorisationen auf Basis der
Schema-Knoten, unabhängig von der konkreten Dokumentinstanz, möglich. Während
Zugriffsrechte, die sich auf das XML Schema beziehen, besonders geeignet sind, um allgemeingültige
Regeln festzulegen (z.B. Autorisationen, die für eine ganze Firma gelten sollen),
ermöglicht ein Sicherheits-Markup in den konkreten Dokumentinstanzen eine individuelle
Verfeinerung der Zugriffsrechte (z.B. unterschiedliche Einschränkungen je Abteilung).
Wurden die XML Daten und/oder das Schema mit Sicherheits-Markup versehen, dann müssen
bei einer Anfrage auf Knoten im XML Dokument die entsprechenden Zugriffsrechte-Tags
überprüft werden.
Problem dieser Vorgehensweise ist, dass die XML Dokumentinstanzen durch die Tags, welche
die Zugriffsregeln ausdrücken, „verunreinigt“ werden. Zudem ist ersichtlich, dass diese
Variante des Zugriffskontrollmechanismuses für Web Services mit vielen Nutzern und SSOs
und bei sich ändernden Regeln und Datenbeständen schwer umsetzbar ist. Darüber hinaus
9 Tags, die Zugriffrechte ausdrücken (z.B. )

44
muss gewährleistet sein, dass alle Daten und Regeln am gleichen Ort vorliegen, was beispielsweise
bei Geo Web Services selten der Fall ist (vgl. 2.4). Fazit dieser Überlegungen ist,
dass sich dieser Ansatz nicht für Zugriffskontrolle bei (Geo) Web Services eignet.
Wenn auch nicht exakt zutreffend, kann dieser Ansatz am ehesten der Klasse (1):
evalQuery(Q, evalRule(R, D))
zugeordnet werden.
3.2.3 View-basierte Umsetzung der Zugriffskontrolle
Query
Web Service
autorisierte Daten
Views
DBMS
Abbildung 3.2 Schema des View-basierten Ansatzes
Hinter diesem Ansatz verbirgt sich die Idee, für die Nutzer eigene Sichten (engl. Views) auf
die Daten bereitzustellen. In diesen sind exakt die Knoten enthalten, die für den Nutzer zugänglich
sein sollen. Die einzelnen Views können einmalig (offline – also nicht erst zum
Zeitpunkt der Anfrage) berechnet werden und existieren in Abhängigkeit vom Algorithmus,
der die Views bereitstellt, entweder physikalisch oder virtuell (siehe Damiani 2000, Damiani
2002, AC XML 2002). Die Stärke dieses Ansatzes liegt in der schnellen (der Query wird über
einer in der Regel kleineren Datenmenge- die von den Views sichtbar gemachte Datenmenge
– evaluiert) und sicheren 10 Beantwortung der Anfragen, die einfach über die Views ausgeführt
werden. Die Views bieten den Vorteil, dass die Zugriffskontrolle nicht zur Laufzeit der Anfragebearbeitung
ausgeführt werden muss. Bei den zuvor erwähnten Ansätzen muss die Anfrageverarbeitung
des Web Services bzw. des DBMS bei jedem Knotenzugriff feststellen, ob
Zugriff gewährleistet werden soll, was zu einer inakzeptablen Performance führen kann.
Der View-basierte Ansatz entspricht ebenfalls der Klasse (1):
evalQuery(Q, evalRule(R, D)).
10 hier: nur rechtmäßig zugreifbare Daten werden zurückgegeben

45
Die I/O Performance und die Speicherkosten dieses Ansatzes hängen stark von der Anzahl an
Regeln und der Größe der Datenbasen ab. Da die Erzeugung der Views für einen konkreten
Systemzustand offline geschehen kann, ist der dafür benötigte Zeitaufwand weniger kritisch.
Sollte es aufgrund von Millionen Regeln und Benutzern zu Speicherproblemen kommen, so
kann man durch Kompressionsverfahren Abhilfe schaffen (vgl. AC XML 2002).
Nachteile dieses Ansatzes sind:
• hohe Speicherkosten und View-Verwaltungskosten
• Nach jedem Update der Regeln oder der Datenquelle müssen die Views angepasst werden.
• Die Daten und Zugriffsbeschränkungsregeln müssen gemeinsam in einem System gespeichert
sein.
• Die Verwaltung und Umsetzung der Views ist bei einer großen Menge von Nutzern bzw.
Rollen nicht skalierbar.
Der View-basierte Ansatz ist für Web Services ungeeignet, da diese in der Regel eine dynamische
Datenbasis und/oder ein dynamisches Regelwerk und/oder ein großes Datenvolumen
und/oder verteilte Datenquellen und/oder viele Nutzer/Rollen haben.
3.2.4 Statischer Analyseansatz
Query
Query Analyse
3
1 2
Web Service
Web Service
DBMS mit Unterstützung feingranularer,
inhaltsabhängiger
Zugriffskontrolle
autorisierte Daten
keine autorisierten Daten
autorisierte Daten
Abbildung 3.3 Schema des statischen Analyseansatzes

46
Der in StatAnalysis 2003 vorgestellte Ansatz kann als Vorstufe des Pre-Processing Ansatzes
(vgl. 3.1.5) angesehen werden. Hierbei wird die Anfrage an den Web Service vor Auswertung
gegen die Datenbasis auf Anwendbarkeit von Zugriffsregeln untersucht. Ziel ist es, eine unnötige
Belastung des Web Services bzw. der Datenbasis zu vermeiden. Dies wird durch Selektion
von Querys erreicht.
Dabei können drei Fälle auftreten:
1. alle von Q angeforderten Daten sind zugriffsberechtigt
(also evalQuery(Q, D) ⊆ evalRule(R, D) )
Query kann ohne weitere Zugriffskontrollmechanismen ausgeführt und das Ergebnis
an den Nutzer zurückgegeben werden.
2. alle angeforderten Daten sind zugriffsgeschützt
(also evalQuery(Q, D) ∩ evalRule(R, D) = {})
Q muss nicht zur Auswertung an den Web Service weitergereicht werden und der Nutzer
kann direkt von der Ablehnung seiner Anfrage benachrichtigt werden.
3. Q fordert Daten an, von denen nur eine Teilmenge zugänglich ist.
(also evalQuery(Q, D) ∩ evalRule(R, D) ≠ {})
In diesem Fall sieht der Ansatz vor, dass die Datenbasis selbst diejenigen Knoten aus
der Antwort herausfiltert, für die der Nutzer keine Berechtigung hat.
Die Vorgehensweise in Fall 3 stellt die Schwäche dieser Lösung dar, da man weiterhin auf eine
Datenquelle mit integrierter Zugriffskontrolle angewiesen ist. Umgehen könnte man dieses
Problem, indem in Fall 3 der Zugriff verboten wird. Dies würde implizieren, dass keine
Zugriffskontrolle nach dem „So viel wie geht“ Prinzip möglich ist, was aber der Forderung in
3.1.2 (S. 40) widerspricht.
Aufgrund der unterschiedlichen Vorgehensweisen ist der Ansatz sowohl der Klasse 1 (Fall 3)
als auch der Klasse 2 (Fall 1 und 2) zuzuordnen.
3.2.5 Pre-Processing Ansatz
Konzeptionell steckt hinter diesem Ansatz das Prinzip der Klasse 2:
evalQuery(merge(Q, R), D)
Die Zugriffskontrolle wird auf der Anfrage an den Web Service durchgesetzt. Der Query
wird durch Anwendung der Zugriffsregeln in einen sicheren Query Q’ umgewandelt. Die
Auswertung von evalQuery(Q’, D) ergibt daher eine Antwort, die nur zugreifbare Daten enthält.
Bei der Umsetzung des Zugriffskontrollmechanismuses ist das Zugriffskontrollsystem
unabhängig vom Datenformat der Antwort des Web Services sowie von den Datenquellen,
die dem Web Service zugrunde liegen. Diese müssen keine Zugriffskontrolle umsetzen können.
Bei diesem Ansatz können Daten sowie Regeln getrennt und verteilt gespeichert werden.

47
In der Literatur zum Pre-Processing Ansatz (PreProc 2003) wird davon ausgegangen, dass Q
und R durch XPath-Ausdrücke definiert sind. PreProc 2003 identifiziert für diesen Ansatz
zwei verschiedene Vorgehensweisen:
• Primitives Pre-Processing
Query
Query ∩ Regeln
Web Service
autorisierte Daten
Abbildung 3.4 Schema des primitiven Pre-Processing Ansatzes
Die Lösung dieses Ansatzes beruht auf einer simplen Verschneidung der XPath-
Ausdrücke in den Regeln mit dem XPath-Ausdruck in der Anfrage. Das Prinzip der Verschneidung
wird durch folgenden Ausdruck erklärt:
Q’ = (Q geschnitten (Vereinigung aller (R + 11 ))) ohne (Vereinigung aller (R - 12 ))
Der neue erweiterte und jetzt sichere Query Q’ wird dann auf die Datenquelle angewandt.
Da die Auswertung von Q’ gegen D mit Sicherheit nur zugriffsberechtigte Daten zurückliefert,
können diese unmittelbar an den Nutzer zurückgegeben werden.
Folgendes Beispiel soll das Prinzip verdeutlichen:
Anfrage auf Gebäudedaten: Q = /Objekt/Gebäude
R 1 = (+, /Objekt/Gebäude[Besitzer = „Schweizer Bank“])
R 2 = (-, /Objekt/Gebäude[Baujahr ≥ 13 „2003“])
Q’= /Objekt/Gebäude/ intersects /Objekte/Gebäude[Besitzer = „Schweizer Bank“] except
/Objekt/Gebäude[Baujahr ≥ „2003“]
Vorteil dieser Variante des Pre-Processings ist die einfache Implementierbarkeit. Allerdings
ist die Performance stark davon abhängig, wie gut die darunter liegende Datenbank
bzw. der Web Service die Mengenoperatoren (intersect, union und except) umsetzen
kann. Je mehr Regeln zu einer Anfrage greifen, umso mehr Mengenoperationen sind nötig
11 die positiven (zugriffsgewährenden) Regeln des Regelwerks
12 die negativen (zugriffsbeschränkenden) Regeln des Regelwerks
13 Logikausdrücke in dieser Arbeit sind an die Java Syntax angelehnt.

48
und umso langsamer wird daher die Bearbeitung von Q’. (Tests mit Galax als XML Datenbank;
vgl. Ausführungen in AC Mech 2004, S.14/15).
• Das QFilter Verfahren:
Query
QFilter
Q’
Web Service
autorisierte Daten
Abbildung 3.5 Schema des QFilter Ansatzes
Die Anfrage wird unter Betrachtung der Zugriffsregeln ausgewertet. Verstößt der Query
gegen eine (mehrere) Regel(n), so wird er umgeschrieben. Im Gegensatz zum primitiven
Pre-Processing wird die Anfrage nicht nur mit den Regeln verschnitten sondern es werden
unsicheren Anteile der Anfrage eliminiert. Vorausgesetzt wird bei diesem Ansatz, dass
sowohl Q als auch R durch XPath-Ausdrücke definiert worden sind. Mit Hilfe von nichtdeterministischen
endlichen Automaten (engl. Non deterministic Finite Automaton –
NFA) – die so genannten QFilter – wird der Query umgeschrieben. Im Falle von evalQuery(Q,
D) ∩ evalRule (R + , D) = {} ist der QFilter Ansatz besonders effizient, da er die Anfrage
direkt abweisen kann – Q’ entspricht in diesem Fall einer leeren Anfrage. Die Erzeugung
des NFAs, der das Regelwerk repräsentiert, kann dabei einmalig offline geschehen,
vorausgesetzt die Regeln bleiben konstant. Zu erwähnen ist, dass die Kosten der
QFilter-Konstruktion und -Auswertung durch die Komplexität der Regeln beeinflusst
werden. Außerdem impliziert eine Änderung am Regelwerk ein Update am NFA. Prädikate
in den XPath-Ausdrücken werden einfach aneinandergehängt. Optimierung dieser
kombinierten Prädikate wird den Query-Optimierern des Web Services bzw. der darunter
liegenden Datenbank überlassen. Im Vergleich zum primitiven Pre-Processing Ansatz
entsteht auf Grund des Umschreibens von Teilen der vorhandenen Anfrage – nicht nur
Ergänzen der Anfrage – ein deutlich besseres Q’. Es bleibt dennoch offen, wie performant
der Web Service die Auswertung von Q’ bei einer großen Anzahl von Prädikaten (d.h. bei
vielen inhaltsbezogenen Regeln) bewerkstelligen kann.
Um den Unterschied zum primitiven Pre-Processing zu verdeutlichen, soll obiges Beispiel,
erweitert um Anfrage auf alle Straße Objekte, unter Verwendung von QFilter betrachtet
werden:
Q= /Objekt/Gebäude/ and /Objekt/Straße

49
R 1 = (+, /Objekt/Gebäude[Besitzer = „Schweizer Bank“])
R 2 = (-, /Objekt/Gebäude[Baujahr ≥ „2003“])
R 3 = (-, /Objekt/Straße)
Q’=/Objekt/Gebäude[(Besitzer = „Schweizer Bank“) and (not (Baujahr ≥ „2003“))]
3.2.6 Post-Processing Ansatz
Bei Ansätzen dieses Typs werden lesende 14 Anfragen an den Web Service unbearbeitet gegen
die Datenbasis ausgewertet. Die Überprüfung von Zugriffsrechten erfolgt erst auf der Antwort
des Web Services, die – sofern zugriffsbeschränkte Daten enthalten sind – entsprechend
modifiziert werden muss. Dazu muss für jedes Datum der Antwort überprüft werden, ob passende
zugriffsbeschränkende Regeln existieren. Dieser Mechanismus ist daher nur dann für
eine feingranulare Zugriffskontrolle verwendbar, wenn die Antwort des Web Services strukturiert
ist und die zu schützenden Objekte noch einzeln identifizierbar sind (z.B. Knoten eines
XML Dokumentes). Unterschiede zwischen den einzelnen Varianten des Post-Processing Ansatz
ergeben sich durch die Art und Weise, wie die zugriffsbeschränkten Daten aus der Antwort
gefiltert werden. Beispiele sind:
• Yfilter Post-Processing – entspricht evalRule(R, evalQuery(Q, D)) (Klasse 3)
Query
Web Service
beliebige Daten
YFilter
autorisierte Daten
Abbildung 3.6 Schema des YFilter Ansatzes
14 Bei modifizierenden Anfragen ist dieser Ansatz in der Regel nicht möglich.

50
Es wird von XML-kodierten Daten ausgegangen und die von Zugriffsregeln betroffenen
Knotenmengen werden durch XPath-Ausdrücke definiert. Q wird ohne jeglichen
Zugriffskontrollmechanismus auf D ausgeführt – evalQuery(Q, D). Als Folge können im
vorläufigen Ergebnis zugriffsgeschützte Daten auftauchen, die in einem zweiten Schritt –
evalRule(R, D’) – herausgefiltert werden müssen. Das Herausfiltern der zugriffsbeschränkten
Daten erfolgt bei dieser Variante durch so genannte YFilter 15 , die einen offline
erzeugten NFA für eine effiziente Filterung von XML Daten nutzen. Basis für die Konstruktion
des NFAs sind die Regeln (einfache XPath-Ausdrücke). Beim ereignis-basierten
Parsen des XML Dokumentes werden die Grammatiken des Automaten (d.h. also die
Transitionen) durchlaufen und es kann knotenweise eine Zugriffsentscheidung getroffen
werden (detaillierte Ausführungen siehe YFilter 2003, Altinel 2002, Diao 2003).
Auch dieser Ansatz wirft Probleme auf:
o Er ist ineffizient, wenn ein Großteil der angeforderten Daten zugriffsgeschützt ist.
Diese Ineffizienz fällt noch stärker ins Gewicht, wenn evalQuery(Q, D) und eval-
Rule(R, D’) verteilt ausgeführt werden. Die Qualität dieses Verfahrens ist also
stark vom Anteil zugriffgeschützter Daten nach evalQuery(Q, D) abhängig.
o Die Vorgänger zu den angeforderten Knoten müssen im Ergebnis vorkommen, da
es sonst zu einer Sicherheitslücke kommt. Zur Verdeutlichung folgendes Beispiel:
Der Query sei /Objekt/Straße/Name
Die Regel lautet
(-, /Objekt/Straße). Liefert der Query als Ergebnis nur eine Menge an Knoten
Name, so kann die Regel, die nur die Objekte vom Typ Straße zugriffsbeschränken
soll, nicht mehr korrekt umgesetzt werden. Grund ist, dass die Auswertung der
Anfrage nur eine Menge an Namenknoten zurückliefert und daher nicht mehr entschieden
werden kann, ob die Regel greifen soll oder nicht. Aus diesem Grund
müssen im Ergebnis der Anfrage immer alle Vorfahrenknoten enthalten sein.
o Die Performance beim Herausfiltern der zugriffsgeschützen Daten ist von der
Komplexität der Regeln abhängig.
15 engl. Yet another FILTER tool (YFilter 2003, S. 3)

51
• evalQuery(Q, D) ∩ evalRule(R, D) (Klasse 4)
Query
Web Service
beliebige Daten
R +
Web Service
zugreifbare Daten
R –
Web Service
zugriffsbeschränkte Daten
Schneiden
autorisierte Daten
Abbildung 3.7 Schema des evalQuery(Q, D) ∩ evalRule(R, D) Ansatzes
Bei diesem Ansatz wird das angeforderte XML Dokument mit dem XML Dokument, das
die entsprechenden zugreifbaren Daten beinhaltet, „geschnitten“. Diese Variante ist allerdings
nur durchführbar, wenn die Domänen unter dem „intersects“ Operator kompatibel
sind. Damit ist gemeint, dass das Schneiden von XML Dokumenten nur dann möglich ist,
wenn die aus evalQuery(Q, D) und evalRule(R, D) resultierenden XML Dokumente dem
gleichen Schema genügen (vgl. AC Mech 2004, S.7 und PreProc 2003, S. 7). Weiterer
Nachteil ist das Auswerten von evalRule(R, D). Dieses entspricht prinzipiell dem Erzeugen
einer View. Daher gelten für diesen Ansatz ebenfalls die bereits unter 3.1.3 aufgeführten
Nachteile.

52
3.3 Eignung der Zugriffskontrollmechanismen für Geo Web Services
Um effiziente und korrekte Zugriffskontrolle für Geo Web Services umsetzen zu können,
müssen die speziellen Anforderungen und Rahmenbedingungen dieses Anwendungsgebietes
berücksichtigt werden. Dadurch wird die Auswahl der zur Verfügung stehenden Alternativen
an Zugriffskontrollmechanismen stark eingeschränkt.
Folgende Kriterien spielen bei der Wahl des Zugriffskontrollmechanismuses für Geo Web
Services eine entscheidende Rolle:
• verteilte heterogene Datenquellen
• Dynamik der Regeln, der Datenbasis und des Nutzerbestandes
• Komplexität feingranularer, inhaltsabhängiger und raumbezogener Regelwerke
• großes Datenvolumen
• heterogene Antwortdatenformate
• viele Nutzer/Rollen
• Aktionen auf einem Geo Web Service, die auf Zugriffsrechte zu überprüfen sind, können
einfügen, lesen, schreiben oder löschen sein.
• Raumbezogene Anfragen an den Geo Web Service sollen unterstützt werden.
• Das Regelwerk soll sich auf die Geodaten beziehen und soweit möglich unabhängig vom
konkreten Geo Web Service sein (Ziel: Wiederverwendbarkeit des Regelwerkes).
Der View-basierte Ansatz, der Instance-Tagging Ansatz sowie Ansätze, die eine Unterstützung
der Datenbank bei der Zugriffskontrolle erwarten (Built-in und statischer Analyseansatz),
werden wegen der bereits unter 3.1 erwähnten Gründe ausgeschlossen.
3.3.1 Eignung des Pre-Processing Ansatzes – evalQuery(merge(Q, R), D)
Die Unabhängigkeit von der Art, Anzahl und Lage der Datenquellen des Web Services sowie
die Irrelevanz des verwendeten Formates der Antwortdaten machen den Pre-Processing Ansatz
für feingranulare Zugriffskontrolle in Geo Web Services besonders interessant. Für ein
Pre-Processing spricht zudem, dass die Hardwarekomponenten, welche die Funktionalität des
Web Services umsetzen, nicht unnötig durch unauthorisierte Anfragen belasten werden. Eine
weitere Stärke des Ansatzes ist, dass mit ihm Autorisationen für lesende und modifizierende
Aktionen (einfügen, schreiben, löschen) auf den Daten eines Web Services überprüft werden
können.

53
Entscheidend für den Einsatz ist die Frage, ob die merge(Q, R) Operation realisierbar ist.
Durch die merge(Q, R) Operation wird die Semantik der Zugriffsregeln mit der Anfragesemantik
verknüpft. Hierfür ist es nötig, die zu einer Anfrage passenden Regel zu identifizieren.
Im Anschluss kann die Anfrage durch die in der Regel ausgedrückte Semantik modifiziert
werden. In den Ausführungen zu diesem Ansatz wird stets davon ausgegangen, dass sowohl
die Queries als auch die Zugriffsregeln Datenmengen über XPath-Ausdrücke spezifizieren.
Die Verwendung von XPath-Ausdrücken zur Deklaration von Anfragen oder Zugriffsregeln
ist allerdings für Geo Web Services nicht ausreichend mächtig.
Wie im Unterpunkt 2.4 bereits erwähnt wurde, müssen Geo Web Services räumliche Abfragen
(z.B. /Gebäude [die alle innerhalb Bayerns liegen]) unterstützen. Zudem muss in einem
Zugriffskontrollsystem für Geo Web Services die Möglichkeit bestehen, raumbezogene
Zugriffsregeln (z.B. alle Gebäude in München sind zugriffsbeschränkt) umsetzen zu können.
Zur Erfüllung dieser beiden Forderungen bietet XPath keine ausreichende Funktionalität. Man
kann zwar durch die Lokalisierungsschritte beliebige Knoten in den GML-kodierten Geodaten
adressieren, allerdings ist man Restriktionen bei der Formulierung von Prädikaten zu einem
Lokalisierungspfad unterworfen, da XPath 2.0 in seiner aktuellen Spezifikation in Prädikaten
keine vordefinierten, standardisierten, raumbezogenen Funktionen zulässt.
Um den Pre-Processing Ansatz dennoch für Geo Web Services adaptieren zu können, bieten
sich folgende Vorgehensweisen an:
1. Die Regeln werden angepasst an das Anfrageformat des Web Services definiert, wodurch
eine Realisierung der „merge“ Operation vereinfacht wird. Allerdings entsteht
durch dieses Vorgehen eine Abhängigkeit zwischen dem Regelwerk und einem bestimmten
Web Service.
2. Die Anfrage des Geo Web Services wird in XPath-Ausdrücke umgewandelt, die um benutzerdefinierte
räumliche Funktionen erweitert wurden. Zur Definition der Regeln werden
ebenfalls um benutzerdefinierte räumliche Funktionen erweiterte XPath-Ausdrücke
verwendet.
Die „merge“ Operation wird dann auf der transformierten Anfrage und den greifenden
Regeln ausgeführt. Der modifizierte, nun sichere Query Q’ kann nach Rücktransformation
in das ursprüngliche Query Format der Web Service Anfrage an den Web Service
weitergeleitet werden.
Unterschied der beiden Varianten ist, dass sie syntaktisch unterschiedlich aufgebaute Regelwerke
fordern. Variante 2 ermöglicht durch eine Abstraktionsebene die Unabhängigkeit des
Regelwerkes vom Web Service. Zur Definition der Regeln werden allerdings XPath-
Ausdrücke, um benutzerdefinierte räumliche Funktionen erweitert, die in den Prädikaten zum
Einsatz kommen, verwendet. Diese müssen den Anforderungen beliebiger Geo Web Services
genügen. Voraussetzung für Variante 2 ist demnach die Existenz einer mächtigen Sprache,
die das raumbezogene Selektieren von Daten in GML-kodierten Geodaten unterstützt. Diese

54
Sprache muss die Möglichkeit bieten, räumliche Relationen und Operationen (wie z.B. berührt,
schneidet, liegt innerhalb, gleich, sowie Distanz, Länge, Volumen, usw.) formulieren zu
können. Bis dato existiert allerdings noch keine standardisierte Spatial Query Sprache für
GML/XML Dokumente. Ausweg bietet daher entweder die Erweiterung einer vorhandenen
Query Sprache (vgl. GML-QL 2002) oder die Definition einer neuen Spatial Query Sprache
(vgl. Córcoles 2002). Diese Sprachen können zur Definition der Regeln und als Abstraktionsformat
der transformierten Web Service Anfragen verwendet werden. Die unterschiedlichen
Anfrageformate der Web Services müssen durch ein vom Web Service abhängiges Modul ins
Abstraktionsformat transformiert werden. Da die Einheit im System, die als Einsprung in die
Zugriffskontrolle dient, ohnehin zu einem konkreten Web Service passen muss, stellt das Web
Service abhängige Modul zur Transformation der Anfrage kein neues Problem dar.
Vorteil der Variante 2 gegenüber der Vorgehensweise 1 ist, dass das Regelwerk unabhängig
vom Anfrageformat eines konkreten Web Services bleibt. Dadurch kann erreicht werden, dass
unterschiedliche Web Services, die auf den selben Daten operieren, das gleiche Regelwerk
verwenden können.
Da noch keine offiziell verabschiedete, standardisierte Spatial Query Sprache veröffentlicht
wurde, die Aufgabenstellung der Arbeit nicht fordert, dass das Regelwerk für beliebige Web
Services wieder verwendbar sein soll und Variante 1 die im gegeben Zeitraum leichter umzusetzende
sowie die einfacher zu vermittelnde Lösung für raumbezogenes Pre-Processing darstellt,
wird nur diese im Folgenden betrachtet. Betont sei, dass die Umsetzung der Variante 2
nur ein anderes Regelformat und Transformationen von und in die Abstraktionssprache benötigt.
Die Umsetzung der Variante 2 sollte daher auf Basis der hier vorgestellten Variante 1
leicht möglich sein.
Eine Zugriffskontrolle mit Umsetzung über den Pre-Processing Ansatz setzt voraus, dass der
Web Service den modifizierten, dann sicheren Query korrekt auswertet. Das Zugriffskontrollsystem
kann daher nie mit hundertprozentiger Sicherheit sagen, ob der Nutzer wirklich nur
Zugriff auf für ihn autorisierte Daten hat. Der Grund für die Ungewissheit ist, dass der Web
Service die Anfragen eventuell nicht exakt beantwortet. Der WFS beispielsweise ergänzt Anfragen
so, dass die Antwort zu dem verwendeten Schema ein gültiges XML Dokument ist.
Können die für einen Web Service zuständigen SSOs allerdings davon ausgehen, dass alle
Anfragen vom Web Service korrekt beantwortet werden und dass aus der Anfrage ersichtlich
ist, welche Daten letztendlich an den Nutzer übermittelt werden (siehe hierzu 5.4.4), dann ist
gewährleistet, dass der Nutzer nur für ihn zugreifbare Daten erhält.
Neben der Abhängigkeit der Zugriffskontrolle von der korrekten Funktionsweise des Web
Services hat der Pre-Processing Ansatz noch eine weitere Schwäche. Greifen zu einer Anfrage
viele Regeln mit umfassenden Bedingungen, so kann die modifizierte Anfrage sehr komplex
werden. Er enthält dann nicht nur viele, sondern auch aufwendig auszuwertende Prädika-

55
te (z.B. topologische Relationen). Ob die Bearbeitung der modifizierten Anfrage unter starken
Performanceeinbußen im Vergleich zur Original-Anfrage zu leiden hat, ist abhängig von der
Arbeitsweise des Geo Web Services sowie von der darunter liegenden Datenquelle.
Zusammenfassend sind in Tabelle 3.1 die Vor- und Nachteile des Pre-Processing Ansatzes
zur Umsetzung der Zugriffskontrolle für Geo Web Services aufgeführt:
Vorteile
• Schutz des Web Services vor überflüssigen
Arbeiten
• Unabhängigkeit vom Antwortformat des
Web Services
• Zugriffskontrolle für die Aktionen „einfügen,
lesen, schreiben“ auf dem Geo Web Service
sind möglich.
Nachteile
• Sicherheitslücke bei Fehlverhalten des Web
Services
• Transformation der Anfrage in mächtige
räumliche Anfragesprache nötig oder Abhängigkeit
des Regelwerkes von einer konreten
Web Service Anfragesprache
• Modifikation der Anfragen in sichere Queries
komplexere Queries, die eine unperformante
Auswertung durch den Web Service
bzw. durch die darunter liegende DB zur
Folge haben können
Tabelle 3.1 Vor- und Nachteile des Pre-Processing Ansatzes
Aufgrund der oben aufgeführten Schwächen erscheint es sinnvoll, eine Alternative zum Pre-
Processing aufzuführen.
3.3.2 Eignung des Post-Processing Ansatzes – evalRule(R, evalQuery(Q, D))
Schwachpunkt dieser Vorgehensweise ist, dass der Anteil zugriffsgeschützer Daten bis zum
Zeitpunkt der eigentlichen Zugriffskontrolle mitgeführt wird. In Szenarien, in denen die Auswertung
der Web Service Anfrage und die Umsetzung der Zugriffskontrolle räumlich verteilt
ablaufen, ist dieser Ansatz besonders ineffizient. Man stelle sich eine 1 GB große Antwort auf
eine Web Service Anfrage vor, von der nur ein Prozent rechtmäßig zugreifbar ist. Der Web
Service erledigt nicht nur unnötig viel Arbeit bei der Generierung der Antwort, sondern das
Zugriffskontrollsystem muss zudem daraufhin die zugriffsbeschränkten Daten gleich wieder
aus der Antwort herausfiltern.
Dieser Zugriffskontrollmechanismus ist nur dann eine Alternative zum Pre-Processing, wenn
oben erwähnter Schwachpunkt nicht stark ins Gewicht fällt. Dies ist beispielsweise dann der
Fall, wenn der Anteil der zugriffsbeschränkten Daten unter allen abfragbaren Daten gering ist
oder die Auswertung der Web Service Anfrage und Überprüfung der Zugriffsregeln innerhalb
eines Rechners umgesetzt sind.

56
Sofern Zugriffskontrolle auch für modifizierende Aktionen unterstützt werden soll, genügt
das Post-Processing alleine nicht den Anforderungen. Zu diesen Aktionen gibt der Web Service
in der Regel keine Antwort zurück, die detaillierte Informationen über die getätigte Aktion
liefert. Selbst wenn dem so wäre, dann müsste das Zugriffskontrollsystem im nachhinein
die Änderungen rückgängig machen, was ohne aufwendige Recovery Komponenten in den
Web Services nicht erreicht werden kann. Als Konsequenz ergibt sich, dass Zugriffskontrollsysteme,
die sowohl lesende wie auch modifizierende Aktionen auf ausreichende Autorisationen
überprüfen, entweder nur Pre-Processing oder sowohl Pre-Processing (Kontrolle der modifizierenden
Aktionen) wie auch Post-Processing (Überprüfung der lesenden Zugriffe) verwenden
müssen.
Für das Post-Processing können folgende Vor- und Nachteile zusammenfassend dargestellt
werden:
Vorteile
• Zugriffskontrollmodul kann mit Sicherheit
sagen, dass nur autorisierter Zugriff möglich
ist.
Nachteile
• Ist besonders ineffizient, wenn der Anteil
zugriffsbeschränkter Daten zu einer Web
Service Anfrage groß ist. Dies fällt besonders
ins Gewicht, wenn Web Service und
Zugriffskontrollsystem räumlich verteilt liegen.
• Belastung des Web Services durch unautorisierte
Anfragen
• Nicht anwendbar, wenn Antwortdaten des
Geo Web Services nicht XML- bzw. GMLkodiert
sind
• Nicht für Einfüge-, Schreib- und Updateoperationen
auf dem Web Service verwendbar
Tabelle 3.2 Vor- und Nachteile des Post-Processing Ansatzes
3.3.3 Der Hybridansatz
Es wird in diesem Abschnitt eine weitere Variante eines Zugriffskontrollmechanismuses aufgeführt,
die im Folgenden als der Hybridansatz bezeichnet wird. Der Hybridansatz kombiniert
Pre- und Post-Processing Ideen, um dadurch die Nachteile beider Ansätze zu eliminieren
bzw. abzuschwächen.
Der Hybridansatz sieht bei modifizierenden Aktionen eine Zugriffskontrolle nach dem Pre-
Processing Ansatz vor. Bei lesenden Aktionen stehen der Pre- und/oder der Post-Processing
Ansatz zur Verfügung.

57
Beide Ansätze nacheinander ausgeführt (erst Pre-Processing dann Post-Processing) würde einige
Nachteile der Varianten eliminieren. Sinn des Post-Processing ist, dass die SSOs mit Sicherheit
wissen, dass keine zugriffsbeschränkten Daten an den Nutzer zurückgehen. Da der
Anteil zugriffsbeschränkter Daten nach dem Pre-Processing gleich null sein sollte, wäre zudem
ein entscheidender Nachteil der Post-Processing Variante – die Ineffizienz bei vielen
zugriffsbeschränkten Daten in der Web Service Antwort – behoben. Den Vorteilen dieser
Vorgehensweise stehen allerdings einige gravierende Nachteile gegenüber:
• zwei Regelwerke für lesende Aktionen nötig (anfragebasiertes Regelwerk für Pre-
Processing sowie Regelwerk für Zugriffskontrolle auf der Antwort beim Post-Processing)
• Problem mit komplexen Queries nicht gelöst
• zweimalige Zugriffskontrolle ( evtl. schlechte Performance)
Wegen der genannten Probleme wird das bloße Hintereinanderschalten der Pre- und Post-
Processing Ansätze als nicht geeignet angesehen. Im Hybridansatz wird daher zur Optimierung
der Post-Processing Variante für die Zugriffskontrolle bei lesenden Aktionen nur ein
teilweiser Pre-Processing Schritt vorgeschaltet. In diesem wird versucht durch Modifikation
der Anfrage den Anteil zugriffsgeschützer Daten in der Web Service Antwort – der für die Ineffizienz
beim Post-Processing Ansatz sorgt – gezielt zu verringern.
Unter teilweisem Pre-Processing versteht der Autor, auf Basis der Informationen in der Anfrage
ein Skelett des entsprechenden Ergebnisdokumentes, bestehend aus Element- und Attributknoten,
aufzubauen, auf dem dann bereits Zugriffsentscheidungen getroffen werden können.
Sofern das Zugriffskontrollsystem nach Anwendung der relevanten Regeln eine negative
Zugriffsentscheidung zu einem Knoten im Skelett berechnet hat, kann die Anfrage modifiziert
werden, so dass dieser Knoten nicht mehr vom Web Service angefordert wird. Dadurch kann
der Anteil zugriffsbeschränkter Daten in der Web Service Antwort verringert werden, wodurch
die Effizienz des im Anschluss stattfindenden Post-Processings gesteigert wird.
Problem des teilweisen Pre-Processing Schrittes ist, dass nur in bestimmten Fällen auf Basis
des Skelettes ermittelt werden kann, ob Zugriff auf einen Knoten gewährt werden soll oder
nicht. Dies ist nur dann möglich, wenn sich alle Zugriffsregeln zu einem Knoten auf Informationen
stützen, die im Skelett vorhanden sind. Dies bedeutet, dass die Wahrscheinlichkeit, auf
Basis des Skelettes eine Zugriffsentscheidung bestimmen zu können, durch Regelwerke mit
vielen inhaltsbezogenen Zugriffsregeln verringert wird. Die inhaltsbezogenen Zugriffsregeln
stützen sich nämlich auf die Textknoten des Dokumentes. Das Skelett besteht allerdings nur
aus Element- und Attributknoten. Sofern also zu einem angefragten Knoten mindestens eine
inhaltsbezogene und daher nicht anwendbare Zugriffsregel existiert, kann keine Zugriffsentscheidung
gefällt werden und die Anfrage an den Web Service kann nicht um diesen Knoten
beschnitten werden.
Da mit dem teilweisen Pre-Processing nur gewährleistet werden kann, dass der Anteil
zugriffsbeschränkter Daten in der Web Service Antwort verringert wird 16 , muss nach dem
16 deshalb der Name teilweises Pre-Processing

58
Generieren der modifizierten Anfrage ein zusätzlicher Post-Processing Schritt erfolgen. Dadurch
wird gewährleistet, dass die Web Service Antwort ausschließlich rechtmäßig zugreifbare
Daten enthält. Aufgrund des vorangegangenen teilweisen Pre-Processing Schrittes wird die
Effizienz dieses Post-Processings allerdings gesteigert.
Tabelle 3.3 zeigt zusammenfassend die Vor- und Nachteile des Hybridansatzes
Vorteile
• Reduktion des Anteiles zugriffsgeschützer
Daten vor Auswertung der Web Service
Antwort optimiertes Post-Processing möglich
• kein extra Regelwerk für Zugriffskontrolle
auf der Anfrage nötig
• Modifikation der Queries impliziert keine
komplexere Auswertung beim Web Service.
• Zuverlässigkeit der Zugriffskontrolle liegt
bei den SSOs
• Schutz des Web Services vor Belastung
durch unautorisierte Anfragen (z.B. Vermeidung
von denial of Service Attacken)
• Autorisation für Einfüge-, Schreib-, Updateund
Leseoperationen auf dem Web Service
überprüfbar
Nachteile
• eventuell zweimalige Regelanwendungen
• Die Effizienz des teilweisen Pre-Processings
ist abhängig von der Beschaffenheit des Regelwerkes
Nicht für alle Regelwerke sinnvoll.
Tabelle 3.3 Vor- und Nachteile des Hybridansatzes

59
3.3.4 Fazit
Wie gezeigt wurde, haben sowohl der Pre- und Post-Processing Ansatz als auch der Hybridansatz
ihre Schwächen. Es existiert kein Mechanismus, der unter beliebigen Ausgangsbedingungen
und Anforderungen immer die optimale Lösung darstellt.
Klar ist, dass für feingranulare Zugriffskontrolle bei modifizierenden Aktionen der Pre-
Processing Ansatz verwendet werden muss 17 .
Bei lesenden Aktionen stehen der Pre-Processing, der Post-Processing 18 und der Hybridansatz
zur Verfügung.
Aufgabenstellung dieser Diplomarbeit ist es, ein Konzept für raumbezogene Zugriffskontrolle
zu entwickeln. Der Fokus liegt daher auf der Umsetzung raumbezogener Zugriffsregeln, die
der Klasse der inhaltsbezogenen Zugriffsregeln zugeordnet werden können. Da der Hybridansatz
nur in Zugriffskontrollsystemen sinnvoll ist, in denen wenige inhaltsbezogene Regeln e-
xistieren, wird dieser in den nachfolgenden Kapiteln nicht näher betrachtet.
In Kapitel 4 und 5 (ohne 5.4) wird gezeigt, wie durch Post-Processing Zugriffskontrolle für
einen Geo Web Service erreicht werden kann. Die Ausführungen in diesen Abschnitten betrachten
daher nur Zugriffskontrolle, die sich auf die Inanspruchnahme eines Dienstes durch
lesende Aktionen bezieht.
Der Pre-Processing Ansatz wird im Anschluss unter 5.4 vorgestellt. Dort wird gezeigt, wie
dieser in einem Zugriffskontrollsystem für Geo Web Services genutzt werden kann, um
feingranulare, inhaltsabhängige und raumbezogene Zugriffskontrolle für lesende und modifizierende
Aktionen (einfügen, schreiben und löschen) zu realisieren.
17 Der Hybridansatz entspricht bei modifizierenden Aktionen dem Pre-Processing und stellt für diesen Fall keine
Alternative dar.
18 Vorausgesetzt der Geo Web Service liefert als Ergebnis strukturierte Daten zurück.

60
4 Zugriffskontrolle mit XACML
Dieses Kapitel beschreibt die konzeptionelle Umsetzung einer feingranularen, regelbasierten
Zugriffskontrolle für Geo Web Services am Beispiel des WFS. Es wird von einem Geo Web
Service ausgegangen, der lesenden Zugriff auf objektartig strukturierte Geodaten, kodiert in
GML, ermöglicht. Zur Durchsetzung des Regelwerkes wird in Abschnitt 4.2 und 4.3 der Post-
Processing Ansatz verwendet. Die Syntax zur Definition der Zugriffsregeln basiert auf dem
XACML Standard, Version 1.1 (XACML Spec 1.1). Es wird gezeigt, wie ein flexibles und
mächtiges Regelwerk definiert werden kann, das ermöglicht, Zugriffsrechte an Featuretypen,
an Features und an den Raumbezug der Features zu binden. Grundlage für die Definition des
Regelwerkes ist das XML Schema der zu schützenden Geodaten.
Alle aufgeführten XACML Beispiele sind vereinfacht (Namensräume – engl. Namespaces –
werden vernachlässigt, Bezeichner für Attributtypen werden abgekürzt etc.) und auf die wesentlichen
Inhalte beschränkt. Dies soll die Lesbarkeit sowie das Verständnis erleichtern.
4.1 XACML – eXtensible Access Control Markup Language
Dieser Abschnitt bietet eine kurze Einführung in die Sprache XACML Version 1.1 von
OASIS 19 (Organization for the Advancement of Structured Information Standards). Um den
Rahmen der Arbeit nicht zu sprengen werden nur die wesentlichen Inhalte von XACML erläutert.
Für detaillierte Informationen und dem Verständnis fördernde Beispiele wird auf die
XACML Spezifikation 1.1 (XACML Spec 1.1) sowie den Sun XACML Implementation Programmer's
Guide (SUNXACML 1.2) verwiesen, die als Basis für die Ausführungen zu diesem
Unterpunkt dienten.
4.1.1 Was ist XACML?
XACML ist eine standardisierte, mächtige und erweiterbare XML-basierte Sprache, um flexibel
Zugriffsregeln zu deklarieren. Zusätzlich ist eine Sprache festgelegt, um Anfragen an und
Antworten vom Zugriffskontrollsystem standardisiert auszudrücken. Antwortmöglichkeiten
auf eine XML-basierte Anfrage für eine Zugriffsentscheidung (zur Verbesserung der Lesbarkeit
im Folgenden als Zugriffsentscheidungsanfrage bezeichnet) sind „Zugriff erlaubt“ (engl.
permit), „Zugriff verboten“ (engl. deny), „nicht anwendbar“ (engl. not applicable) (d.h. es
19 Für webbasierte IT-Infrastruktur ist OASIS ist neben dem W3C eines der populärsten Standardisierungsgremien.

61
greift keine Regel zu dieser Anfrage) oder „nicht auswertbar“ (engl. indeterminate) (d.h. unbestimmt,
weil ein Fehler bei der Anwendung des Regelwerkes aufgetreten ist) (vgl.
SUNXACML 1.2).
Neben der Syntax und Semantik der erwähnten Sprachen sind in der XACML Spezifikation
modulare Einheiten eines Zugriffskontrollsystems sowie der Datenfluss zwischen diesen Bausteinen,
dem Nutzer und der Anwendung grob festgelegt. Abbildung 4.1 zeigt vereinfacht den
Datenfluss in einem XACML-basierten Zugriffskontrollsystem.
Nutzer
Web Service Anfrage oder
Web Service Antwort
Web Service
PEP
Context Handler
PIP
SSO
PAP Regelwerk PDP
Abbildung 4.1 Datenfluss in einem XACML-basierten Zugriffskontrollsystem (angelehnt an
XACML Spec 1.1, S. 19)
Die Administratoren des Regelwerkes können über eine Eingabemaske, den so genannten Policy
Administration Point (PAP), ihre Zugriffsregeln zentral festlegen. Der PAP dient als Eingabemaske
für Regeln und kümmert sich um die Verwaltung des Regelwerkes, wodurch das
Erzeugen und Pflegen der Zugriffsregeln erleichtert wird. Ein PAP 20 bietet beispielsweise:
• eine globale Sicht auf alle Regeln im System
• eine Erkennung von Regelkonflikten und Behandlungshilfen
• eine Visualisierung von Regeln
20 Diese Komponente eines Zugriffskontrollsystems wird in dieser Arbeit nicht behandelt (vgl. Aufgabenstellung).

62
Sobald ein Subjekt eine Aktion auf einer Ressource 21 ausführen möchte, muss das Zugriffskontrollsystem
aktiviert werden. Die Einheit, die als Einstiegspunkt in den Prozess der
Zugriffskontrolle dient, wird Policy Enforcement Point (PEP) genannt. Der PEP stellt somit
den „Wächter“ der Ressourcen dar und gewährleistet, dass nur autorisierte Zugriffe stattfinden
können.
Der PEP erzeugt auf Basis der ihm zur Verfügung stehenden Informationen (z.B. die Web
Service Anfrage – beim Pre-Processing – oder deren Antwort – beim Post-Processing) eine
Zugriffsentscheidungsanfrage, die an den Context Handler übergeben wird. Diese wird auch
XACML Request Context genannt, genügt einem standardisierten Format und dient als Abstraktionsebene
des Zugriffskontrollsystems zu der zu schützenden Anwendungsumgebung
(z.B. ein bestimmter Web Service). Dadurch haben Zugriffsentscheidungsanfragen ein einheitliches
Format und es ist möglich, das selbe Regelwerk für mehrere Anwendungen oder für
unterschiedliche PEPs zu verwenden. Der XACML Request Context wird vom Context Handler
bearbeitet (siehe 4.2.2) und an den so genannten Policy Decision Point (PDP) weitergeleitet.
Der PDP überprüft daraufhin, welche Regeln für diese Zugriffsentscheidungsanfrage anwendbar
sind, wertet diese aus und liefert eine Antwort zur Anfrage, den so genannten
XACML Response Context – die Zugriffsentscheidungsantwort, über den Context Handler an
den PEP. Dieser wertet das Ergebnis des Zugriffskontrollsystems aus und bedient den Nutzer
(Post-Processing) bzw. den Web Service (Pre-Processing) entsprechend (vgl. 4.2.3).
Der Policy Information Point (PIP) dient zum Anfordern zusätzlicher Attribute, die für eine
Autorisationsentscheidung nötig sind (z.B. aktuelle Uhrzeit).
Zu betonen ist, dass in der XACML Spezifikation keine Einschränkungen zur Lage und Anzahl
der einzelnen Einheiten (PEP, PDP ect.) festgelegt sind. Ebenfalls ist nicht genau vorgegeben,
welche Informationen zwischen den Modulen ausgetauscht werden sollen. Damit ist
gemeint, dass bei der Umsetzung einer Zugriffskontrolle, die zur XACML Spezifikation konform
ist, zwar vorgeschrieben ist, welche Sprache (Vokabular und Grammatik) zur Kommunikation
zwischen den einzelnen Komponenten zu verwenden ist, welche Inhalte allerdings
kommuniziert werden ist den Entwicklern eines Zugriffskontrollsystems selbst überlassen.
Neben XACML wurden einige andere Sprachen entwickelt, um Zugriffsregeln zu definieren,
mit denen feingranulare, kontextabhängige und inhaltsbezogene Zugriffskontrolle ermöglicht
werden soll (z.B. XRML – die eXtensible Rights Markup Language). Nachfolgende Argumente
begründen weshalb in dieser Arbeit gerade XACML zur Definition des Regelwerkes
verwendet wurde:
21 Statt des Begriffes Objekt wird das Synonym Ressource verwendet, um an die XACML Terminologie angepasst
zu formulieren.

63
• standardisiert
‣ Interoperabilität der Zugriffsregeln – d.h. Regeln sind für viele Anwendungen
nutzbar.
‣ Möglichkeit der Zusammenführung individueller Regeln oder ganzer Regelwerke
zu einem einzigen Regelwerk.
‣ Basis um die Entwicklung von fortgeschrittenen Werkzeugen für Zugriffskontrollsysteme
voranzutreiben (z.B. Tools zum Editieren und Testen des Regelwerkes)
• XML-basiert und daher unabhängig von einer bestimmten Systemumgebung und Programmiersprache
verwendbar
• Es existiert eine Abstraktionsschicht zur Abkapselung des Zugriffskontrollsystem von der
Anwendungsumgebung.
• Unterstützung verteilter Regelwerke sowie verteilter PEPs und PDPs (dezentrale Architektur
des Zugriffskontrollsystems möglich)
• Verwaltbarkeit des Regelwerkes durch mehrere Administratoren
• Ausdrucksstärke
Bei der Definition der Zugriffsregeln stehen zahlreiche logische und mathematische Funktionen
auf den Attributen der Ressourcen, der Subjekte, der Aktionen und der Systemumgebung
zur Verfügung.
• Die Sprache kann an klar definierten Stellen (Attributtypen, Funktionen, Combining Algorithmen)
nach Belieben erweitert werden (z.B. Unterstützung räumlicher Funktionen –
eine in dieser Arbeit definierte Erweiterung; siehe 5.3).
• Vordefinierte sowie selbstdefinierte, konfliktauflösende und regelverbindene Algorithmen
sind verwendbar.
• Es existiert eine Methodik, um die zu einer Zugriffsentscheidungsanfrage passenden Regeln
schnell zu identifizieren.
• Es besteht die Möglichkeit, eine Menge von Anweisungen zu definieren, die ausgeführt
werden müssen, wenn eine Police durchgesetzt wurde.
4.1.2 Das Sprachmodell des Regelwerkes
Zur Kodierung der Zugriffsregeln wird in der XACML Spezifikation eine XML-basierte
Sprache definiert, deren Modell in Abbildung 4.2 abgebildet ist. Demnach ist das Regelwerk
durch eine Menge an XML Dokumenten definiert.

64
1
PolicySet
1
1
1
0..*
1
Policy
Combining
Alogorithm
1
Target
0..1
0..1
1
1
0..*
Policy
0..*
Obligations
1 0..1
1
1
1
1
1
1..*
1..*
1..*
1..*
1
Subject
Resource
Action
Environment
Rule
Combining
Algorithm
1
0..*
1
Rule
1
1
0..1
Condition
1
Effect
Abbildung 4.2 Klassendiagramm der Sprache XACML (XACML Spec 1.1, S. 21)
Die XACML Regel
In XACML stellt eine Regel die elementarste Einheit der Police dar, beinhaltet die Kernlogik
des Regelwerkes und „existiert“ in einem Policy Objekt bzw. Element (objektorientierte

65
oder XML-orientierte Sichtweise). Eine Regel hat einen Effekt („permit“ oder „deny“), ein
Ziel (engl. Target) und eine Bedingung (engl. Condition). In einer XACML Regel werden ü-
ber Funktionen die Daten der zu bearbeitenden Zugriffsentscheidungsanfragen untereinander
oder mit beliebig definierten Konstanten verglichen. Da es sich bei den Daten unter anderem
um Werte der Ressource oder des Kontexts handelt, wird ersichtlich, dass durch XACML Regeln
inhalts- und kontextabhängige Zugriffskontrolle möglich ist.
Das Target besteht aus den drei Teilen Resource, Subject und Action. In diesen
wird festgelegt, welchen Eigenschaften die Zugriffsentscheidungsanfrage genügen muss, damit
die erste Voraussetzung für die Anwendbarkeit der Regel erfüllt ist. Das Target dient
zur Indexierung der Regeln, so dass deren Anwendbarkeit auf eine konkrete Zugriffsentscheidungsanfrage
schnell entschieden werden kann.
Durch die Bedingung der Regel wird die Anwendbarkeit der Regel, wie sie im Target definiert
worden ist, verfeinert. In Bedingungen sind beliebig geschachtelte Logikausdrücke und
Funktionen umsetzbar.
Wenn der Resource-, Action- und Subject-Teil des Targets erfüllt ist und die anschließende
Überprüfung der Condition erfolgreich ist, kann die Regel angewendet werden.
Dies hat zur Folge, dass der Effekt der Regel bei der Bestimmung der Zugriffsentscheidung
mit einfließt.
Die XACML Policy
Zunächst sei zur Verdeutlichung erwähnt, dass ein signifikanter Unterschied zwischen dem
Wort Police und Policy, wie es in XACML benutzt wird, besteht. Unter einer Police versteht
man ein Regelwerk, welches das Verhalten des Zugriffskontrollsystems definiert. Mit
einer Policy 22 in XACML ist dagegen ein Behälter für Regeln gemeint. Dieser kann in bestimmten
Fällen das Regelwerk darstellen. Üblicherweise wird das Regelwerk aber durch eine
Menge von Behältern bzw. Policys definiert.
Wie in obiger Graphik ersichtlich wird, ist eine Policy durch ein Target, einen regelverbindenden
(engl. rule combining) Algorithmus, eine Menge an Regeln und Obligations
definiert. Das Target spezifiziert die Anwendbarkeit der Policy auf eine Menge von Anfragen.
Durch den regelverbindenden Algorithmus (z.B. deny overrides, first applicable etc.)
wird definiert, wie bei der Anwendung des Regelwerkes die Ergebnisse der Regeln in der
Policy, sofern mehrere Regeln zu einer Anfrage greifen, zu einem Gesamtergebnis der Policy
verschmolzen werden sollen. Obligations bieten die Möglichkeit, eine Menge von
Anweisungen zu definieren, die vom PEP ausgeführt werden müssen, wenn eine Regel und
22 Im Folgenden wird der englische Begriff Policy verwendet, um hervorzuheben, dass die durch XACML
definierte Semantik gemeint ist.

66
eine Policy angewendet wurde. Ein PEP, der einen XACML Response Context inklusive
Obligations erhält, muss diese erfolgreich ausführen. Versteht er die Obligations
nicht oder können sie nicht erfolgreich umgesetzt werden, dann muss der Zugriff abgelehnt
werden.
Das XACML PolicySet
Ein PolicySet stellt einen Behälter für Policy Elemente oder Referenzen auf diese dar.
Durch eine Schachtelung der PolicySet Elemente wird eine beliebige Strukturierung des
Regelwerkes ermöglicht. Die Komponenten eines PolicySets sind ein Target, ein Policy
verbindender (policy combining) Algorithmus, beliebig viele Policy Objekte/Elemente
und Obligations. Das Target definiert die Anwendbarkeit des Policy-
Sets für eine Zugriffsentscheidungsanfrage. Der Policy verbindende Algorithmus legt
fest, wie die Ergebnisse der enthaltenen Policys kombiniert werden.
4.1.3 Der XACML Request und Response Context
XACML arbeitet im Wesentlichen auf Basis von Attributen. Diese haben einen Namen, einen
Wert und gehören zu einem Datentyp – man spricht vom Attributnamen, Attributwert und
vom Attributtyp 23 . Der PEP belegt benötigte Attribute im XACML Request Context mit Werten
aus der Anfrage an den Web Service (Pre-Processing) oder der Antwort des Web Services
(Post-Processing). Der Aufbau des Request Contexts ist viergeteilt. In der Subject Sektion
werden Attribute zum anfragenden Subjekt übergeben. Im Action Abschnitt werden die Daten
zu der vom Subjekt angeforderten Aktion (GetFeature, etc.) eingetragen. Im Resource
Teil des Request Contexts werden Daten zu den angefragten Ressourcen hinzugefügt. Hier
kann sich beispielsweise das beim Web Service angefragte XML Dokument befinden. Im optionalen
Environment Teil werden Daten zum Zustand bzw. Kontext des Zugriffskontrollsystems
übergeben. Jeder Bereich enthält Attributname-Wert-Paare, die sich alle auf die konkrete
Zugriffsanfrage beziehen. Unten abgedrucktes Codebeispiel zeigt exemplarisch den
Aufbau eines XACML Request Contexts, der infolge eines lesenden Zugriffes auf Geodaten
des WFS vom PEP erzeugt wurde (vereinfachte Syntax; detailliertere Informationen zum
XACML Request Context siehe XACML Spec 1.1, z.B. S. 27 oder 30).
max_mustermann@chbank.ch
23 Um der XACML Terminologie zu folgen, wird der Begriff Attributtyp statt des Begriffes Datentyp verwendet.

67
Auszubildender
-180.0,-90.0 180.0,90.0
-120.000000,65.588264 ...-120.000000,65.588264
FMI-Bau
1983
TU-München
4
...
...
/Request/Resource/ResourceContent/
Descendants
WebFeatureService:port7071
GetFeature
Durch das so genannte ResourceContent Element besteht die Möglichkeit, alle Ressourcen,
die von der Nutzerinteraktion betroffen sind, in den Request Context zu integrieren. In
den XACML Regeln können die Daten des Request Contexts referenziert und ausgewertet
werden, um inhalts- oder kontextabhängige Zugriffsentscheidungen zu bestimmen.
Eine Möglichkeit, um in einer Regel auf die Werte des XACML Request Contexts zuzugreifen,
bietet der so genannte AttributeDesignator. Durch ihn können die Werte der Attribute ü-
ber die Attributnamen selektiert werden. Diese dienen dann als Argumente in den Funktionen

68
der Regeln. Ein weiterer Mechanismus zur Adressierung von Werten im Request Context
(genauer im ResourceContent Element) bietet der AttributeSelector. In einem Attribute-
Selector wird ein XPath-Ausdruck definiert, der über dem
/Request/Resource/ResourceContent Knoten der Zugriffsentscheidungsanfrage ausgewertet
wird. Dort befindet sich in der Regel die Kopie der zu schützenden Ressource (z.B. das vom
Web Service als Antwort auf eine lesende Aktion generierte XML Dokument). Der Attribute-
Selector holt die durch XPath adressierten Knoten, die dann als Argumente in den Funktionen
der Regelbedingung verwendet werden können.
Sowohl der AttributeDesignator als auch der AttributeSelector liefert eine „Wertemenge“ zurück.
XACML hat dafür einen speziellen Attributtyp „Bag“ (d.h Multimenge) inklusive Funktionen
zur Verarbeitung des Attributtyps vorgesehen.
Für ein besseres Verständnis der Sprache des Regelwerkes und des XACML Request/Response
Contexts sei auf die gut dokumentierten Beispiele in der XACML Spezifikation
(XACML Spec 1.1, S. 25-46) verwiesen. Dem interessierten Leser ist für einen tieferen
Einstieg in die Sprachen das Lesen der XACML Spezifikation (XACML Spec 1.1) empfohlen.
4.2 Zugriffskontrolle für XML Dokumente mit XACML
Ausgangspunkt für die Ausführungen dieses Abschnittes ist, dass ein Subjekt über die Get-
Feature Anfrage lesend auf die Geodaten eines WFS zugreifen möchte. Ferner wird ein
Zugriffskontrollmechanismus nach dem Post-Processing Ansatz angenommen. Das bedeutet,
dass das GML-kodierte Antwortdokument – die zu schützende dynamisch generierte Ressource
– nach seiner Erzeugung durch den WFS vom Zugriffskontrollsystem auf Zugriffsrechte
überprüft und gegebenenfalls modifiziert werden muss.
Im XACML Jargon wird ein zu schützendes XML Dokument als hierarchische Ressource bezeichnet,
die aus zahlreichen individuellen Ressourcen – den Knoten – besteht (z.B. in
XACML HierProf, S. 3). Es wird davon ausgegangen, dass alle Knoten eines dynamisch generierten
XML Dokumentes an den Nutzer übermittelt werden sollen. Das bedeutet für die
Zugriffskontrolle, dass für jeden Knoten des Dokumentbaumes alle Regeln auf Anwendbarkeit
überprüft werden müssen.
Hierzu kann der PEP eine Zugriffsentscheidungsanfrage für alle Knoten oder mehrere
Zugriffsentscheidungsanfragen – eine je Knoten – auf unterschiedliche Art und Weise absetzen.
Da wie bereits erwähnt in der XACML Spezifikation nicht festgelegt ist, wie die Inhalte
der Nachrichten aufzubauen sind, wird im Folgenden beschrieben, wie XACML-konform lesender
Zugriff auf dynamisch generierte XML Dokumente kontrolliert werden kann.

69
4.2.1 Die vom PEP generierte globale Zugriffsentscheidungsanfrage
Zur Unterscheidung der vom PEP abgesetzten und der vom Context Handler weitergeleiteten
Zugriffsentscheidungsanfrage werden die Begriffe globaler XACML Request Context (die
vom PEP kommende Anfrage) und individueller XACML Request Context (die vom Context
Handler kommende Zugriffsentscheidungsanfrage) eingeführt.
Bei der Überprüfung der Zugriffsregeln zu einem XML Dokument muss der PEP auf Basis
der ihm zur Verfügung stehenden Werte einen globalen XACML Request Context generieren.
Hierzu gibt es mehrere Möglichkeiten.
Eine Variante ist, dass der PEP das angefragte XML Dokument parst und die ihm bekannten
Knoten (beispielsweise die im GML Dokument vorkommenden Featuretypen) explizit über
XACML Attribute in den globalen XACML Request Context einträgt. Dies fordert allerdings
komplexe Funktionalitäten im PEP ( Perfomanceeinbußen) und der Aufbau des Regelwerkes
lässt sich nicht mehr einfach baumartig organisieren (vgl. Anhang C.2 24 ).
Eine andere Möglichkeit, einen globalen XACML Request Context zu erzeugen, ist, dass der
PEP neben allen bekannten Werten zum anfragenden Subjekt und zur getätigten Aktion unter
dem /Request/Resource/ResourceContent Element das zu schützende XML Dokument – die
Web Service Antwort (vgl. Annahmen zu Beginn von 4 oder 4.2) – einfügt. Zudem werden
im Resource Teil des globalen XACML Requests die mit einer besonderen Semantik versehenen
Attribute resource-id und scope verwendet. Das resource-id Attribut
zeigt auf denjenigen Knoten des im ResourceContent Element eingefügten XML Dokumentes,
ab dem die Zugriffsregeln überprüft werden sollen. Das scope Attribut definiert relativ
zu dem im resource-id Attribut angegebenem Wert, für welche Knoten im XML
Dokument der Zugriff kontrolliert werden soll. Im Beispiel aus 4.1.3 impliziert der Wert des
scope Attributes – descendants (deutsch: Nachkommen) – und der Wert des resource-id
Attributes, der auf die Wurzel des im ResourceContent Element eingefügten
XML Dokumentes zeigt, dass für alle Knoten im angeforderten Dokument der Zugriff überprüft
werden soll.
Durch die zweite Variante wird im PEP eine deutlich einfachere Funktionalität benötigt, wodurch
sich dessen Umsetzung erleichtert und zudem ein schnelles Generieren globaler
Zugriffsentscheidungsanfragen begünstigt wird.
Aufgrund dieser Vorteile wurde die zweite Variante zum Erzeugen von globalen Zugriffsentscheidungsanfragen
gewählt.
24 Die Lektüre des Anhangs C wird frühestens nach dem Lesen dieses Kapitels empfohlen

70
4.2.2 Varianten zur Weiterleitung der globalen Zugriffsentscheidungsanfrage
zu einer hierarchischen Ressource durch den Context Handler
an den PDP
Der Context Handler, der den vom PEP erzeugten globalen XACML Request Context entgegennimmt,
kann die Zugriffsentscheidungsanfrage auf mehrere Arten an den PDP weiterleiten.
Nachfolgend werden zwei sinnvolle Alternativen diskutiert.
Variante A:
Der Context Handler erzeugt auf Basis des globalen XACML Request Contexts für die durch
resource-id und scope spezifizierten Knoten individuelle Zugriffsentscheidungsanfragen
(eine je Knoten), die einzeln an den PDP geschickt werden.
Der PDP kann durch das scope Attribut ermitteln, für welche Knoten eine individuelle
Zugriffsanfrage erzeugt werden soll. Dies geschieht relativ zu dem Knoten, der durch das
resource-id Attribut der globalen Zugriffsentscheidungsanfrage selektiert wird. Mögliche
scope Werte sind descendants, entire hierarchie und children 25 .
Bei descendants wird für jeden Knoten unterhalb des durch resource-id bestimmten
Knotens eine individuelle Zugriffsentscheidungsanfrage an den PDP übergeben. Nach Behandlung
der individuellen Zugriffsentscheidungsanfragen (diese beziehen sich auf genau einen
Knoten) werden die individuellen Zugriffsentscheidungsantworten (entspricht der
Zugriffsentscheidung für diesen Knoten) einzeln vom PDP an den Context Handler gesendet
und unverändert an den PEP weitergeleitet.
Bei entire hierarchie wird ebenfalls je Knoten eine individuelle Zugriffsentscheidungsanfrage
an den PDP übergeben. Im Unterschied zum scope Wert descendants
merkt sich der Context Handler die Ergebnisse der individuellen Zugriffsentscheidungsantworten
und übergibt nur ein Gesamtergebnis für alle individuellen Knotenanfragen an den
PEP. Dieses lautet nur dann permit, wenn alle Antworten auf die individuellen Request Contexts
permit ergaben. Der entire hierarchie Attributwert impliziert eine Zugriffskontrolle
nach dem „alles oder nichts“ Prinzip. Grundstein für eine Zugriffskontrolle nach dem
„so viel wie geht“ Prinzip ist daher ein scope Wert von descendants, da dadurch je Knoten
im angeforderten Dokument eine individuelle Zugriffsentscheidungsantwort generiert
wird.
Zu erwähnen ist, dass die Erzeugung individueller Zugriffsentscheidungsanfragen nicht im
PEP geschehen sollte, da die PEPs und PDPs räumlich verteilt liegen können und diese Vorgehensweise
daher zu einem enormen Mehraufwand an Kommunikation führen würde. Die
25 Der Wert children wird für die Ausführungen in dieser Arbeit nicht benötigt und wird daher nicht weiter
erläutert, da alle Knoten des XML Dokumentes auf Zugriffsrechte überprüft werden müssen.

71
globale XACML Zugriffsentscheidungsanfrage wird daher immer erst vom Context Handler
(es wird angenommen, dass dieser im selben lokalen System läuft wie der PDP) in individuelle
Zugriffsentscheidungsanfragen transformiert.
Abgesehen vom Wert des resource-id Attributes entspricht der Aufbau der individuellen
Zugriffsentscheidungsanfrage dem des globalen XACML Request Contexts. Das resource-id
Attribut in der individuellen Zugriffsentscheidungsanfrage stellt einen eindeutigen
XPath-Ausdruck dar, der genau den Knoten kennzeichnet, auf den sich die individuelle
Zugriffsentscheidungsanfrage bezieht. Das scope Attribut in der individuellen Zugriffsentscheidungsanfrage
hat keine Bedeutung.
Beispiel eines resource-id Attributes in einer individuellen Zugriffsentscheidungsanfrage:
/Request/Resource/ResourceContent/wfs:FeatureCollection[1]/gml:Feature-
Member[1]/gml:Gebäude[1]
Variante B:
Alternativ könnte der vom PEP abgesetzte globale XACML Request Context unverändert an
den PDP weitergeleitet werden. Es wird demnach eine Zugriffsentscheidungsanfrage für alle
Knoten an den PDP abgesetzt. In diesem Fall wird das XML Dokument nicht als eine hierarchische
Ressource, sondern als eine strukturierte, individuelle Ressource angesehen. Dies bedeutet,
dass der PDP auf eine Zugriffsentscheidungsanfrage die anwendbaren Regeln für das
gesamte Dokument – d.h. für alle Knoten, betrachtet als ein atomares Ganzes – identifizieren
und überprüfen muss. Nach der Auswertung der greifenden Regeln gibt der PDP dann für das
gesamte XML Dokument nur eine Zugriffsentscheidungsantwort zurück. Das bedeutet, dass
der Zugriff auf das angeforderte Dokument entweder gewährt oder abgelehnt wird, was einer
Zugriffskontrolle nach dem „alles oder nichts“ Prinzip entspricht. Im PEP kann a priori nicht
differenzierter bestimmt werden, welche Knotenmengen des XML Dokumentes zugriffsbeschränkt
oder zugreifbar sind. Bei Variante A ist dies direkt möglich, da sich dort die
Zugriffsentscheidungsantworten immer auf genau einen Knoten beziehen.
Da das in dieser Arbeit entwickelte Zugriffskontrollsystem eine Zugriffskontrolle nach dem
„so viel wie geht“ Prinzip unterstützen soll, muss daher – um Variante B dennoch verfolgen
zu können – im Regelwerk ein zusätzlicher Mechanismus integriert werden, der den PEP mit
Informationen zu den zugreifbaren und zugriffsbeschränkten Knotenmengen des XML Dokumentes
beliefert.
Die von XACML zur Verfügung gestellten Obligations können zur Realisierung dieses
Mechanismuses – wenn auch vom XACML Komitee nicht für diese Funktionalität angedacht

72
(vgl MailProctor) – verwendet werden. Sie bieten die Möglichkeit, in Abhängigkeit der Regeleffekte
26 Anweisungen an den PEP zu übergeben. Da sich eine Zugriffsregel auf bestimmte
Knoten des XML Dokumentes bezieht und für diese eine Zugriffsentscheidung bestimmt,
kann dem PEP je nach Effekt der Regel über eine Obligation mitgeteilt werden, welche
Knotenmengen zugriffsbeschränkt bzw. zugreifbar sind. Diese Informationen kann der PEP
dann nutzen, um das XML Dokument so zu modifizieren, dass nur noch zugreifbare Daten in
der Antwort an den Nutzer enthalten sind.
Die Anwendbarkeit einer Regel, einer Policy oder eines PolicySets wird im Target
definiert. Die Varianten A und B fordern unterschiedlich aufgebaute Targets (genauer:
Funktionen im Resource Element des Targets), deren Definitionen im Folgenden einzeln
vorgestellt werden. Ziel ist es, das Target dieser Elemente so zu deklarieren, dass für
die gewünschten Knotenmengen des im ResourceContent eingefügten XML Dokumentes
Autorisationen festgelegt werden können.
In Variante A kann unter anderem die regexpr-string-match Funktion zur Überprüfung
der Anwendbarkeit der Regeln, Policys und PolicySets verwendet werden. Hierzu
wird im Resource Teil des Rule-, Policy- oder PolicySet-Targets ein regulärer
Ausdruck definiert, der mit dem resource-id Wert der individuellen Zugriffsentscheidungsanfrage
abgeglichen wird (siehe Umsetzung mit Variante A im unten abgebildeten Beispiel).
Genügt das resource-id Element dem regulären Ausdruck, so ist eine Bedingung
für das Greifen der Regel, der Policy oder des PolicySets erfüllt. Durch dieses Vorgehen
kann ausgedrückt werden, auf welche Knoten sich die Regel, die Policy oder das PolicySet
bezieht.
Um Variante B zu ermöglichen, muss im Resource Teil der Target Elemente die
xpath-node-exist Funktion zur Indexierung der Regeln, Policys und PolicySets
eingesetzt werden. Diese verlangt als Argument einen String, der als XPath-Ausdruck interpretiert
und über dem ResourceContent Element ausgewertet wird. Der Rückgabewert
der Funktion ist „wahr“, wenn die Anzahl der durch den XPath-Ausdruck selektierten Knoten
größer 1 ist.
Beispiel:
Betrachtet wird folgendes XML Dokument:
Max Mustermann
Eva
Franz Nissel Grundschule
26 Hierfür wird vorausgesetzt, dass jede Regel einzeln in einem Policy Element steckt, da nur so in XACML
regelbezogen eine Obligation definiert werden kann.

73
...
Tom
Grundschule an der Eversbuschstraße
...
Eine Zugriffsregel soll die Daten zu den Kinder einer Person zugriffsbeschränken, wenn das
Kind die Grundschule an der Eversbuschstraße besucht bzw. besucht hat.
Umsetzung mit Variante A:
Das Target der Regel nach Variante A muss demnach einen XPath-Ausdruck spezifizieren,
durch den ein Greifen der Regel bei Zugriff auf den Kindknoten zu einer Person erreicht wird.
Dies wird durch folgenden Regelausschnitt umgesetzt:
...
/Request/Resource/ResourceContent/Person\[\d+\]/Kind\[\d+\]
...
In der Bedingung der Regel muss dann überprüft werden, ob das gerade betrachtete Kind der
Person die Grundschule an der Eversbuschstraße besucht bzw. besucht hat. Da durch die individuellen
Zugriffsentscheidungsanfragen in Variante A nach anwendbaren Zugriffsregeln für
jedes Kind Element einzeln gesucht wird, bezieht sich die Zugriffsentscheidungsantwort, die
unter Berücksichtigung der eben vorgestellten Regel generiert wurde auf genau ein Kind E-
lement.
Um in Variante B die Beispielregel umsetzen zu können, muss das Target wie folgt definiert
werden:
...
/Request/Resource/ResourceContent/Person/Kind[besuchte_Grundschule=
”Grundschule an der Eversbuschstraße”]

74
...
Sofern der XPath-Ausdruck einen Knoten im zu schützenden XML Dokument selektiert (im
Beispiel das Kind Tom) greift die Regel.
Ein Nachteil von Variante B ist, dass sich die Definition des Regelwerkes verkompliziert –
Obligations sind anzugeben. Zudem ist die Auswertung der benötigten xpath-nodeexist
Funktion unter Verwendung der momentan verfügbaren XPath APIs (Xalan, Xerces
usw.) weniger performant als die Evaluation der reg-exp-string-match Funktion
(vgl. SUNXACML 1.2 und zur Begründung siehe die Implementierung der entsprechenden
Funktionen). Dies ist ein weiterer Nachteil der Variante B.
Für Variante A spricht, dass diese Vorgehensweise vom XACML Komitee beabsichtig ist
(siehe MailAnderson a, XACML MultProf und XACML HierProf), auch wenn nur sehr
rudimentär und noch nicht vollständig ausgereift in der aktuellen Spezifikation 1.1 angedeutet.
Mit der XACML Spezifikation 2.0 (voraussichtliche Verabschiedung Anfang 2005) will
das XACML Komitee diese Unklarheit beseitigen.
Aufgrund der obigen Ausführungen wird im Folgenden die Variante A weiter verfolgt. Die
nachfolgend beschriebenen Umsetzungen von Zugriffsregeln für (Geo) Web Services sind
daher dieser Variante entsprechend entworfen worden.
4.2.3 Auswertung der individuellen Zugriffsentscheidungsantworten im PEP
Der PDP liefert zu jeder individuellen Zugriffsentscheidungsanfrage eine individuelle
Zugriffsentscheidungsantwort, die über den Context Handler an den PEP geleitet wird.
In den individuellen Zugriffsentscheidungsantworten ist neben der Zugriffsentscheidung und
dem Statuscode der Wert des resource-id Attributes enthalten. Dadurch ist dem PEP bekannt,
auf welchen Knoten sich die Antwort bezieht. Je nach Zugriffsentscheidung kann er
dann den Knoten unverändert im XML Dokument (z.B. in der Web Service Antwort) lassen
oder bei einem deny den durch das resource-id gekennzeichneten Knoten aus dem Dokument
herausfiltern. Wie das Herausfiltern zugriffsbeschränkter Knoten im PEP implementiert
werden kann, wird in 6.4.2 behandelt.

75
4.2.4 Modellierung rekursiven Regelverhaltens
In einem Zugriffskontrollsystem für XML Dokumente haben alle Regeln, die sich auf Knoten
in einem XML Dokumentbaum beziehen, „rekursiven 27 “ Charakter. Grund ist die Baumstruktur
des XML Dokumentes. Eine Regel, die sich auf einen Knoten A bezieht, gilt zugleich für
alle Nachkommen von A. Nur wenn alle Vorgängerknoten von A zugreifbar waren und die
Regelauswertung aller Regeln, die sich direkt auf den Knoten A beziehen, „Zugriff erlaubt“
ergeben, ist auf Knoten A zugreifbar. Falls auf Knoten A nicht zugegriffen werden kann, impliziert
dies direkt, dass alle Kinder von Knoten A auch nicht zugreifbar sind.
Wäre dem nicht so, dann würde ein Zugriffskontrollsystem für XML Dokumente, das alle zugreifbaren
Knoten unabhängig von der Zugreifbarkeit der Vorgängerknoten zurückgibt, für
den Zerfall des XML Dokumentbaumes sorgen. Es könnte nämlich beispielsweise der Fall
eintreten, dass der Vater zugriffsbeschränkt, die Kinder allerdings zugreifbar sind. In diesem
Fall könnten die einzelnen neuen Bäume dieses Waldes allerdings nicht mehr sinnvoll zu einer
Baumstruktur zusammengefügt werden, die dem Schema des ursprünglichen Dokumentes
genügt. Aufgrund dieser Problematik wird festgelegt, dass Regeln, die sich auf einen Knoten
beziehen, rekursiven Einfluss auf die Nachkommen dieses Knotens haben.
Die Umsetzung dieses rekursiven Regelverhaltens kann indirekt durch die Arbeitsweise des
Context Handlers ausgedrückt werden. Dieser stellt je Knoten im XML Dokument eine individuellen
Zugriffsentscheidungsanfrage. Dabei geht er den Dokumentbaum in Preorder ab
(d.h. Tiefensuche von links nach rechts). Sobald die Antwort auf eine individuelle Zugriffsentscheidungsanfrage
„deny“ war, muss für den Unterbaum dieses Knotens keine weitere individuelle
Zugriffsentscheidungsanfrage abgesetzt werden, da diese Nachkommenknoten wegen
der Rekursivität ebenfalls nicht mehr zugänglich sind.
Alternativ kann der Context Handler die individuellen Zugriffsentscheidungsanfragen unabhängig
von individuellen Zugriffsentscheidungsantworten absetzen. Er generiert ohne Intelligenz
für jeden Knoten des Dokumentes eine individuelle Zugriffsentscheidungsanfrage.
Die Umsetzung des rekursiven Regelverhaltens geschieht dann durch die Arbeitsweise des
PEPs. Soll dieser einen zugriffsbeschränkten Knoten aus dem XML Dokument herausfiltern,
so wird dieser samt seinen Nachfahren gelöscht. Zugriffsentscheidungsantworten zu Knoten,
die bereits entfernt wurden, werden vom PEP ignoriert.
27 Darunter wird in diesem Zusammenhang verstanden, dass sich die Regel auf einen Knoten und sämtliche
Nachkommen dieses Knotens bezieht.

76
4.2.5 Erweiterung der Mechanismen zur Referenzierung von Attributen
aus XACML Regeln
Durch die in 4.2.1 und 4.2.2 beschriebene Art der Kommunikation zwischen PEP, Context
Handler und PDP ist neben dem AttributeSelector und dem AttributeDesignator eine neue Art
der Referenzierung von Attributen im Request Context möglich geworden. Da sich jede individuelle
Zugriffsentscheidungsanfrage auf einen Knoten im angeforderten XML Dokument
bezieht, kann man in den Regeln Werte relativ zu dem aktuell betrachten Knoten der individuellen
Zugriffsentscheidungsanfrage (per resource-id Attribut adressiert) selektieren.
Da mit dem AttributeSelector nur explizit angegebene XPath-Ausdrücke verarbeitet werden
können, wurde XACML um neue Funktionen zum Referenzieren von Werten relativ zu einem
Kontextknoten erweitert.
Diese so genannte datentyp-InformationSelector Funktionen erwarten zwei String Argumente,
die als die Teile eines XPath-Ausdruckes interpretiert werden. Die beiden Argumente werden
zu einem XPath-Ausdruck konkateniert und anschließend werden die so adressierten Knoten,
entsprechend der Funktionalität des AttributeSelectors, als Strings kodiert geholt. Durch die
Angabe des Datentyps, bzw. Attributtyps (datentyp-InformationSelector) ist es möglich, die
selektierten Knoten als entsprechende Attributtypen zu instanzieren (vgl. 6.2.3). Es existiert
daher für jeden Attributtyp ein eigener InformationSelector.
Beim datentyp-InformationSelector muss, wie auch beim AttributeSelector und beim AttributeDesignator,
angegeben werden, wie zu verfahren ist, wenn die zu selektierenden Knoten im
XACML Request Context nicht vorhanden sind. Um auszudrücken, dass die Regel das Vorhandensein
der selektierten Werte erwartet, muss das boolsche must-be-present Attribut
gesetzt werden. Ist es „wahr“ und die adressierten Knoten sind nicht in der Zugriffsentscheidungsanfrage
enthalten, dann evaluiert der Selektor bzw. der Designator und damit die Regel
zu „nicht auswertbar“. Im Falle eines „false“ Wertes und adressierten, aber nicht existenten
Knoten liefert der Selektor eine leere Menge zurück. Dieses Verhalten muss bei der Definition
der Regel berücksichtigt werden.
4.3 Modellierung unterschiedlicher Regeltypen für Geo Web Services
In dieser Arbeit wird beschrieben, wie Zugriffskontrolle für Geo Web Services zu realisieren
ist. Für dieses Anwendungsszenario lassen sich vier besondere Regeltypen herausarbeiten.
Ausgehend davon, dass Geodaten als Features objektartig modelliert und in GML-kodierter
Form vorliegen, können sich Zugriffsregeln auf einen Featuretyp, auf Eigenschaften eines
Featuretyps, auf bestimmte Features, d.h. auf Instanzen eines Featuretyps, oder auf Eigen-

77
schaften eines Features beziehen. Auf Basis dieser Unterteilung werden im Folgenden vier
Regeltypen einzeln betrachtet:
Definitionen:
• Typregel
Eine Regel, die den Zugriff auf Features aufgrund des Typs, dem die Features angehören,
einschränkt oder zulässt.
• Instanzregel
Eine Regel, die den Zugriff auf Features aufgrund nicht raumbezogener Eigenschaften der
Features definiert. Zugriffsregeln dieses Typs stützen sich auf die Daten eines Features
(Textknoten des XML Dokumentes), woraus folgt, dass es sich um inhaltsabhängige Regeln
handelt.
• Raumregel
Eine Regel, die den Zugriff auf Features aufgrund der raumbezogenen Eigenschaften der
Features festlegt. In Raumregeln können Gebiete im Raum – d.h. georeferenzierte, geometrische
Objekte – definiert werden. Diese werden im Folgenden als Regelgebiet bezeichnet.
Neben dem Regelgebiet muss in der Raumregel zusätzlich eine räumliche Analyse
(z.B. eine topologische oder eine räumliche Operation) spezifiziert werden. Die
raumbezogene Zugriffsregel kann angewendet werden, wenn die Rauminformation eines
angefragten Features die Relationen zum Regelgebiet erfüllt.
• RaumInstanzregel
Eine Regel, die den Zugriff auf Features aufgrund von raumbezogenen und nicht raumbezogenen
Eigenschaften der Features bestimmt. Bei einer RaumInstanzregel handelt es sich
demnach um die Kombination einer Instanz- und einer Raumregel in einer Regel.
Unabhängig vom Regeltyp und allen Regeln gemeinsam ist, dass sie sich auf bestimmte individuelle
Zugriffsentscheidungsanfragen beziehen. Die Anfragen drücken aus, welches Subjekt
eine bestimmte Aktion auf einem Knoten ausgeführt hat. Diese Information kann in der
Zugriffsregel genutzt werden, um zu entscheiden, ob sie angewendet werden soll. Eine Verfeinerung
der Entscheidung zur Anwendbarkeit geschieht gegebenenfalls in der Bedingung
der Regeln. Die Anzahl der Features, auf die sich eine Regel bezieht, ist abhängig von der
Semantik der Regel, vom Inhalt der Datenbasis und von der Anfrage des Nutzers an den Web
Service.
4.3.1 Festlegen von Zugriffsregeln auf den Featuretyp
Die allgemeinste Form einer Zugriffsbeschränkung für GML-kodierte Geodaten bezieht sich
auf den Typ eines Features. Regeln dieser Art erlauben oder beschränken den Zugriff auf alle

78
Features dieses Typs. Für die folgende Betrachtung wird vorausgesetzt, dass der Featuretyp
eines Objektes als ein Elementknoten kodiert ist. Diese Annahme entspricht der Empfehlung
in der GML Spezifikation (OGC GML 2.1.2, S. 9).
Regeln auf Typebene greifen daher, wenn das resource-id Attribut im individuellen Request
Context einen XPath-Ausdruck darstellt, der genau einen Elementknoten im angeforderten
Dokument adressiert, dessen Wert dem Featuretyp entspricht, auf den sich die Regel beziehen
soll.
Aufbau einer Typregel
Durch die unten dargestellte Syntax sind Regeln möglich, die sich auf beliebige Element- und
Attributknoten im XML Dokument beziehen. Da Typregeln eigentlich Zugriffsregeln auf E-
lementknoten darstellen (der Featuretyp ist ja durch einen Elementknoten ausgedrückt), lassen
sich durch diese Syntax Zugriffsregeln für einen Featuretyp deklarieren. Attributregeln sind
ein Spezialfall von Elementregeln. Zunächst wird eine typbezogene Regel betrachtet (Beispiel
1). Im Anschluss wird die verallgemeinerte Form der Element- und Attributknoten Regeln
vorgestellt (siehe Beispiel 2, 3 und 4).
Beispiel 1: Typregel
Durch die unten abgedruckte Regel soll der Zugriff auf Features vom Typ Gebäude gewährt
werden.
/Request/Resource/ResourceContent/FeatureCollection\[\d+\]/
featureMember\[\d+\]/GEBAEUDE\[\d+\]
GetFeature

79
Die in Beispiel 1 aufgeführte Typregel wird für Zugriffsentscheidungsanfragen angewendet,
sofern ihr Target erfüllt ist. Aufgrund des Elementes wird die Regel
unabhängig vom Subjekt, das die Aktion getätigt hat, angesprungen. Dies wird vereinfachend
für alle folgenden Beispiele angenommen, weshalb der Subject Teil des Targets dort
weggelassen wird. Der Action Teil der Regel ist erfüllt, wenn die vom Nutzer getätigte Aktion
der GetFeature Operation entspricht. Wie bereits erwähnt (vgl. 3.3.4 oder Kapitel 4 Anfang),
wird in diesem Kapitel nur der lesende Zugriff, d.h. die GetFeature Anfrage, betrachtet.
Daher ist der Action Teil für alle unter 4.3 aufgeführten Beispiele gleich dem obigen und
wird daher in den nachfolgende Codebeispielen ebenfalls weggelassen.
Das Charakteristikum einer Typregel steckt im Resource Teil ihres Target Elementes.
Dieser ist erfüllt, wenn der Wert des resource-id Attributes der individuellen Zugriffsentscheidungsanfrage
dem regulären Ausdruck
/Request/Resource/ResourceContent/FeatureCollection\[\d+\]/feat
ureMember\[\d+\]/GEBAEUDE\[\d+\]
genügt. Obige Regel würde beispielsweise zu einer Zugriffsentscheidungsanfrage mit einem
resource-id Wert gleich
„/Request/Resource/ResourceContent/FeatureCollection[1]/
featureMember[5]/GEBAEUDE[1]“
greifen. Das bedeutet, dass obige Regel für alle im angefragten Dokument vorkommenden
Gebäude-Featureknoten zur Anwendung kommt.
Nun werden Zugriffsregeln für beliebige Element- und Attributknoten im Dokument betrachtet.
Beispiel 2: Zugriffsregel für einen beliebigen Elementknoten
Ein SSO möchte, dass die Nutzer alle Eigenschaften eines Features vom Typ Gebäude sehen
dürfen, außer den Besitzer. Wird zu einem Feature auch die Besitzer-Eigenschaft abgefragt,
so soll der Nutzer nur dieses Element nicht sehen. Um diese Regel inklusive der gewünschten
Konsequenz umzusetzen, muss die Regel greifen, wenn sich die individuelle Zugriffsentscheidungsanfrage
auf den Besitzer-Elementknoten eines Gebäudefeatures bezieht (vgl. 4.2.3
und C.6). Dadurch kann bei einem Regelverstoß genau der Besitzer-Elementknoten aus der
Web Service Antwort herausgefiltert werden.
...
/Request/Resource/ResourceContent/FeatureCollection\[\d+\]/
featureMember\[\d+\]/GEBAEUDE\[\d+\]/Besitzer\[\d+\]

80
...
Diese Regel greift beispielsweise bei einem resource-id Wert gleich
„/Request/Resource/ResourceContent/FeatureCollection[1]/
featureMember[5]/GEBAEUDE[1]/Besitzer[1]“.
Sobald sich eine individuelle Zugriffsentscheidungsanfrage auf den Besitzer Knoten eines
Gebäudefeatures im XML/GML Dokument bezieht, kommt diese Elementregel zur Anwendung
und die daraufhin generierte individuelle Zugriffsentscheidungsantwort, die an den PEP
zurückgegeben wird, drückt die Zugriffsbeschränkung für den entsprechenden Besitzer
Knoten aus.
Beispiel 3: Zugriffsregel für einen beliebigen Elementknoten, die sich auf dessen Nachkommen-Elemente
bezieht
In diesem Beispiel soll der gleiche Zugriffsschutz wie in Beispiel 2 ausgedrückt werden, allerdings
mit einer anderen Konsequenz. In diesem Fall soll, sobald ein Nutzer ein Gebäudefeature
samt Besitzer-Eigenschaft abfrägt, das gesamte Feature zugriffsbeschränkt sein.
Daraus folgt, dass die Regel bei Zugriffenscheidungsanfragen zum Gebäudeknoten greifen
muss, da der Dokumentbaum bei Anwendung der Regel ab diesem Knoten beschnitten werden
muss (vgl. 4.2.3 und C.6).
...
/Request/Resource/ResourceContent/FeatureCollection\[\d+\]/
featureMember\[\d+\]/GEBAEUDE\[\d+\]
...
1

81
/Besitzer
Ein Voraussetzung für das Greifen der Regel ist, analog zu Beispiel 1, der Bezug der
Zugriffsentscheidungsanfrage auf den Gebäude Elementknoten. In der Condition wird
das zweite Kriterium für das Greifen der Regel, die Existenz der Besitzer-Eigenschaft zu diesem
Feature, überprüft. Dies wird erreicht, indem das Besitzer Element relativ zum resource-id
Wert analysiert wird. Ist es vorhanden, so liefert die xpath-node-count
Funktion den Wert 1. Da dieser Wert gleich dem Literal der Bedingung ist, kommt die Regel
in diesen Situationen zum Einsatz.
Beispiel 4: Zugriffsregel für einen Attributknoten
Um aufzuzeigen, wie der Zugriff auf Attributknoten des XML Dokumentes eingeschränkt
werden kann, wird in diesem Beispiel der Zugriff auf das srsName Attribut des Polygon
Elementes eines Gebäudefeatures beschränkt 28 . Sofern dieses Attribut vorhanden ist, soll es
aus dem XML Dokument entfernt werden.
...
/Request/Resource/ResourceContent/FeatureCollection\[\d+\]/
featureMember\[\d+\]/GEBAEUDE\[\d+\]/Geometrie\[\d+\]/Polygon\[\d+\]/
@srsName
...
Da der Context Handler für alle Knoten der unter ResourceContent eingefügten Ressource
individuelle Zugriffsentscheidungsanfragen generiert (entsprechende Deklaration der
resource-id und scope Attribute vorausgesetzt), wird, sobald ein Gebäudefeature in
seinem Polygon Element das Attribut srsName beinhaltet, eine Zugriffsentscheidungsanfrage
mit einem resource-id Wert wie z.B.
„/Request/Resource/ResourceContent/FeatureCollection[1]/
featureMember[5]/GEBAEUDE[1]/Geometrie[1]/Polygon[1]/@srsName“

82
abgesetzt. Da dieser den regulären Ausdruck im Resource Element des Targets erfüllt,
greift die Regel und setzt die gewünschte Zugriffsbeschränkung für dieses Attribut um.
Eine Zugriffsregel, die sich auf mehrere Featuretypen, Elemente oder Attribute beziehen soll,
kann dies durch mehrere Resource Elemente unterhalb von Resources erreichen. Bei
der Auswertung des Targets der Regel werden die Ergebnisse (Boolsche Werte) der einzelnen
Resource Elemente durch eine oder Semantik verknüpft. Alternativ kann eine Regel,
die sich auf mehrere Featuretypen, Elemente oder Attribute beziehen soll, in einzelne Regeln
(eine je Featuretyp, Element oder Attribut) umgeformt werden.
4.3.2 Deklarieren von Zugriffsregeln für bestimmte Features
In diesem Abschnitt wird gezeigt, wie inhaltsabhängige Regeln festgelegt werden können, die
den Zugriff auf Features mit gewissen Eigenschaften kontrollieren. Instanzregeln stellen eine
Verfeinerung von Typ- bzw. Element- oder Attributregeln dar und beziehen sich nur auf bestimmte
Instanzen eines Featuretyps. Bei welchen Instanzen die Regel greift, hängt von den
im Condition Element der Regel festgelegten Bedingungen ab. Man kann in den Bedingungen
der Regeln beliebige vordefinierte Funktionen nutzen, um nicht-raumbezogene Werte
aus den konkreten Featureinstanzen untereinander oder mit Literalen zu vergleichen. Welche
vergleichbaren Eigenschaften eines Features bei der Regeldefinition zur Auswahl stehen, ist
anhand des XML Schemas der Geodaten bekannt.
Wie auch bei den Typ- bzw. Elementregeln wird im Resource Element des Targets zunächst
grob bestimmt, für welche individuellen Zugriffsentscheidungsanfragen die Regel
greifen soll. Die neue Semantik – der Inhaltsbezug – der Instanzregeln wird in der Bedingung
ausgedrückt. In dieser können beliebige Prädikate formuliert werden. Die Alternative, die besondere
Semantik der Instanzregel im Target umzusetzen, wurde als unsauber und nicht
ausreichend mächtig angesehen. Das Target soll ausschließlich zur Indexierung der Regeln
dienen, um dadurch eine schnelle Auffindbarkeit passender Regeln zu gewährleisten. Außerdem
ist nur im Condition Element eine beliebig flexible Anwendung, Komposition und
Schachtelung von Funktionen zur Deklaration des Prädikates der Regelbedingung möglich.
Aufbau einer Instanzregel
Möchte die Bank festlegen, dass ihre Mitarbeiter nur Daten zu denjenigen Gebäuden sehen
dürfen, die vor 2003 gebaut wurden, so muss die unten abgebildete Regel in das Regelwerk
28 Semantisch gesehen ist diese Zugriffsbeschränkung wohl eher unsinnig. Sie dient ausschließlich zur Erklärung
der Vorgehensweise zur Beschränkung von Zugriff auf Attributknoten.

83
aufgenommen werden. Konsequenz der Regel soll sein, dass die Mitarbeiter dieses Gebäudefeature
nicht sehen dürfen, sofern das Baujahr 2003 oder später ist.
...
/Request/Resource/ResourceContent/FeatureCollection\[\d+\]/
featureMember\[\d+\]/GEBAEUDE\[\d+\]
...
/Baujahr/text()
2003
Das in der Regel definierte Target Element fordert nur dann die Auswertung der Bedingung,
sofern es sich bei dem betrachten Feature um ein Gebäude handelt. In der Bedingung
wird überprüft, ob das Gebäude im Jahr 2003 oder später gebaut wurde. Dazu wird relativ
zum resource-id Attribut über den integerInformationSelector das Baujahr
des Features selektiert und anschließend durch die integer-greater-than-or-equal
Funktion mit dem Literal 2003 verglichen.
Weitere Beispiele zu instanzbezogenen Autorisationen sind im Anhang A.3 (Beispiel 1) zu
finden.
4.3.3 Fazit
Um raumbezogene Zugriffskontrolle für Geo Web Services zu ermöglichen, wurden Typregeln,
Instanzregeln, Raumregeln und Rauminstanzregeln gefordert. Wie gezeigt wurde ist es
mit XACML möglich, beliebige Typ- und Instanzregeln für GML-kodierte Geodaten zu defi-

84
nieren. Allerdings können mit XACML keine raumbezogenen Zugriffsregeln deklariert werden.
Zunächst fehlt die Option, Regelgebiete, d.h. Geometrien mit Raumbezug, in Regeln definieren
zu können, da dieser Daten- bzw. Attributtyp nicht unterstützt wird. Des weiteren
bieten die vordefinierten XACML Funktionen, die auf den einfachen Attributtypen Integer,
Boolean, String etc. basieren, nicht die Möglichkeit, die Regelgebiete sinnvoll mit den räumlichen
Eigenschaften der angefragten Features zu vergleichen. Prinzipiell denkbar wäre der
Abgleich der Gebiete über die Funktion string-equal. Diese Variante raumbezogener
Zugriffskontrolle ist aber für die meisten Anwendungsfälle nicht ausreichend mächtig und
außerdem sehr umständlich. Die per string-equal Funktion mit den Werten aus der
Zugriffsentscheidungsanfrage verglichenen Regelgebiete würden nur als ein eindeutiger
Schlüssel zur Identifikation der Features dienen.
Statt eines Identitätsabgleichs auf Basis der Geometrie der Gebiete ist es deutlich mächtiger,
die Topologie, d.h. die gegenseitige Anordnung im Raum zwischen den Regelgebieten und
den Gebieten der Featureinstanzen für Raumregeln zu nutzen. Das Ausnutzen der topologischen
Relationen zwischen den Regelgebieten und den Gebieten der Featureinstanzen ist eine
Voraussetzung für mächtige raumbezogene Zugriffsregeln. Dadurch ist es möglich, dass sich
eine einfache Raumregel gezielt auf eine bestimmte Menge an Features bezieht, ohne in der
Regel direkt Bezug (z.B. durch die Überprüfung der FeatureID – ein eindeutiger Identifikator
für ein Feature) auf die entsprechenden Features zu nehmen.
Die zur Umsetzung raumbezogener Zugriffsregeln benötigte Erweiterung des XACML Standards
sowie das Abbilden der Raumregeln im erweiterten XACML wird in Kapitel 5 behandelt.

85
5 Raumbezogene Zugriffskontrolle mit XACML
Für Geo Web Services, die Zugriff auf Geodaten ermöglichen, können raumbezogene
Zugriffsregeln die Definition komplexer Regelwerke deutlich vereinfachen. Durch Raumregeln
ist es möglich, einfache aber mächtige Zugriffsrechte auf den Features zu deklarieren. Da
Features einen Raumbezug sowie eine Ausdehnung haben, kann der Zugriff auf diese geographischen
Objekte durch Zugriffsrechte eingeschränkt werden, die sich auf den Raumbezug
der Objekte beziehen.
Hierzu stelle man sich eine Zugriffsregel vor, die sämtliche Daten jener Gebäude zugriffsbeschränken
soll, die weniger als zehn Kilometer von der Staatsgrenze entfernt sind. Als Raumregel
wäre dies umsetzbar, indem die Grenze als Linienzug angegeben wird und die Gebiete
der angefragten Gebäudeinstanzen mit Hilfe der Relation isWithinDistance bezüglich
ihrer Lage zu diesem Linenzug abgeglichen werden. Wenn die Geometrie eines angefragten
Gebäudefeatures die Relation erfüllt, wird die Raumregel angewendet und der Zugriff abgelehnt.
Für die Definition einer entsprechenden Instanzregel müsste der SSO alle FeatureIDs, der im
Umkreis von zehn Kilometer liegenden Gebäude ermitteln, diese explizit in die Instanzregel
aufnehmen und sie mit den FeatureIDs der angefragten Features vergleichen. Hierfür muss allerdings
vorausgesetzt werden, dass jedes Gebäudefeature (z.B. über eine FeatureID) eindeutig
identifizierbar ist und dass für den SSO bestimmbar ist, welche Gebäude weniger als zehn
Kilometer von der Staatsgrenze entfernt liegen.
Wie man sieht ist die Definition einer Raumregel deutlich einfacher als die einer Instanzregeln
und zudem ist Erstere stabiler gegenüber einer Dynamik der Datenbasis, die dem Geo
Web Services zugrunde liegen kann. Sollten z.B. die Daten eines im Grenzgebiet neu errichteten
Gebäudes über den Geo Web Service zugänglich sein, so muss, um diese vor unautorisierten
Zugriffen zu schützen, die Instanzregel um die ID dieses Features ergänzt werden. Die
oben beschriebene wirkungsgleiche Raumregel könnte dagegen unverändert bleiben und würde
die Daten zu dieser neuen Gebäudeinstanz dennoch vor Zugriffen schützen.
Ein weiterer Vorteil der Raumregeln ist, dass durch das Spezifizieren beliebiger topologischer
Relationen in den Regeln komplexe Beziehungen zwischen den Regelgebieten und den Gebieten
der Featureinstanzen überprüft werden können (z.B. die Nachbarschaftsbeziehung).
Möchte ein SSO beispielsweise, dass Daten zu den Gebäuden, die neben einer Bank liegen,
zugriffsgeschützt sind, so kann er dies durch Angabe des Bankgebäudegebiets und der Relation
„touches“ einfach umsetzen.
Neben der Eigenschaft einfache, stabile und mächtige Zugriffsregeln ausdrücken zu können,
bieten Raumregeln noch zwei weitere Vorteile. Einerseits ist es möglich unter gewissen Vorraussetzungen,
ungewollte Regelkonflikte zu erkennen und zu behandeln. Da dies allerdings
ein eigenes, sehr umfangreiches Problemfeld darstellt, wird im Rahmen dieser Arbeit nicht

86
näher darauf eingegangen. Ebenso vorteilhaft ist die Möglichkeit, die Zuständigkeitsgebiete
der SSOs an den Raumbezug zu binden. So kann z.B. SSO A für die Gebäudedaten in Bayern
und SSO B für die Gebäudedaten in Sachsen verantwortlich sein. Dies bedeutet, dass die
SSOs nur Raumregeln definieren dürfen, die sich auf ihr Zuständigkeitsgebiet beziehen.
Im Folgenden wird beschrieben, wie Raumregeln deklariert werden können. Im Anschluss
wird behandelt, welche Methoden und Datentypen ein Zugriffskontrollsystem unterstützen
muss, um Raumregeln definieren und auswerten zu können. Im letzten Abschnitt dieses Kapitels
(5.4) wird darauf eingegangen, wie Pre-Processing in einem XACML-basierten Zugriffskontrollsystem
umgesetzt werden kann.
5.1 Raumbezogene Zugriffsregeln
Ein SSO kann bei der Definition einer Raumregel geometrische Objekte, die Regelgebiete,
festlegen. Dazu muss er für jeden Featuretyp die zugriffsbeschränkten und zugreifbaren Gebiete
identifizieren. In Abhängigkeit der Lage der Features zu den Regelgebieten kann der
Zugriff auf die Features gezielt kontrolliert werden. Zum Vergleich der Regelgebiete mit den
räumlichen Eigenschaften der angefragten Features müssen letztere in den Raumregeln adressiert
werden. Da die Rauminformation je Featuretyp an unterschiedlicher Tiefe sowie Stelle
im Dokumentbaum liegen kann und diese zudem nicht über einen standardisierten einheitlichen
Knotennamen identifizierbar ist, müssen die raumbezogenen Zugriffsbeschränkungen in
Abhängigkeit des Featuretyps erfolgen.
Die Beschreibung der Regelgebiete erfolgt vektororientiert und soll dem GML Standard (siehe
2.2) genügen. In Raumregeln sind daher folgende geometrische Typen angebbar:
• Punkt • Multipunkt
• Linienzug • Multilinienzug
• Polygon • Multipolygon
Die heterogenen GeometryCollections werden bewusst nicht als Datentyp für Regelgebiete
bzw. als Argumente für die räumlichen Relationen zugelassen, da nicht eindeutig definiert ist,
welche Semantik topologische Operationen auf zwei GeometryCollections haben (vgl. JTS
Tech Spec 1.4, S. 27).
Prinzipiell wären auch komplexere geometrische Objekte wie Bezierkurven, Kreise, Ellipsen
usw. in den Regeln möglich. Da diese aber nicht in GML beschreibbar sind, werden sie in

87
dieser Arbeit nicht betrachtet und stehen daher nicht zur Definition der Regelgebiete im Prototypen
zur Verfügung.
Durch räumliche Analysen in den Raumregeln wird die Rauminformation der angefragten
Features untersucht. Verwendet werden können dazu die im Folgenden aufgeführten topologischen
Relationen und räumlichen Operationen.
Eine topologische Operation überprüft die Lage zweier Geometrien zueinander. Eine räumliche
Operation berechnet Zahlenwerte auf Basis der Geometrie(n) (z.B. die Länge eines Linienzuges),
die dann zur Bestimmung einer Zugriffsentscheidung genutzt werden können.
Topologische Operationen:
• equals • crosses
• disjoint • overlaps
• intersects • within
• touches • contains
Topologische Operationen sind boolesche Methoden, die sofern die entsprechende topologische
Relation zwischen zwei Geometrien erfüllt ist, wahr als Ergebniswert liefern. Zur Erklärung
der Semantik der einzelnen Relationen werden die Begriffe das Innere, der Rand
und das Äußere einer Geometrie verwendet, die aus diesem Grund kurz erklärt werden.
Der Rand einer Geometrie ist eine Menge an Geometrien nächst niedrigerer Dimension. Der
Rand eines Punktes ist daher die leere Menge. Bei einem nicht geschlossenen Linienzug sind
es die beiden Endpunkte. Der Rand eines linearen Ringes ist die leere Menge. Bei einem Polygon
sind es die ihn definierenden Ringe (äußerer Rand und innere Ränder).
Das Innere einer Geometrie stellen alle Punkte der Geometrie dar, die nicht zum Rand gehören.
Der die Geometrie umgebende Raum, d.h. alle Punkte, die nicht zum Rand oder zum Inneren
der Geometrie gehören, wird als Äußeres der Geometrie bezeichnet (vgl. OGC SFS 1.1, S.
24 und 25 bzw. 2-12 und 2-13 29 ).
29 In der pdf Quelle OGC SFS 1.1 wird eine selbstdefinierte Seitenummerierung verwendet. Daher wird für Referenzen
auf diese Quelle in dieser Arbeit neben der dort verwendetet Seitennummerierung die Seitenzahl nach
Adobe Acrobat 6.0 angegeben.

88
A) Kommutative topologische Operationen, die beliebige Geometrietypen als Argumente
zulassen:
equals
Abbildung 5.1 Zwei Geometrien, welche die equals Relation erfüllen
Zwei Geometrien sind topologisch identisch, wenn sich das Innere der beiden Geometrien
schneidet und wenn sich kein Teil des Inneren oder des Rands einer Geometrie mit dem Äußeren
der anderen Geometrie schneidet (vgl JTS Tech Spec 1.4, S. 26). Topologische Identität
fordert nicht, dass die Geometrien exakt gleich definiert worden sind. Zum Beispiel sind
die Linien, definiert durch die Koordinaten 0,0 0,5 0,10 und 0,0 0,4 0,6 0,10 zwar topologisch
aber nicht exakt identisch. Für die Definition von Raumregeln wird in dieser Arbeit nur die
topologische Identität betrachtet.
disjoint
Abbildung 5.2 Zwei Geometrien, welche die disjoint Relation erfüllen
Disjoint evaluiert zu wahr, wenn die Geometrien keinen gemeinsamen Punkt haben.

89
intersects
Abbildung 5.3 Zwei Geometrien, welche die intersects Relation erfüllen
Intersects evaluiert zu wahr, wenn die Geometrien mindestens einen gemeinsamen
Punkt haben. Intersects entspricht der negierten disjoint Relation
(d.h. A.intersects(B) not(A.disjoint(B)).
B) Kommutative topologische Operationen, die nicht für alle Kombinationen von Geometrien
definiert sind:
touches
Abbildung 5.4 Zwei Geometrien, welche die touches Relation erfüllen
Diese Operation evaluiert zu wahr, wenn die gemeinsamen Punkte der beiden Geometrien in
der Vereinigungsmenge beider Ränder liegen. Der Vergleich zweier Punkte oder zweier Multipunktmengen
per touches ist undefiniert, da diese geometrischen Objekte keinen Rand
besitzen.

90
crosses
Abbildung 5.5 Zwei Geometrien, welche die crosses Relation erfüllen
Crosses evaluiert zu wahr, wenn folgende Bedingungen erfüllt sind (OGC SFS 1.1, S. 63
bzw. 3-21):
• Die Dimension derjenigen Geometrie, welche die Schnittmenge von G 1 und G 2 darstellt,
ist kleiner als das Maximum der Dimensionen von G 1 und G 2 .
• Die Schnittmenge von G 1 und G 2 enthält Punkte die zugleich im Inneren von G 1 und G 2
liegen.
• Die Schnittmenge von G 1 und G 2 entspricht weder G 1 noch G 2 .
Die crosses Operation ist für die Argumentkombinationen (Punkt, Punkt), (Multipunkt,
Multipunkt), (Polygon, Polygon) und (Multipolygon, Multipolygon) undefiniert.
overlaps
Abbildung 5.6 Zwei Geometrien, welche die overlaps Relation erfüllen
Die overlaps Operation zwischen zwei Geometrien G 1 und G 2 gibt wahr zurück, wenn die
Dimension der Schnittmenge der beiden Geometrien gleich der Dimension von G 1 und G 2 ist.
Zusätzlich muss gelten, dass die Schnittmenge weder G 1 noch G 2 entspricht. Daraus folgt,
dass die overlaps Relation für die Argumentkombinationen {(Multi-)Punkt, (Multi-
)Linie}, {(Multi-)Punkt, (Multi-)Polygon} und {(Multi-)Linie, (Multi-)Polygon} nicht definiert
ist (OGC SFS 1.1, S. 63 bzw. 3-21).

91
C) Nicht kommutative topologische Operationen, die für alle Kombinationen von Geometrien
anwendbar sind:
within
Abbildung 5.7 Zwei Geometrien, welche die within Relation erfüllen
Die Operation G 1 within G 2 evaluiert zu wahr, wenn alle Punkte der Geometrie G 1 im Inneren
oder auf dem Rand der Geometrie G 2 liegen.
contains
Abbildung 5.8 Zwei Geometrien, welche die contains Relation erfüllen
A.contains(B) B.within(A)
Anstelle der contains Operation kann durch Vertauschen der Argumente immer die
within Operation verwendet werden.
Die Tabellen im Anhang B zeigen, welche sinnvollen Vergleichsmöglichkeiten zwischen
zwei Geometrien in Abhängigkeit ihres Typs mit den genannten topologischen Operationen
bestehen. Dadurch wird beschrieben, welche topologischen Relationen bei der Definition von
Raumregeln zur Verfügung stehen, wenn die Instanz- und/oder Regelgeometrien gegeben
sind (oder umgekehrt: welche Regelgebiete möglich sind, wenn Relation und Featuregeomet-

92
rie gegeben sind). Zudem wird im Anhang B darauf eingegangen, welche Semantik die Relationen
angewandt auf MultiGeometrietyp-Datentypen haben.
Die Operationen contains und intersects überprüfen gegenüber within und disjoint
keine neue Art der Lagebeziehung zwischen zwei Geometrien. Die Unterstützung
dieser Operationen dient ausschließlich einem erhöhten Komfort bei der Definition von
Raumregeln.
Neben topologischen Operationen können in den Raumregeln zusätzlich folgende räumliche
Operationen auf den Geometrien der Features angewendet werden:
Räumliche Operationen:
• length
• area
• distance
• isWithinDistance
length (Geometrie x)
Handelt es sich bei der Geometrie um einen Linienzug, so wird dessen Länge bestimmt. Wird
die length Funktion auf ein Polygon angewendet, so wird der Umfang des Polygons berechnet.
area (Polygon a)
Die area Funktion angewandt auf ein nicht leeres Polygon berechnet dessen Fläche.
distance (Geometry x, Geometry y)
Die distance Funktion berechnet die minimale Distanz zwischen zwei Geometrien.
isWithinDistance (Geometry x, Geometry y, double d)
Die isWithinDistance Funktion prüft, ob die minimale Distanz zwischen zwei Geometrien
kleiner gleich dem Wert d ist. Der Rückgabewert dieser Funktion ist daher Boolean.
Operationen auf Geometrien, die neue Geometrien erzeugen (z.B. intersection, union
oder difference), sollen in dieser Arbeit nicht betrachtet werden. Es wird davon ausgegangen,
dass der SSO die entsprechenden Berechnungen vor Definition seiner Regeln durch-

93
führt und die endgültigen Regelgeometrien in den Regeln festlegt. Sollte es in speziellen Anwendungsfällen
nötig sein, diese Operationen auf die Regelgeometrie und/oder auf die Geometrie
einer Featureinstanz anzuwenden, kann das Zugriffskontrollsystem durch kleine Zusätze,
nach dem gleichen Schema wie die Umsetzung der oben vorgestellten Funktionen (vgl.
6.2.2 oder 6.3.3), erweitert werden.
Welche der möglichen Relationen bzw. Operationen in den Raumregeln verwendet werden
sollen, hängt ausschließlich von der vom SSO gewünschten Semantik der Regeln ab. Beispielsweise
kann man zugriffsbeschränkte Gebiete per intersects Operation in einer negativen
30 Raumregel mit den Gebieten der Features vergleichen. Durch diese Operation wird
erreicht, dass ein angefragtes Feature, sobald es einen gemeinsamen Punkt mit dem zugriffsbeschränkten
Gebiet hat, nicht mehr zugreifbar ist. Möchte man allerdings eine Regelsemantik
ausdrücken, die definiert, dass der Zugriff auf eine Featureinstanz nur dann verboten werden
soll, wenn diese komplett im zugriffsbeschränkten Gebiet liegt, so ist die within Operation
zu verwenden.
5.2 Auswerten der topologischen Relationen
Davon ausgehend, dass in Raumregeln topologische Relationen definiert worden sind, ist ein
entscheidender Arbeitsschritt bei der Anwendung einer raumbezogenen Regel die Überprüfung
der in der Regel spezifizierten Relation. Zur Vereinfachung wird für die nachfolgenden
Ausführungen angenommen, dass raumbezogene Daten zum selben SRS definiert worden
sind. Wie bei unterschiedlichen Raumbezugssystemen zu verfahren ist, wird in Kapitel 6.3.4
detailliert behandelt.
Mit dem Dimensionally Extended Nine-Intersection Matrix Model (DE-9IM Model, vgl.
OGC SFS 1.1, S. 25 bis 32 bzw. 2-13 und 2-20) können räumliche Relationen zwischen
Punkten, Linien und Flächen (gegebenenfalls mit Löchern) beschrieben werden. Prinzipielles
Vorgehen bei der Überprüfung der Lage zweier Geometrien zueinander ist der paarweise Test
der Schnittmengen zwischen den Rändern, dem Inneren und dem Äußeren der Geometrien.
Dadurch kann eine so genannte „intersection“ Matrix aufgestellt werden. Es handelt sich um
eine 3x3 Matrix, in der die maximale Dimension der Geometrien, die sich aus dem Schnitt der
Ränder, der inneren und äußeren Gebiete der zu vergleichenden Objekte ergibt, gespeichert
ist.
Abbildung 5.9 zeigt eine „intersection“ Matrix nach dem DE-9IM Modell für zwei sich überlappende
Polygone.
30 Zur Erinnerung: Regel mit negativem Effekt (Definition siehe 3.1.2)

94
Intersection Matrix
B
Innere Rand Äußere
Innere 2 1 2
A Rand 1 0 1
Äußere 2 1 2
Abbildung 5.9 „intersection“ Matrix für zwei sich überlappende Polygone (angelehnt an OGC SFS
1.1, S. 25 bzw. 2.14)
Auf Basis der Einträge in der Matrix kann man nun überprüfen, ob eine räumliche Relation
zwischen den Geometrien vorliegt. Dazu wird die „intersection“ Matrix mit einer so genannten
„pattern“ Matrix verglichen, die in Abhängigkeit der zu überprüfenden Relation unterschiedlich
aufgebaut ist. Genügt die „intersection“ Matrix der „pattern“ Matrix (vergleichbar
mit: genügt ein String einem regulären Ausdruck) so liegt die Relation vor, die durch diese
„pattern“ Matrix repräsentiert wird. Möchte man demnach für obiges Beispiel überprüfen, ob
die Geometrien A und B die overlaps Relation erfüllen, so wird die „intersection“ Matrix –
repräsentiert als ein Array mit 9 Einträgen (2, 1, 2, 1, 0, 1, 2, 1, 2) – mit der „pattern“ Matrix
zur overlaps Relation (T,*, T, *, *, *, T, *, *) verglichen. Während das * Zeichen sagt, dass
die Dimension der entsprechenden Schnittmenge beliebig ist, fordert T von der Dimension
der Schnittmenge, dass sie definiert sein muss (d.h. sie muss 0, 1, oder 2 entsprechen). Da die
„intersection“ Matrix in diesem Beispiel der „pattern“ Matrix zur overlaps Relation genügt,
kann gefolgert werden, dass die Polygone A und B sich überlappen.
Durch das vorgestellte DE-9IM Modell kann die in den Raumregeln angegebene Relation
zwischen dem Regelgebiet und dem Gebiet eines Features überprüft werden. Einzige Vorraussetzung
ist, dass es sich bei den zu vergleichenden Geometrien um topologisch geschlossene
Körper handelt, wovon in dieser Arbeit ausgegangen wird. Für detailiertere Informationen
zur Berechnung der „intersection“ Matrix wird auf die JTS Spezifikation (JTS Tech Spec
1.4, S. 22 ff) verwiesen.

96
5.3.2 Erweiterung der XACML Funktionen
Wie bereits im Fazit des Kapitels 4 erörtert wurde sind die in XACML vordefinierten Funktionen
für die Umsetzung raumbezogener Zugriffskontrolle nicht geeignet. Die unter 5.1 diskutierten
topologischen und räumlichen Operationen müssen daher in XACML nutzbar gemacht
werden. Wie dies erreicht werden kann soll in diesem Abschnitt demonstriert werden. Zur
Vereinfachung und Konzentration auf das Wesentliche wurden die irrelevanten Teile der Regel
weggelassen.
Beispiel: Deklaration einer topologischen Relation in XACML
...
280,340
/GEBAEUDE/Geometrie/gml:Polygon
...
Wie man sieht, ist die Umsetzung einer topologischen Relation sehr ähnlich der Verwendung
der in XACML vordefinierten Funktionen (vgl. XACML Spec 1.1, S. 25-46). Per Apply
und FunctionId wird die touches Funktion deklariert. Da die touches Relation zwei Geometrien,
d.h. also zwei spatial Argumente, als Eingabe erwartet, muss sie entsprechend
aufgerufen werden. Das erste Argument der Funktion im Beispiel ist ein Punkt (GMLkodiert)
und hat den Attributtyp spatial (vgl. 5.3.1). Das zweite Argument – eine räumliche
Eigenschaft eines Features – wird durch einen spatialInformationSelector adressiert (vgl.
4.2.5). Durch die Deklaration spatialInformationSelector wird der Rückgabedatentyp des InformationSelectors
implizit angegeben. Da in InformationSelectoren die Auswertung von
XPath-Ausdrücken erfolgt und diese potentiell eine Menge an Knoten zurückliefern kann, ist
der Rückgabewert des spatialInformationSelectors eine Menge an Attributen vom Typ spatial.
Um genau eine Geometrie zur Weiterverarbeitung über die touches Funktion bereitzustellen,
wird die spatial-one-and-only Funktion auf die vom spatialInformationSelector
zurückgegebene Menge angewendet. Damit wird erzwungen, dass die vom spatialInformationSelector
selektierte Menge einelementig ist.

97
5.3.3 Aufbau einer Raumregel
Nachdem vorgestellt wurde, wie topologische Relationen und die Argumente mit Rauminformation
angegeben bzw. adressiert werden können, wird nun der Aufbau einer Raumregel
beschrieben.
Wie schon bei den Instanzregeln (siehe 4.3.2) erörtert wurde, ist auch bei den raumbezogenen
Regeln das Condition Element der geeignete Ort, um die raumbezogenen Regelprädikate
zu definieren. Nur dort ist in XACML völlige Freiheit bei der Definition der Funktionen gegeben.
Das Target wird unter anderem dazu verwendet, den Bezug zu einem Featuretyp
herzustellen, da die Raumregeln in Abhängigkeit von diesem definiert werden müssen. Dazu
kann es wie in den Typ- und Instanzregeln definiert werden. Greift das Target der Raumregel
zu einer konkreten individuellen Zugriffsentscheidungsanfrage und evaluiert das Prädikat
des Bedingungsteils, welches die räumlichen Analysen definiert, zu „wahr“, so ist die raumbezogene
Regel anwendbar und fließt bei der Bestimmung der Zugriffsentscheidung mit ein.
Beispiel: Aufbau einer raumbezogenen Zugriffsbeschränkung
Die unten abgebildete Raumregel verbietet den Zugriff auf Gebäudefeatures, sofern sie zum
Teil in Gebiet A liegen, welches durch das Polygon (20,380 40,200 240,140 360,260 340,380
200,400 100,400 20,380) definiert ist.
/Request/Resource/ResourceContent/FeatureCollection\[\d+\]/
featureMember\[\d+\]/GEBAEUDE\[\d+\]&
/Geometrie/gml:Polygon

98
20,380 40,200 240,140 360,260 340,380 200,400 100,400 20,380
Auf Grund obiger Target Definition kann die Regel nur dann zur Anwendung kommen,
wenn sich die individuelle Zugriffsentscheidungsanfrage auf einen Gebäudeknoten eines vom
Nutzer angefragten Gebäudefeatures bezieht. Unter der Voraussetzung, dass die Auswertung
des Targets zu „wahr“ evaluierte, wird die Condition überprüft. Im Beispiel entspricht
dies der Anwendung der intersects Relation auf zwei Geometrien. Erstere stellt den Grundriss
einer angefragten Gebäudeinstanz in Form eines Polygons dar, die über den spatialInformationSelector
adressiert wird. Die zweite Geometrie ist das vom SSO festgelegte, zugriffsbeschränkte
Regelgebiet A, ebenfalls in Form eines Polygons. Ergibt die Auswertung der intersects
Relation „wahr“, so greift die Regel und der Zugriff auf die entsprechende Gebäudeinstanz
wird verboten.
Im Anhang A.3 bzw. auf der CD-ROM finden sich zahlreiche weitere Beispiele zu Raumregeln.
Diese veranschaulichen zum einen die Möglichkeiten, die raumbezogene Zugriffsregeln
bieten und zum anderen dienen sie als Testfälle zur Validierung der im Kapitel 6 vorgestellten
Implementierung.
Erwähnt sei noch, dass bei Geodaten ein Raumbezug an mehreren Stellen auftreten kann. Zunächst
hat das geographische Feature selbst einen Raumbezug. Zusätzlich können Kind-
Elemente des Features einen eigenen, unabhängigen Raumbezug haben. Für die Syntax der
Raumregeln spielt diese Unterscheidung allerdings keine Rolle und die unter 5.3 vorgestellten
Techniken zur Definition von Raumregeln sind für beide Fälle in gleicher Weise anwendbar.
Des weiteren ist es möglich, dass ein Raumbezug durch den aktuellen Standort des Web Service
Nutzers gegeben ist. Dieser kann in der Zugriffsentscheidungsanfrage mit übergeben
werden und ebenfalls durch die oben vorgestellten Raumregeln überprüft werden (vgl Beispiel
2 im Anhang A.3).

99
5.3.4 Der RaumInstanz Regeltyp
Eine RaumInstanz Regel ist die Kombination einer Instanz- und einer Raumregel. In ihr können
die Zugriffsrechte auf Features in Abhängigkeit der räumlichen und nicht räumlichen Eigenschaften
der Features festgelegt werden. Für die Verwendung des Target Elements gilt
das bereits für die Instanz- und Raumregeln Gesagte. Instanz- und Raumregeln unterscheiden
sich nur durch ihre Prädikatausdrucke im Condition Element. Eine RaumInstanz Regel
verknüpft die unterschiedlichen Prädikate durch logische Operatoren im Condition Element.
Um dies zu verdeutlichen, soll die Raumregel aus Beispiel 5.3.3 mit der Instanzregel
aus Beispiel 4.3.2 zu einer RaumInstanz Regel erweitert werden.
Beispiel: Aufbau einer RaumInstanz Regel
Ein SSO möchte durch eine Zugriffsregel definieren, dass Zugriff auf Daten zu jenen Gebäudefeatures
verboten ist, die im Jahr 2003 oder später gebaut wurden und die zum Teil in Gebiet
A liegen. Eine XACML Regel, die diese Semantik ausdrückt, hat folgenden Aufbau:
/Request/Resource/ResourceContent/FeatureCollection\[\d+\]/
featureMember\[\d+\]/GEBAEUDE\[\d+\]
/Baujahr/text()
2003

100
/Geometrie/gml:Polygon
20,380 40,200 240,140 360,260 340,380 200,400 20,380
Der orange markierte Teil der Condition entspricht der Bedingung der Instanzregel und
der rot gekennzeichnete Teil drückt die Relation der Raumregel aus. Verknüpft werden die
Regelsemantiken über die „and“ Funktion.
Um ungewollte „nicht auswertbar“ Zustände zu vermeiden, muss bei der Definition von
RaumInstanz Regeln beachtet werden, dass sich die Regelbedingungen ausschließlich auf sicher
existente Knoten stützen (vgl. C.6).
Aufgrund verkürzten Auswertung (short circuit evaluation ; siehe Brügge 2000) der Operanden
in XACML (XACML Spec 1.1, S. 100 ff) sollten raumbezogene Bedingungen am Ende
des Bedingungsteils der RaumInstanz Regeln auftauchen, da diese am „teuersten“ zu überprüfen
sind. Durch vorherige performantere Bedingungen kann dadurch in bestimmten Fällen die
Überprüfung der raumbezogenen Bedingungen eingespart werden.
Erwähnt sei an dieser Stelle, dass alle bislang vorgestellten Regeltypen für Zugriffskontrolle
nach dem Post-Processing Ansatz um Bedingungen, die unabhängig von den Ressourcen sind,
erweitert werden können. Diese Bedingungen stützen sich z.B. auf den Kontext des Zugiffskontrollsystems.
Dieser ist durch AttributeDesignatoren referenzierbar, die Attribute im
Environment Element der Zugriffsentscheidungsanfrage selektieren. Dadurch ist es möglich,
die vorgestellten inhaltsbezogenen und raumbezogenen Zugriffsregeln um kontextabhängige
Autorisationen zu ergänzen.
Bislang wurden sämtliche Zugriffsregeln isoliert betrachtet. Wie Regeln beliebigen Typs in
einem Regelwerk organisiert werden und welche Strukturierungsmöglichkeiten sich bieten,
ist stark vom Anwendungsfall abhängig. Es ist kaum möglich, einen für beliebige Situationen

101
sinnvollen Strukturierungsvorschlage zu machen. Dennoch wird im Anhang C exemplarisch
gezeigt, wie ein Regelwerk mit den vorgestellten Regeltypen strukturiert werden kann, welche
Alternativen es gibt und worauf bei der Organisation geachtet werden muss. Dort wird
auch auf die sich durch den Raumbezug ergebende Möglichkeit einer speziellen Organisation
der Raumregeln eingegangen, die auf dem Clustering Prinzip basiert. Ergänzt werden diese
Vorschläge um Prinzipien die bei der Definition von Zugriffsregeln empfehlenswert sind.
5.4 Pre-Processing mit XACML
Nachdem in den vorangegangenen Abschnitten ausführlich diskutiert wurde, wie ein Regelwerk
zur Unterstützung von Zugriffskontrolle nach dem Post-Processing Ansatz für lesende
Aktionen auf den Daten des Geo Web Services definiert werden kann, soll in diesem Abschnitt
betrachtet werden, welche Konsequenzen die Verwendung des Pre-Processing Ansatzes
für das Zugriffskontrollsystem und den Aufbau der Regeln hat.
Es wird zunächst Zugriffskontrolle für die modifizierenden Aktionen „einfügen“ und „updaten“
betrachtet. Im Anschluss wird die Umsetzung von Zugriffsregeln, die sich auf die Löschoperation
beziehen, diskutiert. Zuletzt wird darauf eingegangen, wie der Pre-Processing Ansatz
als Alternative zum Post-Processing Ansatz für Zugriffskontrolle bei lesende Aktionen
genutzt werden kann. Hierfür werden die Beispiele, die in den Erläuterungen zum Post-
Processing (vgl. Kapitel 4 und 5 ohne 5.4) verwendet wurden, auf den Pre-Processing Fall
übertragen.
5.4.1 Die Einfügeoperation
Wenn ein Subjekt auf einem Geo Web Service eine Einfügeoperation ausführen möchte, so
muss es dem Geo Web Service in dieser Transaktion die Daten zu dem neu einzufügenden
Feature mitteilen.
Beispiel einer Einfügetransaktion auf einem WFS (vereinfachte Syntax):
-98.54,24.26...

102
Muenchner Rathaus
1901
Staat
5
...
Nachdem ein Subjekt eine Einfügeanfrage abgesetzt hat, wird im PEP der Prozess der
Zugriffskontrolle angestoßen. Nach Überprüfung der Zugriffsregeln und positiver Zugriffsentscheidung
wird die Anfrage zur Bearbeitung an den Web Service weitergeleitet.
In diesem Prozess erzeugt der PEP vergleichbar zum Vorgehen bei der Post-Processing Variante
eine globale Zugriffsentscheidungsanfrage. Unterschied ist allerdings, dass der PEP die
Anfrage an den Web Service für eine Einfügeaktion im ResourceContent Element der
globalen Zugriffsentscheidungsanfrage übergibt. Da in diesem XML Dokument sämtliche Information
zu den neu in die Datenbasis des Geo Web Services aufzunehmenden Features enthalten
sind, kann man auf Basis dieser Daten feingranulare, inhaltsabhängige und raumbezogene
Zugriffsregeln definieren.
In den Regeln muss unter anderem wieder spezifiziert werden, auf welche Knoten des XML
Dokumentes – in diesem Fall die Einfügeanfrage – sich die Zugriffsregeln beziehen und welche
Bedingungen erfüllt sein müssen, damit die Regeln anwendbar sind. Dies kann analog zu
dem für Post-Processing beschriebenen Verfahren geschehen. In den Zugriffsregeln wird zunächst
geprüft, ob der Nutzer das Recht, hat neue Features in die Datenbasis des Web Services
einzutragen. Zudem kann spezifiziert werden, welche Bedingungen die neu aufzunehmenden
Daten erfüllen müssen. Hierdurch lassen sich neben den Autorisationen zusätzlich Integritätsbedingungen
überprüfen (vgl. Trigger und Check-Constraints Konzept in Datenbankmanagementsystemen).
Die vom PDP, je Knoten der Web Service Anfrage generierten individuellen Zugriffsentscheidungen
teilen dem PEP mit, ob der Nutzer
• zu einer Einfügeoperation bemächtigt ist,
• Features eines bestimmten Typs einfügen darf (Typregel für die Einfügeoperation) und
• Features mit gewissen räumlichen bzw. nicht-räumlichen Eigenschaften einfügen darf
(Raumregel und Instanzregel für die Einfügeoperation).
Bei unzureichenden Rechten stehen im PEP zwei mögliche Verfahrensweisen zur Auswahl:
• Sofern eine Zugriffsentscheidungsantwort dem PEP als Ergebnis „Zugriff beschränkt“
mitteilt, kann er die Einfügeoperation abweisen. Dies entspricht dem „alles oder nichts“
Prinzip.

103
• Andererseits kann der PEP auf negative Zugriffsentscheidungsantworten die Einfügeanfrage
in der Art modifizieren, dass sie zu einer autorisierten Anfrage wird. Hierzu stehen
ebenfalls zwei Varianten zur Verfügung:
o Der PEP kann zugriffsbeschränkte Knoten, d.h. Daten des einzufügenden Features,
aus der Einfügeanfrage nehmen. Dies bedeutet, dass einige Werte des
einzufügenden Features gelöscht werden und dieses im Anschluss in modifizierter
Form in der Datenbasis des Web Services gespeichert wird.
o Einen Schritt weiter könnte man gehen, indem zu den Zugriffsregeln Obligations
definiert werden, die dem PEP mitteilen, durch welchen Wert er
den einzufügenden aber zugriffsbeschränkten Knoten ersetzen soll.
Da fragwürdig ist, ob das Modifizieren der Einfügeanfrage durch das Zugriffskontrollsystem
in konkreten Anwendungsszenarien sinnvoll oder wünschenswert ist, wird in dieser Arbeit für
Zugriffskontrolle bei Einfügeoperationen das „alles oder nichts“ Prinzip verfolgt.
Im Verzeichnis policy auf der CD-ROM finden sich Regelbeispiele, die zeigen, welche Möglichkeiten
Zugriffsregeln für die Einfügeoperation bieten.
5.4.2 Die Update-Operation
Ähnlich zur Einfügeoperation können Zugriffsregeln für die Update-Operation spezifiziert
werden. Der PEP fügt in diesem Fall die vom Nutzer an den Web Service abgesetzte Update-
Transaktion (s.u.) in die Zugriffsentscheidungsanfrage ein.
Beispiel einer Update-Aktion auf einem WFS (vereinfachte Syntax):
Anzahl_Spuren
3
Anzahl_Spuren
3
Geometrie

104
50,40 100,60 ...
In den Zugriffsregeln zu dieser Aktion kann ausgedrückt werden, unter welchen Voraussetzungen
ein Nutzer die Möglichkeit hat, die Daten der Features in der Datenbasis des Web
Services zu modifizieren. Zudem kann eine Überprüfung der einzufügenden Daten erfolgen.
Für Beispielregeln wird wieder auf die Beispiele im Verzeichnis policy auf der CD-ROM verwiesen.
Wie bereits in den Ausführungen zur Einfügeoperation erörtert, ist es zweifelhaft, ob ein
Zugriffskontrollsystem bei unzureichenden Autorisationen eine modifizierte Update-Anfrage
an den Geo Web Service weiterleiten sollte. Daher wird auch für diese Operation angenommen,
dass das Zugriffskontrollsystem bei nur einer zugriffbeschränkenden individuellen
Zugriffsentscheidungsantwort die gesamte Web Service Anfrage ablehnt („alles oder nichts“
Prinzip).
5.4.3 Die Löschoperation
In der Löschtransaktion wird festgelegt, welche Features aus der Datenbasis des Geo Web
Services gelöscht werden sollen (siehe unten abgedrucktes Beispiel). Zur Selektion der Features,
die vom Löschvorgang betroffen sein sollen, muss der Featuretyp sowie ein Filter (vgl.
OGC Filter Spec 1.0) angegeben werden. Diese Informationen können neben den Informationen
zum Subjekt bei der Definition von Zugriffsregeln zur Löschoperation verwendet werden.
Beispiel einer Löschtransaktion auf einem WFS (vereinfachte Syntax):
Es werden alle Features vom Typ „Bankautomat“ gelöscht, die sich innerhalb des in der
Löschoperation spezifizierten Gebiets (das Polygon) befinden.
Geometrie
-95.7,38.1-97.8,38.2...

105
Vorab sei erwähnt, dass Typ- bzw. Element- und Attributregeln, wie z.B. der Nutzer XY darf
Features vom Typ Gebäude löschen, analog zu dem bisher Erläuterten und daher einfach umzusetzen
sind. Beispiele zu Typ- bzw. Element- und Attributregeln für die Löschoperation
finden ebenfalls auf der beiliegenden CD-ROM.
Problematischer ist allerdings die Umsetzung von Zugriffsregeln, die sich auf das Löschen
bestimmter Instanzen beziehen, da sich diese Instanzregeln auf die Inhalte des Filters der
Löschoperation stützen müssen. Da nicht bekannt ist, über welche Eigenschaften und Funktionen
der Nutzer die zu löschenden Features selektiert, können zu Knoten des Filters der
Löschanfrage keine sinnvollen inhaltsbezogenen Zugriffsregeln deklariert werden.
Eine Lösung dieses Problems stellt die Erweiterung des vom Nutzer spezifizierten Filters in
der Löschanfrage dar. Dieser Filter wird vom Zugriffskontrollsystem so erweitert, dass die
Löschoperation nur auf den löschbaren Datensätzen ausgeführt werden kann.
Dazu wird wie folgt vorgegangen:
In einer Obligation wird ein Filterprädikat (im Format der vom Web Service unterstützten
Filter – vgl. 3.3.1) definiert, das die für einen Nutzer löschbaren 32 Features eines bestimmten
Typs spezifiziert – ähnlich dem Definieren einer View in einem DBMS. Für die Deklaration
des Filters können beliebige Eigenschaften des Featuretyps genutzt werden, um die löschbaren
Features zu adressieren. Dadurch wird, wenn auch nur indirekt, Bezug auf die Inhalte der
zu schützenden Features genommen, weshalb in diesem Zusammenhang von inhaltsabhängiger
bzw. raumbezogener Zugriffskontrolle gesprochen werden kann. Sofern nun ein Nutzer
eine Löschanfrage zu Features dieses Typs absetzt, muss das Zugriffskontrollsystem dafür
sorgen, dass diese Obligation an den PEP übermittelt wird. Der PEP kann daraufhin das
in der Obligation enthaltene Filterprädikat per „and“ mit dem vom Nutzer spezifizierten
Filter der Original-Löschanfrage verknüpfen. Dadurch wird die Schnittmenge aus den löschbaren
und zu löschenden Features gebildet, so dass die modifizierte Löschaktion nur noch autorisierte
Löschungen zur Folge hat.
Ein Nachteil dieser Verfahrensweise ist, dass bei jeder Löschaktion die „View-
Erzeugungsvorschrift“, d.h die in den Obligations steckenden Filterausdrücke, vom Web
Service neu berechnet werden müssen. Dem gegenüber steht der Vorteil, dass zu jedem Nutzer,
in Abhängigkeit der Inhalte der Löschaktion, spezielle Views auf die löschbaren Daten
festgelegt werden können, die nur dann berechnet werden müssen, wenn der Nutzer eine entsprechende
Anfrage an den Web Service absetzt.
Es stellt sich bei dieser Vorgehensweise allerdings die Frage, ob es sinnvoll ist, Löschoperationen
vom Zugriffskontrollsystem nach dem „so viel wie geht“ Prinzip modifizieren zu lassen.
Da angenommen wird, dass Löschoperationen auf einem Geo Web Service atomar zu behan-
32 Es können auch Filter angegeben werden, welche die nicht löschbaren Features spezifizieren. Für eine
Verbesserung der Lesbarkeit wurde dieser Fall allerdings vernachlässigt.

106
deln sind – d.h. entweder die Löschaktion kann in ihrer Form vom WFS bearbeitet werden
oder sie wird komplett abgelehnt, wird eine unautorisierte Löschaktion komplett abgelehnt.
Dies hat zur Folge, dass Löschaktionen nur durch Typ- bzw. Element- und Attributregeln auf
Zugriffsrechte überprüft werden können. In diesem Fall sind daher keine sinnvollen inhaltsbezogenen
bzw. raumbezogenen Autorisationen deklarierbar. Relativiert werden muss diese
Annahme, dass Löschoperationen als atomar anzusehen sind, sofern die Semantik der Löschaktion
fest vorgegeben wird (z.B. zu löschende Features müssen durch Angabe der FeatureID
selektiert werden).
5.4.4 Die Leseoperation
Wie bereits in 3.3.1 herausgearbeitet wurde, kann der Pre-Processing Ansatz als Alternative
zum Post-Processing Ansatz für Zugriffskontrolle bei lesenden Aktionen auf einen Geo Web
Service verwendet werden. Es wird nun am Beispiel des WFS gezeigt, wie lesende Zugriffe
auf ihn mit Hilfe des Pre-Processing Ansatzes kontrolliert werden können. Betont sei an dieser
Stelle, dass die für Kapitel 4 und 5 (ohne 5.4) zwingende Annahme einer XML/GMLkodierten
Web Service Antwort nicht mehr nötig ist (zur Begründung vgl. 3.2.5 oder 3.3.1).
Dies bedeutet dass durch die nachfolgend beschriebene Verfahrensweise feingranulare
Zugriffskontrolle trotz unstrukturierter Web Service Antworten (z.B. ein Rasterbilddateiformat)
möglich ist. Bei diesem Ansatz findet im PDP keine explizite Überprüfung der Zugriffsgesetze
statt. Seine Aufgabe ist in diesem Fall das korrekte Umschreiben der Web Service
Anfrage zu ermöglichen, so dass diese nur mehr zugreifbare Daten liefert. Die eigentliche
Überprüfung der Zugriffsrechte geschieht implizit im WS der durch Auswertung der modifizierten
nun sicheren Anfrage die ausschlieslich zugreifbare Daten in der Web Service Antwort
impliziert.
Die vom Nutzer kommende GetFeature-Anfrage (s.u.) veranlasst, dass der PEP eine globale
Zugriffsentscheidungsanfrage absetzt. In dieser ist die lesende Anfrage an den WFS im ResourceContent
Element enthalten. Dadurch können in den Typ- bzw. Element- und Attributregeln
die vom Nutzer angefragten Featuretypen und dessen Eigenschaften auf Zugriffsrechte
überprüft werden (siehe Beispiel unten).
Zu berücksichtigen ist, dass einige Web Services automatisch verpflichtende Knoten in die
Antwort einbauen (z.B. mit „mandatory“ gekennzeichnete Elemente im Schema welches den
Antwortdokumenten des WFS zugrunde liegt). Dadurch enthält die Antwort auf einen Query
gegebenenfalls mehr Werte als die Angefragten. Daher muss der PEP, bevor er den Prozess
der Zugriffskontrolle einleitet, die Anfrage modifizieren, so dass aus dieser ersichtlich wird,
welche Werte letztendlich tatsächlich an den Nutzer zurückgegeben werden. Hierfür kann das
der Antwort zugrundeliegende XML-Schema genutzt werden.

107
Wie schon für die Löschoperation erörtert wurde, kann auch für Zugriffsregeln, die sich auf
lesende Aktionen beziehen, die Information im Filter der GetFeature-Anfrage nicht sinnvoll
zum Treffen einer Zugriffsentscheidung genutzt werden. Um dennoch inhaltsbezogene bzw.
raumbezogene Zugriffsregeln definieren zu können, muss die Zugriffskontrolle indirekt über
die Definition von Filterprädikaten –Teile von Filtern – in den Obligations, zugehörig zu
einer Regeln, erfolgen. Die dadurch modifizierbare Leseanfrage kann dann an den WFS weitergeleitet
werden und gibt dem Nutzer als Antwort die Schnittmenge aus angefragten und
zugreifbaren Daten. Die Filterprädikate in den Obligations definieren die für einen Nutzer
lesend zugreifbare 33 Datenmenge. Indem das Filterprädikat der Regel über die „and“
Funktion mit dem Filter der GetFeature-Anfrage verknüpft wird, kann erreicht werden, dass
die Leseanfrage nur auf der zugreifbaren Datenmenge ausgewertet wird. In diesem Fall erfolgen
daher in den Zugriffsregeln keine inhaltsbezogenen Überprüfungen, sondern es werden
nur die zu einer lesenden Web Service Anfrage passenden Obligations identifiziert, um
die Anfrage wie oben beschrieben modifizieren zu können.
Zur Identifikation der zu einer Anfrage passenden Filterprädikate werden Zugriffsregeln verwendet.
In den Regeln wird neben den Informationen zum Subjekt und zur Aktion auch der
angefragte Featuretyp bzw. dessen angefragte Eigenschaften überprüft. Das Target muss
daher den Typ- bzw. Element- und Attributregeln entsprechend definiert werden. Der Resource
Teil in der Regel sollte so definiert sein, dass die Regel bei individuellen Zugriffsentscheidungsanfragen
zu demjenigen Knoten greift, an dessen Stelle auch die durch ihr Greifen
übermittelte Obligation bzw. das Filterprädikat per „and“ angefügt werden soll (z.B.
Abgleich des resource-id Attributes mit einem regulären Ausdruck zum Filter Element
das Filterprädikat wird per „and“ an die Wurzel des Filters – das Filter Element –
der Leseanfrage des Nutzers angehängt). Das Greifen einer Regel hat zur Folge, dass der PDP
die zu den Regeln definierten Obligations 34 (diese enthalten die Filterprädikate) an den
PEP leitet. Letzterer nutzt die darin enthaltene Filterdeklaration, um den Filter der vom Nutzer
abgesetzten GetFeature-Anfrage geeignet zu erweitern (für Details zur Vorgehensweise
siehe 6.4.3).
Beispiel für Typregel im Preprocessing:
...
33 Der negierte Fall (d.h. die zugriffsbeschränkte Datenmenge) wird der Einfachheit halber vernachlässigt.
34 Dies wird erreicht indem in einer Policy genau eine Regel mit positiven Effekt existiert. Die Obligation
wird an den PEP übermittelt, sofern FulfillOn auf "Permit" gesetzt wird.

108
/Request/Resource/ResourceContent/wfs:GetFeature\[\d+\]/wfs:Query\[\d+\]/
ogc:Filter\[\d+\]$
BANKAUTOMAT
/../@typeName
FeatureType
Bankautomat
...
Weitere Beispielregeln für Zugriffskontrolle mit dem Pre-Processing Ansatz finden sich auf
der der Arbeit beiliegenden CD-ROM.

109
6 Prototypische Implementierung eines Zugriffskontrollsystems
für Geo Web Services
Um die Umsetzung der vorgestellten Erweiterungen des XACML Standards zur Realisierung
raumbezogener Zugriffskontrolle für einen Geo Web Service zu demonstrieren, wird in diesem
Kapitel die Erweiterung einer XACML API sowie die Implementierung eines Zugriffskontrollsystems
vorgestellt. Als Basis dient die von Sun entwickelte XACML API
(SUNXACML). Deren Aufbau sowie die Mechanismen und Schnittstellen zur Nutzung und
Erweiterung der SUNXACML Klassen werden unter 6.1 betrachtet. Unter 6.2 wird die Umsetzung
der geforderten Erweiterungen von XACML beschrieben. In 6.3 und 6.4 werden die
verwendeten Techniken zur Implementierung der wesentlichen Komponenten (PDP, PEP und
Context Handler) eines XACML-basierten Zugriffskontrollsystems für Geo Web Services
vorgestellt.
6.1 SUNXACML
Suns XACML Implementierung ist eine Menge an Java Klassen 35 , die XACML verstehen
und Mechanismen zur Verarbeitung von Attributen, Zugriffsentscheidungsanfragen und
Zugriffsregeln anbieten. Auf Basis von SUNXACML ist es mit relativ wenig Code möglich,
ein XACML-basiertes Zugriffskontrollsystem für Web Services zu realisieren. Im Folgenden
wird eine kurze Einführung zum Aufbau und zur Verwendung der XACML Implementierung
von SUN (Version 1.2) gegeben. Erwähnt werden nur die für die Erweiterung von
SUNXACML und die zur Umsetzung der wesentlichen Komponenten des Zuriffskontrollsystems
relevanten Packages der API. Die genaue Funktionalität der einzelnen Packages und
Klassen von SUNXACML kann in SUNXACML 1.2 und in den JavaDocs der SUNXACML
API nachgelesen werden.
Das Factory System
Im Package com.sun.xacml.attr werden neben den Standard XACML Attributtypen
und den XACML Mechanismen zum Selektieren von Attributen die so genannten Factories
definiert.
Ziel der Factories ist es, stabile und einheitliche Schnittstellen zur Nutzung und Erweiterung
der von SUNXACML unterstützten Attributtypen, Funktionen und Combining Algorithmen
anzubieten. Der Kerncode von SUNXACML nutzt die unveränderbaren default Standard
Factories.
35 Die Implementierung mit SUNXACML Version 1.2 benötig mindestens JDK 1.4.0 zum Erzeugen und Ausführen
des Codes.

110
Benötigt ein Programmierer weitergehende Funktionalitäten als die von den default Factories
angebotenen, so muss er für die entsprechende Factory eine neue Instanz anfordern.
Für diese sollte gewährleistet sein, dass sie die selben Funktionalitäten wie die Standard
Factory bietet. Auf Basis der neuen Factory Instanz kann der Programmierer dann seine
Änderungen bzw. Erweiterungen beliebig umsetzen. Dadurch wird erreicht, dass andere
Komponenten nicht von den Änderungen des Programmierers beeinträchtigt werden. Dies
vereinfacht den Austausch, das Erweitern sowie das Weglassen von Modulen in
SUNXACML.
Wie der Programmierer die Erweiterungen der Attributtypen und Funktionen, die ihm die entsprechende
Factory zur Verfügung stellt, mit SUNXACML umsetzen kann, ist durch die
unten abgebildeten Codebeispiele beschrieben. Es werden an dieser Stelle nur die Mechanismen
zum Erweitern der Factories vorgestellt. Ein Beispiel für den Einsatz der Mechanismen
findet sich im Abschnitt 6.2, in dem gezeigt wird, wie die für raumbezogene Zugriffskontrolle
benötigten Erweiterungen der Attributtypen und Funktionen von SUNXACML umgesetzt
werden. Detailliertere Informationen zum Factory System in SUNXACML finden
sich in SUNXACML 1.2.
Zur Erweiterung der Attributtypen über die StandardAttributeFactory muss folgendermaßen
vorgegangen werden:
StandardAttributeFactory standardFactory =
StandardAttributeFactory.getFactory();
final BaseAttributeFactory newFactory =
new BaseAttributeFactory(standardFactory.getStandardDatatypes());
...
// Ändern der Factory. Beispiel siehe 6.2.1
...
AttributeFactory.setDefaultFactory(new AttributeFactoryProxy() {
public AttributeFactory getFactory() {
return newFactory;
}
});
Das Ergänzen von Funktionen kann mit der FunctionFactory wie folgt erreicht werden:
FunctionFactoryProxy proxy = StandardFunctionFactory.getNewFactoryProxy();
...
// Modifizieren der Faktory über den Proxy
...
FunctionFactory.setDefaultFactory(proxy);
Neben dem Factory System bietet SUNXACML ein Finder Konzept zur Nutzung von Modulen,
die zur funktionalen Strukturierung der Komponenten dienen. Je nach Bedarf können
benötigte Module – vordefiniert oder auch selbstdefiniert – zu einer Einheit des Zugriffskontrollsystems
(z.B. zum PDP) zusammengefügt werden. Dafür müssen die Module zunächst instanziert
werden. Im Anschluss werden die entsprechenden Finder mit den instanzierten Mo-

111
dulen angelegt. Über diese Finder können die Einheiten des Zugriffskontrollsystems die
Funktionalität der Module dann nutzen (Details siehe 6.3).
6.2 Erweiterungen von SUNXACML
Dieser Abschnitt beschreibt, wie die SUNXACML API zu erweitern ist, um die zur Umsetzung
raumbezogener Zugriffskontrolle benötigten Attributtypen, Funktionen und Module zu
unterstützen. Für einen detaillierten Einblick in die Implementierung der Erweiterungen wird
auf die im Inneneinband der Arbeit befindliche CD-ROM (genauer: auf den src Verzeichnis
auf der CD-ROM) mit dem dokumentierten Quellcode des Prototypen verwiesen.
6.2.1 Der Spatial Attributtyp
Wie in 5.3.1 erörtert wurde, muss zur Realisierung raumbezogener Zugriffskontrolle mit
XACML, die Verwendung des spatial Attributtyps im Regelwerk sowie im XACML Request
Context unterstützt werden. Zur Erweiterung der von SUNXACML angebotenen Attributtypen
muss das unter 6.1 eingeführte Factory Konzept verwendet werden.
Alle Attributtypen sind Unterklassen der abstrakten Klasse AttributeValue. Daher muss
zur Implementierung des spatial Attributtyps eine neue Klasse angelegt werden, die
AttributValue erweitert. In dieser werden der Bezeichner des Attributtyps
(http://www.spatial-DatatypesForXACML#spatial), die Signatur des Konstruktors
sowie einige einfache Funktionen auf diesem neuen Attributtyp definiert. Der Attributtyp
ermöglicht das Speichern der GML-kodierten Repräsentation der Geometrien in einem
String sowie Funktionen zur Verarbeitung dieses GML Strings. Zum Aufbau und Inhalt dieser
Klasse sei auf die Datei SpatialAttribut.java im Verzeichnis src auf der CD-ROM (siehe Inneneinband
der Arbeit) verwiesen.
Nachdem der spatial Attributtyp durch die neue Klasse (SpatialAttribut) unterstützt
wird, kann er der AttributeFactory hinzugefügt werden. Hierfür ist der unter 6.1
vorgestellte Mechanismus zum Erweitern der Factories zu verwenden.
StandardAttributeFactory standardFactory =
StandardAttributeFactory.getFactory();
final BaseAttributeFactory newFactory = new BaseAttributeFactory
(standardFactory.getStandardDatatypes());
newFactory.addDatatype("http://www.spatialDatatypesForXACML#spatial",
new AttributeProxy() {

112
});
public AttributeValue getInstance(Node root) throws Exception {
// create a new SpatialAttribute
return SpatialAttribute.getInstance(root);
}
public AttributeValue getInstance(String value) throws Exception {
return new SpatialAttribute(value);
}
Der AttributeProxy wird immer dann aufgerufen, wenn die AttributeFactory gebeten
wird, einen neuen spatial Attributtyp zu initialisieren.
6.2.2 Topologische und räumliche Funktionen
Trotz des großen Angebotes an vordefinierten Funktionen in XACML muss, wie in 5.1 diskutiert
wurde, XACML bzw. SUNXACML um die genannten topologischen und räumlichen
Funktionen erweitert werden.
Alle SUNXACML Funktionen implementieren das Function Interface über die FunctionBase
Hilfsklasse. Diese sorgt dafür, dass eine von SUNXACML erwartete Basisfunktionalität
der neu definierten Funktionen vorhanden ist (mehr Infos siehe JavaDocs zu
SUNXACML).
Es soll an dieser Stelle der Aufbau der Klassen zur Umsetzung topologischer und räumlicher
Operationen (TopologicalRelations.java und SpatialOperations.java) nur kurz vorgestellt und
auf die wesentlichen Aspekte hingewiesen werden. Für Details wird die Lektüre des Quellcodes
beider Dateien empfohlen (siehe CD-ROM im Inneneinband).
Zunächst müssen die Bezeichner der neuen Funktionen festgelegt werden. Zudem muss für
jede Funktion die Anzahl und der Typ der Parameter (hier der spatial Attributtyp 36 ) sowie
der Rückgabetyp festgelegt werden. Des weiteren wird spezifiziert, was bei Anwendung der
neuen Funktionen geschehen soll. Im ersten Schritt werden die Werte der spatial Attribute,
welche die Argumente der neuen Funktionen darstellen, geparst (vgl. die selbstentwickelten
Klassen: TopologicalRelations.java und SpatialOperations.java sowie die geometrietyp-
Attribut.java). Dadurch wird überprüft, ob sie der erwarteten GML Syntax genügen. Außerdem
kann durch das Parsen bestimmt werden, welche Geometrie in dem spatial Attribut
gespeichert ist (vgl. getDatatype Methode ). Dies ist sinnvoll, da dadurch in gewissen Fällen
vor Instanzierung der Geometrieobjekte und vor Auswertung räumlicher Funktionen entschieden
werden kann, ob die Funktion auf die Geometrie(n) überhaupt definiert bzw. zu berechnen
ist (vgl. Tabellen in Anhang B oder TopologicalRelations.java bzw. SpatialOperations.java).
36 Würde je Geometrietyp ein eigener Daten- bzw. Attributtyp verwendet werden (vgl. 5.3.1), dann müssten für
jede topologische Operation alle möglichen Signaturen definiert werden.

113
Nachdem die spatial Attribut Argumente der räumlichen Funktionen geparst wurden,
werden sie in einer internen Darstellung (Array aus Strings) gespeichert. Die einzelnen Felder
enthalten Informationen zum Typ der Geometrie, zum Raumbezugssystem sowie die Koordinaten,
welche die Form der Geometrie beschreiben.
Im nächsten Schritt findet die tatsächliche Berechnung der topologischen und räumlichen O-
perationen statt. Diese wurde in eine gesonderte Klasse, die XACMLGeometryFactory
verlagert und stellt die Schnittstelle zur Java Topologie Suite (JTS) API dar. Mit Hilfe der
JTS API lassen sich geometrische Objekte einfach instanzieren und sämtliche benötigten topologischen
und räumlichen Operationen sind zudem direkt auf den mit JTS erzeugten Geometrieinstanzen
nutzbar (mehr hierzu in 6.3.3).
Der letzte Schritt zur Unterstützung der neuen Funktionen ist ihre Bekanntmachung in der
FunctionFactory. Die FunktionFactory ist in drei Gruppen unterteilt (vgl. Java-
Docs) und es muss vom Proxy eine der Gruppen angefordert werden. Da räumliche Funktionen
nur in Conditions der Regeln verwendbar sein sollen, wurden die neuen Funktionen
der ConditionFunktionFactory Gruppe zugeordnet.
FunctionFactoryProxy proxy =
StandardFunctionFactory.getNewFactoryProxy();
FunctionFactory factory = proxy.getConditionFactory();
//Die topologischen Relationen
Iterator iterator=
TopologicalRelations.getSupportedIdentifiers().iterator();
while (iterator.hasNext()){
factory.addFunction(new TopologicalRelations((String)(iterator.next())));
}
//Die spatial Operationen getLength, getArea und distance
iterator = SpatialOperations.getSupportedIdentifiers().iterator();
while (iterator.hasNext()){
factory.addFunction(new SpatialOperations((String)(iterator.next())));
}
FunctionFactory.setDefaultFactory(proxy);
Zusätzlich zu der expliziten Definition der räumlichen Funktionen muss SUNXACML um
Funktionen erweitert werden, die das Arbeiten mit dem neuen spatial Attributtyp ermöglichen.
Sofern es sich um eine Standard Bag oder eine Equal Funktion auf dem neuen Attributtyp
handelt, bietet SUNXACML einen besonderen Mechanismus um diese indirekt definieren
zu können, wodurch sie in den Regeln verwendbar werden. Hierzu müssen die Konstruktoren
der BagFunction und EqualFunction Klasse mit dem neuen Datentyp aufgerufen
werden.
FunctionFactory factory0 = FunctionFactory.getGeneralInstance();
factory0.addFunction(BagFunction.getOneAndOnlyInstance
("spatial-one-and-only", SpatialAttribute.identifier));

114
Durch obigen Codeausschnitt wird ermöglicht, dass die spatial-one-and-only Funktion
auf einem Bag aus Werten vom Typ spatial Attribut angewendet werden kann (z.B.
als Hülle des spatialInformationSelectors, um genau ein spatial Attribut zu
fordern).
Ähnlich den beschriebenen Erweiterungen ist es mit SUNXACML auch möglich, neue Combining
Algorithmen zu definieren. Da für das in dieser Arbeit betrachtete Beispielszenario die
vordefinierten Algorithmen ausreichend mächtig sind, wird der Mechanismus zur Erweiterung
von Combining Algorithmen nicht explizit vorgestellt. Für detailliertere Informationen
hierzu wird stattdessen auf SUNXACML 1.2 verwiesen.
6.2.3 Funktionen zum Auflösen der Referenzen in den Regeln auf Daten
im XACML Request Context
In der SUNXACML API 1.2 sind der AttributeDesignator und der AttributeSelector
bereits implementiert. Wie in 4.2.4 erörtert wurde, ist allerdings eine neue Art der
Referenzierung von Attributen im Request Context möglich und nötig. Zur Umsetzungen der
datentypInformationSelectoren musste SUNXACML um selbstdefinierte Funktionen
erweitert werden, die es ermöglichen, Daten im ResourceContent der Zugriffsentscheidungsanfragen
zu selektieren und als Parameter für die Funktionen der Regeln bereitzustellen.
Wie der AttributeDesignator und der AttributeSelector liefert auch
der datentypInformationSelector einen Bag mit Attributen vom Typ datentyp
zurück. Zum Selektieren der Werte unterhalb des ResourceContent Elementes wird der
sich durch Konkatenation der Parameter ergebende XPath-Ausdruck ausgewertet. Der angesprochene
Knoten wird daraufhin samt aller Nachkommen zunächst als String kodiert selektiert.
Im Anschluss wird dieser String zur Initialisierung der Attribute vom Typ datentyp
verwendet. Sofern der XPath-Ausdruck mehrere Knoten selektiert, wird je Knoten ein eigenes
Attribut angelegt. Unabhängig von der Zahl der erzeugten Attribute wird zuletzt ein Bag
Attribut instanziert, dessen Inhalt die vom datentyp-InformationSelector erzeugten
datentyp Attribute sind.
Zur Auswertung der XPath-Ausdrücke wurde die XALAN API (Version 2.6) von Apache
verwendet da diese auch von SUNXACML für die Verarbeitung von XML-kodierten Daten
verwendet wird (z.B. im SelectorModule welches die Funktionalität des AttributeSelector
umsetzt).
Abschließend sei erwähnt, dass datentypInformationSelectoren versuchen, Namespaces
in XPATH-Ausdrücken durch die Namespace Definitionen in der Wurzel des Regelwerkes
zu substituieren.

115
6.2.4 Das Resource Finder Modul zur Unterstützung hierarchischer Resourcen
In SUNXACML ist es möglich der Implementierung eines Zugriffskontrollsystems neue Module
hinzuzufügen. Es existieren drei Typen von Finder Modulen:
• Attribut Finder Module:
Dieses Modul dient zum Auffinden von Attributwerten. Es wird vom AttributeDesignator
und AttributeSelector aufgerufen.
• Policy Finder Module:
Dieses Modul dient zum Auffinden der Policies und PolicySets zu einer Zugriffsentscheidungsanfrage
und zum Auffinden verteilt gehaltener Policies, die in einem
PolicySet referenziert worden sind.
• Resource Finder Module:
Dieses Modul dient zur Unterstützung hierarchischer Ressourcen. Falls die zu schützende
Ressource ein hierarchisches Objekt aus einzelnen Ressourcen ist (z.B. ein XML Dokument),
kann durch dieses Modul eine Liste der Identifikatoren der individuellen Ressourcen
(z.B. XPath-Ausdrücke zu allen Knoten des XML Dokumentes) erstellt werden. Da
dieses Modul in der SUNXACML API nicht implementiert ist, musste es für den Prototypen
neu entwickelt werden.
Es wird nun kurz gezeigt, wie das Resource Finder Module mit SUNXACML für den Prototypen
implementiert worden ist. Dies entspricht der Erweiterung des Context Handlers, so
dass dieser die Umwandlung der globalen Zugriffsentscheidungsanfrage in individuelle
Zugriffsentscheidungsanfragen ermöglichen kann. Da im vorgestellten Prototyp eine
Zugriffskontrolle nach dem „so viel wie geht“ Prinzip unterstützt werden soll, müssen die
Antworten auf die individuellen Zugriffsentscheidungsanfragen einzeln an den PEP weitergeleitet
werden (vgl. 4.2.2). Angemerkt sei an dieser Stelle, dass, sofern ein konkretes Anwendungsszenario
eine Zugriffskontrolle nach dem „alles oder nichts“ Prinzip wünscht, der Context
Handler zusätzlich um ein zweites Modul erweitert werden muss, so dass er in Abhängigkeit
der individuellen Zugriffsentscheidungsantworten nur eine Antwort an den PEP zurückgibt.
Ob der Context Handler dieses zweite Modul zu verwenden hat, wird durch den
scope Attribut Wertes entire hierarchie im globalen Request Context gekennzeichnet.
Wie bereits unter 4.2.4 erörtert wurde, ist es zur Effizienzsteigerung sinnvoll, dass der Context
Handler, wenn die Zugriffsentscheidung zu einer individuellen Ressource „zugriffsbeschränk“
lautete, das Absetzen der individuellen Zugriffsentscheidungsanfragen für die
Nachkommen zu diesem Knoten abbricht (Begründung vgl. 4.2.4).
Im umgesetzten Prototyp ist diese Performanceverbesserung allerdings bislang noch nicht
realisiert, da in SUNXACML 1.2 dieses Verhalten nur mit weitreichenden Änderungen im
Kern der Implementierung zu erreichen ist. Da allerdings die Nachfolgerversion zur XACML

116
2.0 Version die erwähnte Optimierung unterstützen soll (MailAnderson b) wurde diese in der
Implementierung des Prototyps vernachlässigt.
Zunächst muss im scope Attribut festgelegt werden, wann das Resource Finder Module
verwendet werden soll. Wie in 4.2.2 erklärt wurde, drückt ein scope Wert von descendants
im globalen XACML Request Context aus, dass sich die Zugriffsentscheidungsanfrage
auf eine hierarchische Ressource bezieht, deren Wurzel durch das resource-id Attribut
spezifiziert wurde. Dies bedeutet, dass das Resource Finder Module immer dann angesprungen
werden muss, wenn der Wert des scope Attributes der globalen Zugriffsentscheidungsanfrage
gleich descendants ist. Die Aufgabe des Modules ist dann in Abhängigkeit des
resource-id Wertes alle individuellen Ressourcen zu identifizieren. Da die hierarchische
Ressource im Anwendungsfall der Arbeit ein XML Dokument ist, hat der Resource Finder die
Aufgabe, zum resource-id Wert – dieser zeigt auf die Wurzel des XML Dokumentes, da
für alle Knoten die Zugriffsregeln überprüft werden sollen – alle darunter liegenden Elementund
Attributknoten zu finden und einen eindeutigen Identifikator je Knoten zu erzeugen.
Hierfür wird das XML Dokument, das unterhalb des ResourceContent Elementes liegt
durch eine rekursiv arbeitende Funktion durchlaufen, die zu jedem Knoten den ihn adressierenden
XPath-Ausdruck zurückliefert. Für die genaue Arbeitsweise dieser Rekursion wird auf
den Quellcode in MyResourceFinderModule.java verwiesen.
Rückgabewert des Moduls ist ein ResourceFinderResult Objekt, das mit der Menge an XPath-
Ausdrücken konstruiert wurde. Dieses Objekt stellt die Basis zur Erzeugung der individuellen
Zugriffsentscheidunganfragen dar. Für jeden in ihm gespeicherten XPath-Ausdruck wird eine
individuelle Zugriffsentscheidungsanfrage an den PDP abgesetzt. Der Aufbau dieser individuellen
Zugriffsentscheidungsanfragen entspricht mit Ausnahme des Wertes des resource-id
Attributes dem der globalen Zugriffsentscheidungsanfrage. Dieses Attribut wird mit
einem der XPath-Ausdrücke belegt. Durch diese Vorgehensweise wird gewährleistet, dass
sich jede individuelle Zugriffsentscheidungsanfrage auf genau einen Knoten des XML Dokumentes
bezieht und jede individuelle Ressource einzeln auf Zugriffsrechte überprüft wird.
Zuletzt muss das neu definierte Resource Finder Module im PDP eingebunden werden. Wie
dies umgesetzt wurde, wird in Abschnitt 6.3.1 demonstriert.

117
6.3 Der PDP
6.3.1 Implementierung des PDP
Zur Implementierung eines PDPs mit SUNXACML müssen die benötigten Module zusammengefügt
werden. Dazu wird das von SUNXACML angebotene Finder Konzept (vgl. 6.1)
verwendet. Es muss eine Menge von Finder Modules instanziert werden, die das Zusammenfügen
der benötigten Module ermöglichen. Die für den hier vorgestellten Prototypen benötigten
Module sind das
• File Policy Module, das den Zugriff auf das Regelwerk, gespeichert als XML Dateien,
ermöglicht.
• CurrentEnv Module, das Werte wie die aktuelle Uhrzeit, das Datum etc. bereitstellt.
• Selector Module zur Unterstützung von AttributeSelectoren.
• Resource Finder Module, das für die Umwandlung der globalen Zugriffsentscheidungsanfrage
in die individuellen Zugriffsentscheidungsanfragen zuständig ist.
Bevor diese Module über die Finder Modules im PDP verfügbar gemacht werden können,
müssen sie zunächst wie folgt instanziert werden:
FilePolicyModule policyModule = new FilePolicyModule();
policyModule.addPolicy("/path/to/policy.xml");
CurrentEnvModule envModule = new CurrentEnvModule();
SelectorModule selectorAttributeModule = new SelectorModule();
MyResourceFinderModule resourceFinderModule = new MyResourceFinderModule();
Nach der Instanzierung der Module können die Finder, die diese Module für den PDP nutzbar
machen, initialisiert werden:
PolicyFinder policyFinder = new PolicyFinder();
Set policyModules = new HashSet();
policyModules.add(policyModule);
policyFinder.setModules(policyModules);
AttributeFinder attrFinder = new AttributeFinder();
List attrModules = new ArrayList();
attrModules.add(envModule);
attrModules.add(selectorAttributeModule);
attrFinder.setModules(attrModules);
ResourceFinder resourceFinder = new ResourceFinder();
List resourceModules = new ArrayList();
resourceModules.add(resourceFinderModule);
resourceFinder.setModules(resourceModules);

118
Nun kann der PDP über die PDPConfig Klasse mit den Findern als Argumente erzeugt und
dadurch gleichzeitig konfiguriert werden:
PDP pdp = new PDP(new PDPConfig(attrFinder, policyFinder, resourceFinder));
Die so gewonnene PDP Instanz stellt den voll funktionsfähigen PDP dar. Man kann Anfragen
von ihm auswerten lassen, indem seine evaluate Funktion mit einem RequestCtx Objekt
(entspricht dem globalen XACML Request Context) als Argument aufgerufen wird.
RequestCtx request =
new RequestCtx(subjects, resourceAttrs, actionAttrs, environmentAttrs);
ResponseCtx response = pdp.evaluate(request);
Das Ergebnis der Auswertung des PDPs ist eine ResponseCtx Instanz, die einem gültigen
XACML Response Context entspricht. In diesem ist eine Menge an Antworten (eine je Knoten
der vom WFS generierten Antwort) des PDPs enthalten.
In Kapitel 6.4 wird beschrieben, wie der PEP und Context Handler die RequestCtx Objekte
erzeugen. Dort wird ebenfalls die Interpretation der ResponseCtx Instanz durch den PEP
diskutiert.
6.3.2 Instanzieren der georeferenzierten geometrischen Objekte
Für die Instanzierung der Geometrien und zur Berechnung der räumlichen Funktionen wurde
die JTS API verwendet. JTS verwendet zum Abbilden zweidimensionaler, georeferenzierter
Geometrien ein Datenmodell, das auf dem Modell der OpenGIS Simple Features Specification
For SQL Revision 1.1 (OGC SFS 1.1) basiert. Für Polygone wurde festgelegt, dass die inneren
Ränder eines Polygons den äußeren Rand maximal in einem Punkt berühren dürfen.
Zudem wurden sich wiederholende Punkte und selbstschneidende Linienzüge erlaubt.
Eine Möglichkeit zur Erzeugung geschlossener geometrischer Objekte in JTS bietet der so
genannte WKTReader (Well-Known Text Reader). Dieser liest eine Textfolge ein, die einer
bestimmten Syntax genügen muss (vgl. OGC SFS 1.1, S. 53 und 54 bzw. 3-11 und 3-12) und
instanziert mit deren Hilfe ein Geometry Objekt.
Beispiel:
Geometry g = new WKTReader().read(„LINESTRING (0 0, 10 10, 20 20)“);
Wie man sieht, weist der WKT String eine nicht GML-konforme Syntax auf (für die korrekte
GML Syntax vgl. 2.2). Es ist daher nötig, die GML-kodierten Geometrien bzw. deren interne

119
Darstellung (Array aus Strings – vgl. 6.2.2) in die WKT Syntax zu transformieren (siehe
Klasse XacmlGeometryFactory), bevor die Geometrie nach obigen Schema instanziert
werden kann.
JTS bietet die Möglichkeit, zu jeder erzeugten Geometrie eine Menge an Metadaten festzulegen
(z.B. das sich auf die Koordinaten der Geometrie beziehende Raumbezugssystem). Metadaten
werden in dem zum Objekt gehörigen „userData“ Feld gehalten. Diese Daten werden
allerdings von den JTS Funktionen bei deren Anwendung nicht berücksichtigt. Daraus folgt,
dass es Aufgabe der Anwendung ist, nötige Koordinatensystemüberprüfungen und gegebenenfalls
-transformationen durchzuführen (siehe 4.3.6).
Sobald die Geometrien instanziert sind und die Koordinaten sich auf das selbe SRS beziehen,
können die topologischen Relationen oder die räumlichen Operationen (length, area etc.) auf
ihnen angewendet werden.
6.3.3 Auswertung der raumbezogenen Funktionen
Auf den mit JTS erzeugten Geometrien lassen sich die gängigen Algorithmen zur Verarbeitung
von Geodaten einfach und effizient umsetzen. Wie bei allen numerischen Berechnungen
treten auch bei den geometrischen Algorithmen Rundungsfehler aufgrund der begrenzten Genauigkeit
der Zahlen in Computern auf. Robuste Algorithmen (d.h. keine Ungenauigkeiten
aufgrund von Rundungen) sind in der Regel komplexer und weniger performant. Daher sind
in JTS nur die fundamentalen geometrischen Algorithmen, wie z.B. die Bestimmung der
Schnittmenge, durch robuste Algorithmen umgesetzt. Die Berechnung der Relationen zwischen
zwei Geometrien beruht auf dem DE-9IM Modell (vgl. 5.2).
Wie folgender Codeausschnitt der XacmlGeometryFactory Klasse zeigt, lassen sich die
in JTS implementierten Funktionen sehr einfach zur Auswertung der in den Raumregeln spezifizierten
räumlichen Analysen nutzen.
...
Geometry g1 = wktReader.read(geom_1_JtsFormat);
Geometry g2 = wktReader.read(geom_2_JtsFormat);
if (relation.equals("within")){
result = g1.within(g2);
}else if (relation.equals("touches")){
result = g1.touches(g2);
...

120
6.3.4 Koordinatensystemüberprüfung und Transformation der Koordinaten
Wenn das Raumbezugsystem der Geodaten, die vom Geo Web Service angefordert wurden,
von dem Raumbezugssystem abweicht, das für die Geometrien in den raumbezogenen
Zugriffsregeln verwendet wurde, muss die Zugriffskontrolle diesen Fall entsprechend den
nachfolgenden Ausführungen behandeln.
Die einfachste Lösung wäre zu fordern, dass Raum- oder RaumInstanzregeln und abfragbare
Features im selben SRS festgelegt wurden. Die Überprüfung der Äquivalenz der Raumbezugssysteme
könnte durch eine extra Regel festgelegt werden, die in jeder Policy, in der
Raumregeln auftauchen, existieren muss. Die Regel muss das srsName Attribut der Objektinstanz
mit dem srsName Attribut der Regelgeometrie auf Gleichheit überprüfen. Sind die
Raumbezugssysteme verschieden, so sollte das Zugriffskontrollsystem eine Fehlermeldung
zurückgeben.
Eine fortgeschrittenere Verfahrensweise bei unterschiedlichen Raumbezugssystemen ist dagegen
eine automatisierte Durchführung von SRS Transformationen durch das Zugriffskontrollsystem.
Hierzu ist es notwendig, zu jeder zu erzeugenden Geometrie das entsprechende
Koordinatensystem (SRSID) im „userData“ Feld der JTS Geometry zu speichern. Sollte bei
der Überprüfung einer topologischen Relation die SRSID verschieden sein, so muss eine
Transfomationseinheit beauftragt werden, die Koordinaten der beiden Geometrien so umzuformen,
dass sie sich auf das selbe SRS beziehen und somit direkt vergleichbar sind. Auf dem
Markt existieren einige kostenpflichtige APIs und Frameworks (z.B. CoordTrans oder
Transdata), mit denen die Transformationseinheit einfach umgesetzt werden kann. Aus finanziellen
Gründen wurde allerdings im Prototyp keines der kommerziell verfügbaren Produkte
integriert. Stattdessen wird im Regelwerk des Beispielszenarios (vgl. Regelbeispiel
srsCheck.xml im Verzeichnis policy auf der CD-ROM) die erstgenannte Lösung zur Behandlung
der SRS Problematik verfolgt.
Eine weitere Alternative wäre, im Zugriffskontrollsystem mehrere Kopien des Regelwerkes
zu halten. Diese sind untereinander identisch mit der Ausnahme, dass die Koordinaten der
Regelgebiete in andere Koordinatensysteme umgerechnet wurden. Dadurch ist es möglich
Koordinatensystemtransformationen während des Prozesses der Zugriffskontrolle zu vermeiden.
Diese Vorgehensweise ist allerdings sofern das Regelwerk per Hand editiert wird eher
umständlich. Dieser Ansatz wird daher nur als sinnvoll erachtet, sofern ein PAP im Zugriffskontrollsystem
vorhanden ist oder aus Performance gründen dieser Weg verfolgt werden soll.
Da dieser im Prototypen nicht existiert und Performanceoptimierungen in dieser wissenschaftlichen
Arbeit keine Rolle spielen, wurde diese Variante nicht weiter verfolgt.

121
6.4 Der PEP
Die Aufgabe des PEPs ist es, Zugriffsentscheidungsanfragen an den PDP zu generieren sowie
die darauf resultierenden Antworten zu interpretieren. Er hat daher eine Schnittstelle zur Anwendungsumgebung
(zum Geo Web Service oder zum Nutzer). Es wird von einer Kommunikation
gemäß der WFS Spezifikation ausgegangen, da der entwickelte Prototyp exemplarisch
für einen WFS entworfen wurde. Die Ausführungen sind allerdings durch kleine Anpassungen
auf beliebige Anwendungsfälle übertragbar. Basis für die Implementierung des PEPs ist
das Package com.sun.xacml.ctx.
6.4.1 Generierung der globalen Zugriffsentscheidungsanfrage
Zunächst muss der PEP eine RequestCtx Instanz erzeugen, die den globalen XACML Request
Context darstellt. Dazu wird der Konstruktor der RequestCtx Klasse mit den vier
Argumenten Subject, Resource, Action und Environment aufgerufen (Details siehe
PEP.java im Verzeichnis src). Diese Objekte stellen Mengen von Attributen zum Subjekt, zur
Ressource (z.B. zur Web Service Anfrage oder Antwort), zur Aktion und zum Environment
dar, welche die dem PEP bekannten Informationen zu einer Nutzerinteraktion auf einen
Dienst repräsentieren.
RequestCtx request =
new RequestCtx(subjects, resourceAttrs, actionAttrs, environmentAttrs);
Kurz erwähnt werden sollte, dass im Resource Objekt das zu schützende XML Dokument
(die Web Service Anfrage oder Antwort) enthalten ist. Um zu gewährleisten, dass dieses ein
gültiges XML Dokument darstellt, kann im PEP eine Validierung erfolgen. SUNXACML bietet
dafür eine Schnittstelle zur Xerces API (Version 2.6.2). Da davon ausgegangen wird, dass
der Web Service immer gültige Antworten erzeugt, wird im Prototypen beim Einsatz der
Post-Processing Variante keine Validierung umgesetzt, wodurch sich die Performance der
Zugriffskontrolle verbessert. Sofern allerdings der Pre-Processing Modus im Zugriffskontrollsystem
eingestellt wird (Setzen der boolschen Variable doPreProcessing auf true), erfolgt
Validierung, da ungewiss ist, ob die vom Nutzer kommenden Anfragen gültig sind. Nur
wenn das System von einer gültigen Web Service Anfrage ausgehen kann, ist gewährleistet,
dass das Regelwerk, welches in Abhängigkeit des Schemas der Anfrage generiert wurde, den
gewünschten Zugriffsschutz umsetzt. Aus diesem Grund werden nicht-valide Web Service
Anfragen vom Zugriffskontrollsystem direkt abgewiesen.
Eine nach obigem Schema erzeugte RequestCtx Instanz stellt einen gültigen globalen
XACML Request Context dar. Allerdings müssen auf der Zugriffsentscheidungsanfrage noch

122
zwei Zwischenschritte zur Unterstützung des deutschen Zeichensatzes und zur Deklarationen
von Namensraumknoten ausgeführt werden, bevor diese zur Weiterverarbeitung an den Context
Handler übergeben werden kann. SUNXACML bietet nicht die Möglichkeit, beim Erzeugen
eines XACML Request Contextes den verwendeten Zeichensatz anzugeben. Ohne einen
Zwischenschritt würden demnach Inhalte in der Zugriffsentscheidungsanfrage, die nicht
UTF8 (SUNXACMLs default Zeichensatz für XML Daten) entsprechen (z.B. ß,ä,ö,ü), vom
Parser im Context Handler bzw. PDP als ungültiger Input abgewiesen werden. Das Problem
wird im Prototyp gelöst, indem eine zweite Möglichkeit zum Erzeugen einer Zugriffsentscheidungsanfrage
genutzt wird. Die Klasse RequestCtx bietet die Methoden encode()
und getInstance(InputStream in). Über die encode Funktion kann ein XACML
Request Context XML-kodiert als OutputStream ausgegeben werden. Die Methode getInstance
erzeugt basierend auf einem InputStream (XML-kodierter XACML Request
Context) eine RequestCtx Instanz. Der unten abgebildete Codeausschnitt zeigt, wie
über diese Methoden beliebige Zeichensätze in Zugriffsentscheidungsanfragen und -
antworten unterstützt werden können.
ByteArrayOutputStream out = new ByteArrayOutputStream();
String header = "";
out.write(header.getBytes());
//Durch obige Zeile wird der Header an den RequestContext(zu diesem Zeitpunkt
als OutputStream repräsentiert) angehängt
request.encode(out);
request = RequestCtx.getInstance((InputStream)new ByteArrayInput-
Stream(out.toByteArray()));
Ein weiterer Zwischenschritt (vgl. nachfolgender Codeausschnitt) wird benötigt, da in
SUNXACML kein standardisierter Weg angeboten wird, um im Wurzelknoten des XACML
Requests Namespace Attribute zu setzen.
Node root = request.getDocumentRoot();
((Element)root).setAttribute("xmlns","urn:oasis:names:tc:xacml:1.0:context"
((Element)root).setAttribute("xmlns:gml","http://www.opengis.net/gml");
Nachdem die beiden Zwischenschritte auf dem globalen XACML Request durchgeführt wurden,
kann er zur Auswertung über den Context Handler an den PDP übergeben werden. Dies
geschieht durch folgenden Ausdruck:
ResponseCtx response = pdp.evaluate(request);
Durch diese Implementierung wird die Übergabe des Request Contexts vom PEP über den
Context Handler an den PDP sowie das Senden der Request Response vom PDP über den
Context Handler an den PEP im selben Code und dadurch innerhalb eines lokal ablaufenden
Programmes realisiert.
Um diese Kommunikation über ein Netzwerk ablaufen zu lassen, müssen in den verteilt laufenden
Programmen (der PEP und der PDP) Socket Schnittstellen eingesetzt werden. Zusätz-

123
lich können die über das Netz ausgetauschten Informationen mit Technologien wie SAML
verpackt werden. Allerdings wird in der XACML Spezifikation bisher noch nicht festlegt wie
die Kommunikation zwischen einem online PDP und online PEP abzulaufen hat. Es ist von
Seiten OASIS geplant diese Spezifikationslücke in den zukünftigen Versionen der Spezifikation
zu schließen.
6.4.2 Modifikation der Web Service Antwort beim Post-Processing
Da im Prototypen Zugriffskontrolle nach dem „so viel wie geht“ Prinzip umgesetzt ist, erhält
der PEP von Contex Handler für jeden Knoten des angefragten XML Dokumentes eine eigene
individuelle Zugriffsentscheidungsantwort. Von Bedeutung sind die Antworten, deren
Zugriffsentscheidung deny, indeterminate oder not applicable entsprechen. Zunächst muss
entschieden werden, wie der PEP die Fälle not applicable und indeterminate behandeln soll.
Eine Möglichkeit ist, ein not applicable als permit zu werten. Dies entspricht der Logik, dass,
falls im Regelwerk keine Zugriffsregel für einen bestimmten Knoten des XML Dokumentes
existiert, angenommen wird, dass dieser zugreifbar ist. Demnach kann, sofern der SSO einen
kleinen Fehler bei der Definition des Regelwerkes gemacht hat, der Zugriff auf gewisse Knoten
fälschlicher Weise gewährt werden (z.B. wenn eine negative Regel aufgrund des Fehlers
nicht zur Anwendung kommt).
Weniger brisant erscheint in diesem Zusammenhang das Fehlen anwendbarer Regeln (eine
Zugriffsentscheidung zu einer individuellen Zugriffsentscheidungsanfrage von not applicable)
einem deny gleich zu setzen. Zwar tritt auch in diesem Fall bei einem Fehler im Regelwerk
ein unerwünschtes Verhalten auf, aber diesmal werden höchstens eigentlich zugreifbare Knoten
fälschlicher Weise als zugriffsbeschränkt angesehen. Da die zweite Variante im Fall von
Definitionsfehlern im Regelwerk eine aus Datensicherheitsaspekten sichere Verfahrensweise
darstellt, wird diese als default Einstellung im Prototyp angeboten. Wünscht man allerdings
ein Verhalten des Zugriffskontrollsystems entsprechend der ersten Variante, so kann dies
durch Konfiguration des PEPs (Belegen der boolschen Variable werteNotApplicableAlsDeny
mit false) erreicht werden.
Im Falle einer indeterminate Zugriffsentscheidung wurde für den Prototypen festgelegt, dass
der PEP dies wie ein deny wertet.
Sofern der PEP eine individuelle Zugriffsentscheidungsantwort von deny (direkt oder indirekt
durch Interpretation von indeterminate oder not applicable) erhält, muss er den entsprechenden
Knoten aus dem angeforderten XML Dokument herausfiltern. Zur Identifikation des Knotens
kann das resource-id Attribut, das in der XACML Response enthalten ist, verwendet
werden.

124
Zur Modifikation des XML Dokumentes wird XSLT eingesetzt. In der Implementierung wurde
zur Unterstützung der XSL Transformationen die Xalan API (Version 2.6.0) sowie die
Xerxes API (Version 2.6.2) genutzt. Das unten abgedruckte Stylesheet Dokument entspricht
dem Skelett der XSL Datei, die zur Transformation der XML Dokumente verwendet wird.
Durch das Skelett wird eine identische Kopie des XML Dokumentes erzeugt. Sofern dem PEP
aber nach dem Prozess der Zugriffskontrolle direkte oder indirekte 37 deny Zugriffsentscheidungen
zu Knoten des XML Dokumentes vorliegen, muss dieser das Skelett der XSL Stylesheet
Datei um einfache Template Regeln erweitern:
...
Diese überschreiben die vordefinierten Template Regeln, die für eine identische Kopie des
XML Dokumentes sorgen. Damit eine Template Regel zur Anwendung kommt und dadurch
der gewünschte überschreibende Effekt eintritt, muss das Template für den zugriffsbeschränkten
Knoten greifen. Zu diesem Zweck ist es nötig, dass der PEP die XPath-Ausdrücke, die im
resource-id Attribut der individuellen XACML Responses gespeichert sind, in die
Template Regeln integriert. Da das nach diesem Schema definierte Template keine weitere
Funktionalität hat (es handelt sich um ein so genanntes leeres Template, vgl. O’Reilly 2002,
Abschnitt 8.4), wird umgesetzt, dass der Knoten, für den das Template greift, nicht im Ergeb-
37 Ergeben sich durch entsprechende Wertung von not applicable und/oder indeterminate

125
nisdokument erscheint. Durch diese Vorgehensweise können alle zugriffsbeschränkten Knoten
aus dem XML Dokument herausgefiltert werden.
Zum Verständnis des Skeletts sei noch ergänzt, dass durch die strip-space und preserve-space
Elemente eine Eliminierung unnötiger Leerzeilen und –zeichen, die wegen
herausgefilterter Knoten im XML Dokument entstehen können, erreicht wird.
Die auf diese Weise zur Laufzeit erzeugte XSL Datei wird dann vom XSLT Prozessor auf der
Web Service Antwort ausgeführt. Ergebnis ist ein neues XML Dokument – die modifizierte
Web Service Antwort, aus der alle zugriffsgeschützten Knoten herausgefiltert wurden. Dieses
Dokument kann nun an den Nutzer zurückgegeben werden. Sofern Knoten herausgefiltert
wurden, muss dem Nutzer mitgeteilt werden, dass seine ursprüngliche Anfrage an den Web
Service aufgrund mangelnder Zugriffsrechte modifiziert wurde und er nur die für ihn zugreifbaren
Daten aus der Menge der angefragten Daten übermittelt bekommen hat. Dies geschieht
im Prototypen durch einen Kommentar am Anfang der modifizierten Web Service Antwort.
6.4.3 Erweiterung der Web Service Anfrage beim Pre-Processing
Wie man den Ausführungen aus Abschnitt 5.4 entnehmen kann, wird eine Modifikation der
Anfrage an den Web Service nur bei lesenden Aktionen als sinnvoll erachtet. Im Folgenden
wird daher kurz darauf eingegangen, wie der PEP anhand einer Menge an Obligations –
diese bekommt er, wenn eine Zugriffsregel angewendet werden konnte – die Web Service
Anfrage erweitert (Details siehe PEP.java). In einer Obligation ist ein Fiterprädikat enthalten,
welches die zugreifbare Datenmenge beschreibt und per and mit dem Filter der Web
Service Anfrage verknüpft werden soll.
Zur Modifikation der Web Service Anfrage muss der PEP eine XSL Datei erzeugen. In dieser
wird zunächst eine identische Kopie der Anfrage erreicht. Zusätzlich wird an der durch das
resource-id Attribut der individuellen XACML Response gekennzeichneten Stelle der
Filter der Web Service Anfrage um die Filterprädikate der entsprechenden Zugriffsregel bzw.
Obligation über die and Funktion erweitert. Unten abgebildete XSL Datei ist ein Beispiel
für eine vom PEP generierte XSL Datei, die zur Modifikation der Leseanfrage nach dem
gerade beschrieben Schema verwendet werden kann.
Beispiel einer XSL Datei beim Pre-Processing zum modifizieren der Web Service Anfrage:

126
Geometrie
50,40 100,60
6.5 Validierung der Implementierung
Das für diese Arbeit entwickelte Zugriffskontrollsystem für den WFS stellt einen Prototypen
dar, der zeigt, wie raumbezogene Zugriffskontrolle für Geo Web Services umgesetzt werden
kann. Zur Validierung der vorgestellten Implementierung finden sich im Anhang A.3 bzw.
auf der CD-ROM zahlreiche Testfälle. Durch sie wird die korrekte Funktionalität der
SUNXACML Erweiterungen überprüft und belegt.

127
7 Zusammenfassung, Evaluierung und Ausblick
In diesem letzten Kapitel werden die Ergebnisse der Diplomarbeit zunächst noch einmal zusammengefasst
(7.1). Anschließend werden diese im Ausblick (7.2) kurz kritisch bewertet
und darüber hinaus wird auf fortführende Arbeitsgebiete eingegangen, in denen noch Forschungsbedarf
besteht.
7.1 Zusammenfassung der Arbeit
In dieser Arbeit wurden zunächst gängige Konzepte zum Schutz von Daten vor unautorisierten
Zugriffen vorgestellt. Von diesen Ansätzen ausgehend wurde ein Modell für Zugriffskontrolle
bei Geo Web Services entworfen, das den Anforderungen dieses Anwendungsbereiches
genügt. Im Fokus stand daher die Umsetzung regelbasierter raumbezogener Zugriffskontrolle.
Es wurde davon ausgegangen, dass Geo Web Services XML- bzw. GML-kodierte Anfragebzw.
Antwortformate unterstützen und die dem Dienst zugrundeliegenden Geodaten objektartig
strukturiert sind.
Beim Entwurf der Architektur des Zugriffskontrollsystems wurde versucht, soweit möglich
die Richtlinien des XACML Standards zu verfolgen. Die zur Umsetzung von raumbezogenen
Zugriffsregeln benötigten Erweiterungen der eXtensible Access Control Markup Language
wurden ausführlich erläutert und deren Verwendung wurde an zahlreichen Beispielen demonstriert.
Anschließend wurde die prototypische Implementierung des beschriebenen Zugriffskontrollmodells
vorgestellt. Dabei wurde als Basis die XACML Implementierung der Firma SUN
verwendet. Eine Version des Programms befindet sich zusammen mit den Testdaten und den
Zugriffsregeln, die das Programm validieren, auf der CD-ROM im Inneneinband der Arbeit.
Das Zugriffskontrollsystem erfüllt die in der Aufgabenstellung geforderten Ziele: Es können
Zugriffsrechte an Featuretypen, an Featureinstanzen und an den Raumbezug der Features gebunden
werden. Dadurch ist es möglich, mächtige Regelwerke für Geo Web Services zu definieren,
wodurch flexibler Zugriffsschutz für Geodaten umgesetzt werden kann.

128
7.2 Evaluierung und Ausblick
Neben dem Zeitaufwand, sich durch die Fülle englischsprachiger Literatur zu lesen, kam erschwerend
hinzu, dass aus den Artikeln nur wenig brauchbare Informationen gezogen werden
konnten. Es fehlen Werke, die zusammenfassend einen Überblick über die Autorisationsproblematik
geben. Material zur Umsetzung einer Zugriffskontrolle für Web Services ist kaum
auffindbar, was den Forschungsbedarf in diesem Bereich unterstreicht. Für den in dieser Arbeit
betrachteten Spezialfall feingranularer, raumbezogener Zugriffskontrolle für Geo Web
Services konnten keine hilfreichen Quellen gefunden werden. Das im Rahmen dieser Arbeit
entwickelte und implementierte Konzept liefert daher einen substantiellen Fortschritt im Forschungsgebiet
der sicheren Nutzung verteilter Geodaten über Geo Web Services. Das herausgearbeitete
Zugriffskontrollmodell zeigt, wie feingranulare und raumbezogene Zugriffskontrolle
für Geo Web Services bzw. für GML-kodierte Geodaten erreicht werden kann. Die
Ausführungen dieser Arbeit können als Basis für Standardisierungen im Bereich raumbezogener
Zugriffskontrolle dienen und/oder in konkreten Anwendungsfällen als Anleitung und
Muster zur Umsetzung eines Zugriffskontrollsystems verwendet werden.
Um einem Paradigma der Informationsverarbeitung – der Interoperabilität – zu genügen,
wurde das vorgestellte Konzept für raumbezogene Zugriffskontrolle konsequent auf Spezifikationen
internationaler Standardisierungs- und Normierungsgremien aufgebaut. Des weiteren
standen bei der Entwicklung die Informatikprinzipien Austauschbarkeit, Erweiterbarkeit
und „separation of concerns“ im Vordergrund.
Das Modell und die prototypische Implementierung erfüllen zwar die geforderten Ziele,
könnten jedoch an einigen Stellen weiterentwickelt werden. Aufgrund des Umfangs dieser
Ergänzungen wurden sie in den vorliegenden Ausführungen nicht behandelt, um den Rahmen
der Arbeit nicht zu sprengen. Der Vollständigkeit halber werden diese allerdings im Folgenden
kurz erwähnt.
Das Beispielregelwerk dieser Arbeit wurde per Hand editiert. Dieses Vorgehen ist allerdings
sehr umständlich, zeitaufwendig und fehleranfällig. Gerade angesichts komplexer Autorisationen
und mehrerer SSOs ist es deutlich besser, das entwickelte Zugriffskontrollsystem um einen
PAP zur Pflege und Verwaltung des Regelwerkes zu erweitern. Dadurch wäre eine komfortable
Eingabeschnittstelle für Zugriffsregeln gegeben, die zahlreiche Vorteile, wie beispielsweise
eine semantische Überprüfungen des Regelwerkes (z.B. Konflikterkennung), eine
Visualisierung von Raumregeln oder die Unterstützung eines Regelwerkes zur Administration
des Regelwerkes der Anwendung bieten könnte.
Zusätzlicher Forschungsbedarf besteht des weiteren im Bereich Performance. Es muss beispielsweise
analysiert werden, wann der Pre- oder der Post-Processing Ansatz als Zugriffskontrollmechanismus
für feingranulare, inhaltsabhängige Zugriffskontrolle zu verwenden ist.

129
Zu beweisen ist ebenfalls, dass bei der Definition von Autorisationen gemäß dem Pre-
Processing Ansatz völlige Flexibilität gegeben ist und dass Q’ (d.h. der modifizierte dann sicher
Query) unter allen Umständen erzeugt werden kann. So erwähnte Dongwon Lee, einer
der Erfinder des Q-Filter Ansatzes, im Mailverkehr, dass er bislang nur Regelfilterprädikate
in der konjuktiven Normalform (KNF) behandelt habe. Prädikate, die eine Negierung enthalten,
wurden von Dongwon Lee stets in KNF umgewandelt (siehe MailLee).
Ebenfalls interessant aber noch ungeklärt ist, inwieweit mächtige feingranulare Autorisationen
verwaltbar sind und ob diese ausreichend reaktionsschnell überprüft werden können. Des
weiteren ist zu betrachten, wie bei einer Zugriffskontrolle nach dem „so viel wie geht“ Prinzip
verhindert werden kann, dass böswillige Nutzer durch geschickte Anfragen und zugriffsbeschränkte
Antworten indirekt Information über nicht zugreifbare Daten bekommen.
Bislang wurde zudem ausschließlich der zweidimensionale Fall berücksichtigt. Es gilt noch
zu erforschen, welche Konsequenzen eine Erweiterung auf den dreidimensionalen Fall hat, ob
dies sinnvoll ist und ob das vorgestellte Konzept weiterhin gültig bleibt.
Seitens des Autors ist geplant, die genannten Aspekte in einer auf dieser Arbeit aufbauenden
Geographie Diplomarbeit zu behandeln. Ebenso soll in dieser anhand eines realen Anwendungsbeispieles
darauf eingegangen werden, wie Regelwerke inhaltlich aufzubauen sind (z.B.
an welche Variablen inhaltsabhängige Autorisationen gebunden werden sollen, welche Vorraussetzungen
Zugriffsregeln erfüllen müssen, um im PAP Konflikte in Zugriffsregeln zu erkennen
usw.).
Abschließend ist zu erwähnen, dass die vorgestellten Konzepte nicht nur für Geo Web Services
einsetzbar sind. Es ist vorstellbar, dass die in dieser Arbeit verfolgte Vorgehensweise zur
Realisierung raumbezogener Zugriffskontrolle für beliebige Anwendungen, die das Arbeiten
mit strukturierten Daten ermöglichen (z.B. XML Datenbanken), verwendbar ist.

130
Literaturverzeichnis
AC Mech 2004
AC XML 2002
Altinel 2002
Brügge 2000
Bungartz 1996
CoordTrans
Córcoles 2002
Damiani 2000
LUO, B.; LEE, D.; LEE, W.-C.; et al. (2004): A Flexible Framework for
Architecting XML Access Control Enforcement Mechanisms. Pennsylvania.
Online im Internet. URL: http://nike.psu.edu/publications/
sdm04.pdf (Stand: 30.9.2004).
DIVESH, S.; YU, T.; et al. (2002): Compressed Accessibility Map: Efficient
Access Control for XML. Online im Internet. URL:
http://www.csc.ncsu.edu/faculty/yu/courses/csc591d/handouts/ATN.p
df (Stand: 20.9.2004).
ALTINEL, M.; DIAO, Y.; FRANKLIN, M. J.; et al. (2002): Path sharing
and predicate evaluation for high-performance XML filtering. Online
im Internet. URL: http://www.cs.berkeley.edu/˜diaoyl/publications/
yfilter-public.pdf (Stand: 30.9.2004).
BRÜGGE, B.; HERZOG, C. (2000): Einführung in die Informatik Funktionale
Programmierung. Online im Internet. URL:
http://atbruegge27.informatik.tu-muenchen.de/teaching/ws00/Info1/
vorlesung/folien/08a_Funktional.pdf (Stand: 23.2.2005).
BUNGARTZ, H.-J.; GRIEBEL, M.; ZENGER, C. (1996): Einführung in die
Computergraphik: Grundlagen, Geometrische Modellierung, Algorithmen.
Wiesbaden.
FRANSON TECHNOLOGY AB: Franson CoordTrans – Programm zur
Transformation von Koordinaten. Online im Internet. URL:
http://franson.com/coordtrans/download.asp?platform=winxp (Stand:
7.3.2005).
CÓRCOLES, J. E.; GONZÁLEZ, P. (2002): A Specification of a Spatial
Query Language over GML. Online im Internet. URL:
http://portal.acm.org/citation.cfm?id=512186 (Stand: 15.10.2004).
DAMIANI, E.; DE CAPITANI DI VIMERCATI, S.; SAMARATI, P.; et al.
(2000): Design and Implementation of an Access Control Processor
for XML Documents. Online im Internet. URL:
http://www9.org/w9cdrom/419/419.html (Stand: 15.9.2004).

131
Damiani 2001
Damiani 2002
Diao 2003
Eckert 2002
Gallagher 1987
GI-Lexikon
GIS-Glossar
GML-QL 2002
Hauser 2004
DAMIANI, E.; DE CAPITANI DI VIMERCATI, S.; SAMARATI, P.; et al.
(2001): Controlling Access to XML Documents. Mailand. Online im
Internet. URL: http://seclab.dti.unimi.it/Papers/ieee-ic.pdf (Stand:
17.9.2004).
DAMIANI, E.; PARABOSCHI, S.; SAMARATI, P.; et al. (2002): A Fine-
Grained Access Control System for XML Documents. ACM Transactions
on Information and System Security (TISSEC) archive Volume
5 , Issue 2, S. 169 – 202. Online im Internet. URL:
http://portal.acm.org/citation.cfm?id=505586.505590 (Stand:
23.9.2004).
DIAO, Y.; FRANKLIN, M. J. (2003): Query processing for high-volume
XML message brokering. Berkeley. In ACM CCS. Online im Internet.
URL: http://portal.acm.org (Stand: 25.9.2004).
ECKERT, C. (2002): IT-Sicherheit. München.
GALLAGHER, P. (1987): A Guide to Understanding Discretionary Access
Control in Trusted Systems. National Computer Security Center
(NCSC-TG-003 Version 1). Online im Internet. URL:
http://nestroy.wi-inf.uniessen.de/Lv/ibis2/discretionary_acces_control.html
(Stand:
5.10.2004).
GI-Lexikon des Instituts für Geodäsie und Geoinformatik der Uni
Rostock. Online im Internet. URL: http://www.geoinformatik.unirostock.de/suche.asp
(Stand: 5.2.2005).
M Schilcher, M (2003): GIS-Glossar. Online im Internet. URL:
http://www.gis1.bv.tum.de/Aktuelles/GIS-Glossar/Dokumente/GIS-
Glossar_online.pdf (Stand: 5.2.2005).
VATSAVAI, R. R. (2002): GML-QL: A Spatial Query Language Specification
for GML. Online im Internet. URL:
http://www.cobblestoneconcepts.com/ucgis2summer2002/vatsavai/vat
savai.htm (Stand: 30.11.2004).
HAUSER, T.; LOWER, U. M. (2004): Web Services – Die Standards.
Galileo Press GmbH. Bonn.

132
Huber 2002
HUBER, U. W. (2002): Das Referenz-Geoinformationssystem „Nationalpark
Bayerischer Wald“, eine fachübergreifende Forschungsplattform
für die Geoinformatik. München.
ITSEC 2001
Bundesamt für Sicherheit in der Informationstechnik (2001): Leitfaden
für die Erstellung und Prüfung formaler Sicherheitsmodelle im
Rahmen von ITSEC und CC. Online im Internet. URL:
http://www.bsi.de/aufgaben/projekte/fmethode/sonstige/wwwleitf.htm
(Stand: 11.10.2004).
Jajodia 2001
JAJODIA, S.; SAMARATI, P.; SAPINO, M. L. (2001): Flexible Support
for Multible Access Control Policies. Online im Internet. URL:
http://homes.dsi.unimi.it/~samarati (Stand: 20.9.2004).
JTS Tech Spec 1.4
VIVID SOLUTIONS (Hrsg.) (2003): JTS Topology Suite, Technical Specifications,
Version 1.4. Online im Internet. URL:
http://www.vividsolutions.com/JTS/bin/jts-1.4.0.zip (Stand:
10.02.2005).
Lampson 1974
LAMPSON, B. W. (1974): Protection. In: ACM Operating System Review,
Vol. 8, S. 18-24.
Leitfaden GIS 2003 BAYERISCHES STAATSMINISTERIUM DER FINANZEN (Hrsg.) (2003):
Leitfaden für kommunale GIS-Einsteiger. München. Online im Internet.
URL: http://www.gis-leitfaden.de/GIS-Leitfaden-www.pdf
(Stand: 30.11.2004).
MailAnderson a
Mailverkehr vom 7.10.04 mit Anne Anderson. Online im Internet.
URL: http://www.geo.wiso.tu-muenchen.de/herrmann/da/mailquellen
(Stand: 10.03.2005).
MailAnderson b
Mailverkehr vom 9.10.04 mit Anne Anderson. Online im Internet.
URL: http://www.geo.wiso.tu-muenchen.de/herrmann/da/mailquellen
(Stand: 10.03.2005).
MailLee
Mailverkehr vom 15.10.04 mit Dongwon Lee. Online im Internet.
URL: http://www.geo.wiso.tu-muenchen.de/herrmann/da/mailquellen
(Stand: 10.03.2005).

133
MailProctor
Mailverkehr vom 5.10.04 mit Seth Proctor. Online im Internet. URL:
http://www.geo.wiso.tu-muenchen.de/herrmann/da/mailquellen
(Stand: 10.03.2005).
OGC Filter Spec 1.0 VRETANOS, P. A. (2001): Filter Encoding Implementation Specification,
Version 1.0.0. Open GIS Consortium, Inc. (Hrsg.). Online im Internet.
URL: http://www.opengis.org/techno/specs/02-059.pdf (Stand:
30.11.2004).
OGC GML 2.1.2
OGC SFS 1.1
OGC WFS 1.0.0
Opincaru 2004
O’Reilly 2002
PreProc 2003
RBAC 1996
COX, S.; CUTHBERT, A.; LAKE, R.; et al. (2002): OpenGIS Geography
Markup Language (GML) Implementation Specification, Version
2.1.2. Open GIS Consortium, Inc. (Hrsg.). Online im Internet. URL:
http://www.opengis.net/gml/02-069/GML2-12.html (Stand:
27.10.2004).
OPEN GIS CONSORTIUM, INC. (Hrsg.) (1999): OpenGIS Simple Features
Specification For SQL Revision 1.1. Online im Internet. URL:
http://www.opengis.org/techno/specs/99-049.pdf (Stand: 18.9.2004).
VRETANOS, P. A. (2002): Web Feature Service Implementation Specification,
Version 1.0.0. Open GIS Consortium, Inc. (Hrsg.). Online im
Internet.
URL:
https://portal.opengeospatial.org/files/?artifact_id=7176 (Stand:
20.1.2005).
OPINCARU, C. (2004): Study about Securing OPENGIS Web Services.
Institut für Technik Intelligenter Systeme an der Universität der Bundeswehr
München. München.
O’REILLY (Hrsg.), HAROLD, E. R.; MEANS W. S. (2002): XML in a
Nutshell. Sebastopol.
LUO, B.; LEE, D.; LEE, W.-C.; et al. (2004): QFilter: Fine-Grained
Run Time XML Access Control via NFA-based Query Rewriting. Online
im Internet. URL: http://nike.psu.edu/publications/cikm04.pdf
(Stand: 15.10.2004).
SANDHU, R. S.; COYNE, E. J., FEINSTEIN, H.; et al. (1996): Role-Based
Access Control Models. Online im Internet. URL:
http://www.list.gmu.edu/journals/computer/i94rbac(org).pdf (Stand:
30.11.2004).

134
Samarati 2000
SAMARATI, P.; DE CAPITANI DI VIMERCATI, S. (2000): Access Control:
Policies, Models and Mechanisms. Online im Internet. URL:
http://homes.dsi.unimi.it/~samarati (Stand: 15.1.2005).
Schilcher et al. 2004 SCHILCHER, M; AUMANN, G; MATHEUS, A; et al. (2004): Abschlussbericht
Geoportal. München.
Schilcher GeoInf1
SCHILCHER, M. (2001); Skript zur Vorlesung Geoinformatik 1. Kapitel
3, 4 und 6. Online im Internet. URL:
http://www.gis1.bv.tum.de/Lehre/Vorlesungen/Geoinformatik1/Geoin
formatik1.htm (Stand: 5.10.2004).
Scholz 2001
SCHOLZ, D. (2001); Diplomarbeiten normgerecht verfassen. Schreibtipps
zur Gestaltung von Studien-, Diplom- und Doktorarbeiten.
Würzburg.
StatAnalysis 2003
MURATA, M.; TOZAWA, A.; KUDO, M. (2003): XML Access Control
using Static Analysis. In: ACM CCS, Washington D.C.. Online im Internet.
URL: http://portal.acm.org/citation.cfm?id=505576.505590
(Stand: 30.11.2004).
Summers 1997
SUMMERS, R. C. (1997): Secure Computing: Threats and Safeguards.
Maidenhead: McGraw-Hill.
SUNXACML 1.2
SUN (Hrsg.); PROCTOR, S. (2004): Sun's XACML Implementation
Programmer's Guide for Version 1.2. Online im Internet. URL:
http://sunxacml.sourceforge.net/guide.html (Stand: 3.10.2004).
Tannenbaum 2002
TANNENBAUM, A. S. (2002): Moderne Betriebssysteme. München.
Twig Queries 2002
CHO, S.; DIVESH, S.; SIHEM, A.-Y.; et al. (2002): Optimizing the Secure
Evaluation of Twig Queries. Online im Internet. URL:
http://www.research.att.com/~divesh/ papers/cals2002-secureopt.abs
(Stand: 8.10.2004).
W3C DefWS
AUSTIN, D.; BARBIR, A.; FERRIS, C.; et al. (2004): Web Service Architekture
Requirements. Online im Internet. URL:
http://www.w3.org/TR/wsa-reqs/ (Stand: 24.11.2004).

135
W3C XML 1.0
W3C XML Schema
W3C XPath 2.0
W3C XSLT 1.0
XACML HierProf
XACML MultProf
XACML Spec 1.1
YFilter 2003
BRAY, T.; PAOLI, J. ; SPERBERG-MCQUEEN, C. M.; et al. (2004): XML
Specification Version 1.0. World Wide Web Consortium (Hrsg.).
Online im Internet. URL: http://www.w3.org/TR/2004/REC-xml-
20040204 (Stand: 30.11.2004).
THOMPSON, H., BEECH, D.; MALONEY, M.; et al. (2001): XML
Schema Part 1: Structures. World Wide Web Consortium (Hrsg.). Online
im Internet. URL: http://www.w3.org/TR/xmlschema-1 (Stand:
30.11.2004).
FERNANDEZ, M. F.; KAY, M.; ROBIE, J.; et al. (2003): XML Path Language
(XPath) 2.0. World Wide Web Consortium (Hrsg.). Online im
Internet. URL: http://www.w3.org/TR/2003/WD-xpath20-20031112
(Stand: 30.11.2004).
CLARK, J. (1999): XSL Transformations (XSLT) Specification Version
1.0. World Wide Web Consortium (Hrsg.). Online im Internet.
URL: http://www.w3.org/TR/1999/WD-xslt-19990421 (Stand:
30.11.2004).
ANDERSON, A. (2004); Hierarchical Resource profile of XACML.
Committee Draft 01, 30 September 2004. Online im Internet. URL:
http://docs.oasis-open.org/xacml/access_control-xacml-2.0-
hier_profile-spec-cd-01.pdf (Stand: 5.10.2004).
ANDERSON, A. (2004); Multiple Resource profile of XACML. Committee
Draft 01, 30 September 2004. Online im Internet. URL:
http://docs.oasis-open.org/xacml/access_control-xacml-2.0-
mult_profile-spec-cd-01.pdf (Stand: 5.10.2004).
OASIS (Hrsg.); GODIK, S.; MOSES, T. (2003): eXtensible Access Control
Markup Language (XACML) Version 1.1, Committee Specification.
Online im Internet. URL: http://www.oasisopen.org/committees/xacml/repository/cs-xacml-specification-1.1.pdf
(Stand: 15.9.2004).
DIAO, Y.; FRANKLIN, M. J. (2003): High-Performance XML Filtering:
An Overview of YFilter. Online im Internet. URL:
http://www.csdl.computer.org/comp/proceedings/
icde/2002/1531/00/15310341.pdf
(Stand: 25.9.2004).

136
Anhang A
Anwendungsszenario – Die Schweizer Bank
Für ein besseres Verständnis der in dieser Arbeit vorgestellten Techniken zur Realisierung
raumbezogener Zugriffskontrolle soll folgendes fiktives, aber dennoch realistisches Anwendungsszenario
angenommen werden:
Die Schweizer Bank besitzt Gebäude, Straßen und Bankautomaten. Diese stellen georeferenzierbare
geographische Objekte dar. Gebäude werden als Polygone, Straßen durch Linienzüge
und Bankautomaten als Punkte dargestellt. Zu jedem dieser Objekte stehen neben den raumbezogen
Daten auch Sachdaten zur Verfügung. Für die Verwaltung der dezentral gehalten Informationen
zu diesen Objekten durch die weltweit verteilten Bankangestellten setzt die Bank
einen WFS ein. Bankangestellte können sowohl lesend als auch schreibend über den WFS auf
die Objekte der Bank zugreifen. Welche Daten gewisse Bankangestellte sehen dürfen, unterliegt
staatlichen Gesetzen und Regulierungen. Zudem existiert bei der Schweizer Bank eine
Verwaltungseinheit, welche die für die Mitarbeiter möglichen Aktionen auf bestimmten Daten
verfeinernd festlegt. Zur Umsetzung dieser Zugriffsregeln soll der WFS um ein XACMLbasiertes
Zugriffskontrollsystem ergänzt werden, um die Anforderungen des Datenschutzes zu
erfüllen.
Im Anhang A.1 wird das Modell der Daten, die vom WFS bereit gestellt werden, aufgeführt.
Unter A.2 findet sich eine Beispielanfrage an den WFS sowie die darauf folgende Antwort
des Dienstes der Bank. Anhang A.3 enthält die umzusetzenden Zugriffsregeln.
Anhang A.1 Das den Geodaten zugrundeliegende Datenmodell
Im Folgenden wird das Datenmodell je Featuretyp in Worten, und ergänzend über UML Klassendiagramme
beschrieben. Zudem findet sich unter A.2 eine diesem Schema genügende
XML Dokumentinstanz (umhüllt in einer WFS Response).
Gebäude
Ein Feature vom Typ Gebäude besitzt die Eigenschaften Name (String), Besitzer (String),
Baujahr (Integer) und Anzahl_Stockwerke (Integer). Zusätzlich besitzen Gebäude eine
geometrische Eigenschaft Geometrie. Diese ist ein dem GML Datenmodell (OGC
GML 2.1.2) entsprechender Polygon-Datentyp.
UML Klassendiagramm zum Gebäude Featuretyp

137
GEBÄUDE
Name: String
Besitzer: String
Baujahr: Integer
Anzahl_Stockwerke: Integer
Geometrie: Polygon
Straßen
Features vom Typ Straße besitzen die Eigenschaften Bezeichner (String), Belag_Typ
(String), Anzahl_Spuren (Integer) sowie die geometrische Eigenschaft Geometrie. Diese
ist wieder ein dem GML Datenmodell (OGC GML 2.1.2) entsprechender Linenzug-
Datentyp.
STRAßE
Bezeichner: String
Belag_Typ: String
Anzahl_Spuren: Integer
Geometrie: Linienzug
Bankautomat
Ein Feature vom Typ Bankautomat besitzt die Eigenschaften ID (Integer), Monteur
(String), kameraüberwacht (Boolean), existiertSeit (Date) sowie die geometrische
Eigenschaft Geometrie. Diese ist vom GML Datentyp Punkt.
BANKAUTOMAT
ID: Integer
Monteur: String
kameraüberwacht: Boolean
existiertSeit: Date
Geometrie: Punkt

138
Die unten abgebildete Karte in Abbildung A.1 stellt exemplarisch 37 einige Gebäude-, Straßenund
Bankautomat-Objekte der Bank in Zürich dar.
Legende
Bankautomat
Straße
Gebäude
Abbildung A.1 Gebäude-, Straßen- und Bankautomat-Objekte der Schweizer Bank in Zürich

139
Anhang A.2 Beispielanfrage an und Antwort vom WFS
Um die Funktionalität des Regelwerkes und die aus Sicht des Zugriffskontrollsystems besonders
interessanten Fälle zu analysieren, wird hier zunächst eine Beispielanfrage eines Bankangestellten
definiert, der alle Daten zu Straßen, Bankautomaten und Gebäuden der Schweizer
Bank im Gebiet Zürich (kodiert durch das Polygon 50,40 100,60 38 ) einsehen möchte. Anschließend
ist die entsprechende Antwort 1 des WFS abgedruckt.
Beispiel für eine GetFeature Anfrage an den WFS der Schweizer Bank:
myns:Geometrie
myns:Bezeichner
myns:Belag_Typ
myns:Anzahl_Spuren
myns:Geometrie
50,40 100,60
myns:Geometrie
myns:ID
myns:Monteur
myns:Kameraüberwacht
myns:existiertSeit
myns:Geometrie
50,40 100,60
myns:Geometrie
myns:Name
38 rein fiktive Daten

140
myns:Baujahr
myns:Besitzer
myns:Anzahl_Stockwerke
myns:Geometrie
50,40 100,60
Beispiel für eine Antwort des WFS der Schweizer Bank (korrespondierend zu oben abgedruckter
Anfrage):
-180.0,-90.0 180.0,90.0
120,360 280,360
280,240 120,240 60,300 120,360
ETH
1980
Staat
5
80,300 80,260 140,220
140,260 200,280 200,340
N304
ASPHALT

141
6
280,300
0000000002
Firma Meier
false
30.11.2002
...
Anhang A.3 Das Regelwerk der Schweizer Bank
An dieser Stelle sollen einige Zugriffsregeln auf Daten zu Gebäuden, Straßen und Bankautomaten
der Schweizer Bank kurz in Worten angegeben werden. Für ihre Umsetzung in
XACML wird aufgrund der Länge der entsprechenden Deklarationen auf die Dateien im Verzeichnis
policy der im Inneneinband der Arbeit beigefügten CD-ROM verwiesen.
Sämtliche in diesem Abschnitt vorgestellten Zugriffsregeln sind so definiert worden, dass sie
den Zugriff auf genau ein Feature der WFS Antwort (vgl. A.2) beschränken. Dadurch kann
bei Ausführung des Prototypen und anschließender Überprüfung der Ausgabe des PEPs (die
modifizierte WFS Antwort beim Post-Processing oder die modifizierte WFS Anfrage beim
Pre-Processing) nachvollzogen werden, welchen Effekt die Zugriffsregel auf die Aktion des
Nutzers hat. Alle hier vorgestellten Zugriffsregeln haben negativen Effekt, was bedeutet, dass
die der Regel zugehörige Instanz aus der WFS Antwort gefiltert wird. Aus diesem Grund sind
die modifizierten WFS Antworten nicht explizit aufgeführt.
Des weiteren ist zu erwähnen, dass die Regeln zum Postprocessing sofern sie den Zugriff auf
ein Feature beschränken sollen ab dem FeatureMember Element greifen, damit in der WFS
Antwort nicht ein leeres FeatureMember Element auftaucht.
Beispiele: Zugriffsregeln für eine Zugriffskontrolle nach dem Post-Processing Ansatz
Beispiel 1:
Um aufzuzeigen, welche Möglichkeiten Instanzregeln bieten, seien hier noch zwei weitere Instanzregeln
definiert.

142
Regel 1: Ein Mitarbeiter der Bank darf nur dann auf Gebäudedaten der Bank lesend zugreifen,
wenn der Name des Gebäudes nicht ETH ist.
Für die XACML-kodierte Form dieser Regel sei auf die Datei einzelne_Testfaelle_Instanzregel.xml
verwiesen.
Regel 2: Ein Auszubildender der Bank darf nur dann auf Daten zu den Bankautomaten der
Bank lesend zugreifen, wenn alle unten aufgelisteten Bedingungen erfüllt sind:
• Der Zugriff muss zwischen 9 und 17 Uhr erfolgen.
• Die FeatureID der Bankautomaten muss im Intervall [0, 100] liegen.
• Der Monteur der Bankautomaten muss die Firma Meier sein.
• Der Bankautomat darf nicht kameraüberwacht sein.
• Der Bankautomat muss nach dem 1.1.2000 errichtet worden sein.
Die Formulierung dieser Regel findet sich in der Datei einzelne_Testfälle_Instanzregel2.xml.
Beispiel 2:
Raumbezogene Zugriffsregel in Abhängigkeit des Standpunktes des Web Service Nutzers
Hier soll aufgezeigt werden, dass das in 5.1 vorgestellte Konzept zur Deklaration raumbezogener
Zugriffsregeln unverändert auch für Autorisationen verwendet werden kann, die sich
auf den Standort des Web Service Nutzers beziehen. Vorausgesetzt werden muss hierfür, dass
aus der Kommunikation zwischen Nutzer und Web Service (die über den PEP läuft) zuverlässig
ermittelt werden kann, wo sich der Nutzer befindet. Sofern dies möglich ist, muss der PEP
diese Information z.B. per XACML Attribut (location_WS_User) im XACML Request Context
übergeben, wovon in diesem Beispiel ausgegangen werden soll.
Bei der Schweizer Bank lautet ein Bankdatengesetz beispielsweise, dass ein Angestellter der
Schweizer Bank, der in New York seinen Arbeitsplatz hat, nur Daten von amerikanischen
Kunden sehen darf.
Die XACML basierte Formulierung dieser Regel findet sich in der Datei einzelne_Testfälle_Instanzregel3.xml.

143
Beispiel 3: Raumregeln
Da die Umsetzung raumbezogener Zugriffskontrolle im Mittelpunkt dieser Arbeit stand und
es daher zur Validierung der Ergebnisse von besonderer Bedeutung ist, sämtliche Fälle abzudecken,
die bei der Deklaration raumbezogener Autorisationen auftreten können, wurden
zahlreiche Testfälle definiert. Die Testregeln sind so organisiert, dass die topologischen Operationen
(touches und within 39 ) und die räumlichen Operationen (length, distance, iswithin-
Distance) überprüft werden. Zu jeder Operation werden dabei alle sinnvollen (vgl. hierzu Anhang
B) Parameterkombinationen (z.B. (Punkt,Punkt) oder (Polygon,Polygon)) überprüft.
Zum Nachvollziehen der Tests sei auf die unten aufgelisteten Dateien im Verzeichnis policy
verwiesen:
• einzelne_Testfaelle_Touches_AA.xml
• einzelne_Testfaelle_Touches_AL.xml
• einzelne_Testfaelle_Touches_AP.xml
• einzelne_Testfaelle_Touches_LA.xml
• einzelne_Testfaelle_Touches_LL.xml
• einzelne_Testfaelle_Touches_LP.xml
• einzelne_Testfaelle_Touches_PA.xml
• einzelne_Testfaelle_Touches_PL.xml
• einzelne_Testfaelle_Touches_PP.xml
• einzelne_Testfaelle_Within_AA.xml
• einzelne_Testfaelle_Within_LA.xml
• einzelne_Testfaelle_Within_LL.xml
• einzelne_Testfaelle_Within_PA.xml
• einzelne_Testfaelle_Within_PL.xml
• einzelne_Testfaelle_Within_PP.xml
• einzelne_Testfaelle_areaOfPolygon.xml
• einzelne_Testfaelle_isWithinDistance_PA.xml
• einzelne_Testfaelle_isWithinDistance_PA.xml
• einzelne_Testfaelle_lengthOfLine.xml
Alternativ kann zum Überprüfen der Testfälle auch die Datei policy_WFS.xml verwendet
werden. In dieser sind sämtliche Testfälle auskommentiert enthalten. Zur Überprüfung der
einzelnen Fälle können diese selektiv einkommentiert werden. Sofern alle Regeln auskommentiert
bleiben und werteNotApplicableAlsDeny im PEP auf true eingestellt wurde,
bekommt der Nutzer keine Daten, da keine Regel auf die Anfrage greift.
Beispiel 4
In der Datei RaumregelMitBoundedBy.xml wird eine Raumregel definiert, die prüft ob alle
angefragten Features unabhängig von ihrem Typ in einem gewissen Gebiet liegen. Sofern
kein angefragtes Feature in den Zugreifbaren Gebieten liegen kannn das Zugriffskontrollsystem
bereits ein deny für alle angefragten Features zurückgeben (Performacegewinn da auswertung
gegebenenfalls vorhandener einzelner Regeln nicht mehr nötig ist)
39 Der Einfachheit halber wurden die Testfälle für die übrigen topologischen Relationen nur probeweise überprüft
und die entsprechenden Regeln wurden nicht explizit gespeichert.

144
Beispiel 5
In diesem Beispiel wird eine Attributregel definiert. Ihr Ziel ist, exemplarisch die in Abschnitt
6.3.4 aufgeführte Alternative zur Gewährleistung übereinstimmender Koordinatensysteme zu
errreichen, bevor Raumregeln angewendt werden. Hierzu wird das srsName Attribut der angefragten
Gebäudeinstanzen mit dem Literal http://www.opengis.net/gml/srs/epsg.xml#4326
(eindeutige Kodierung des EPSG 4326 Raumbezugssystems) verglichen.
Die entsprechende XACML Testregel findet sich in der Datei einzelne_Testfaelle_Instanzregel_aufAttribut.xml.
Alle weiteren Regelbeispiele finden sich im Verzeichnis policy auf der CD-ROM und sind
durch die ergänzenden Kommentare selbsterklärend.

145
Anhang B
Verwendbarkeit topologischer Relationen
Es werden nur Relationen auf den Grundtypen Punkt, Linienzug und Polygon – also nicht auf
MultiGeometrietyp und Geometry Collection – betrachtet. Für MultiGeometrietypen
gelten die selben Vergleichsmöglichkeiten wie für den entsprechenden Grundtyp.
Daher sind die MultiGeometrietypen zu den Grundgeometrien nicht extra in den Tabellen
aufgeführt. Werden die topologischen Relationen auf MultiGeometrietypen angewendet,
so muss für jedes Element der Menge die Relation zu mindestens einem Element der
zweiten Menge erfüllt sein.
Welche Vergleichsmöglichkeiten zwischen zwei Geometry Collections möglich sind, hängt
von den enthalten Grundtypen ab. Da nicht klar definiert ist, welche Semantiken für räumliche
Analysemethoden, die auf Geometry Collections ausgewertet werden, gelten sollen, sind
Geometry Collections nicht als Argumente topologischer Relationen angebbar (JTS Tech
Spec 1.4, S. 26).
Lesehinweis:
• Reihenfolge: Geometrie Zeile Relation Geometrie Spalte
• grün – sinnvoller Vergleich
• rot – Vergleich der immer false liefert
• grau – nicht definierter Vergleich
equals point line polygon
point
line
polygon
disjoint point line polygon
point
line
polygon
intersects point line polygon
point
line
polygon

146
touches point line polygon
point
line
polygon
crosses point line polygon
point
line
polygon
overlaps point line polygon
point
line
polygon
within point line polygon
point
line
polygon
contains point line polygon
point
line
polygon

147
Anhang C
Organisiation der XACML PolicySets, Polices und Regeln
XACML bietet bei der Definition und Organisation des Regelwerkes maximale Flexibilität,
da nur die zu verwendende Syntax vorgegeben wird. Leider erschwert diese völlige Flexibilität
ein leichtes Umsetzen und Administrieren des Regelwerkes für einen konkreten Anwendungsfall.
Für SSOs ist es nicht leicht, mit der Mächtigkeit der Sprache umzugehen. Unklar
konzipierte Regelwerke bergen das Risiko, dass sie mit der Zeit unüberschaubar und chaotisch
werden und für unerwünschtes Verhalten des Zugriffskontrollsystems sorgen. Um diese
Gefahr zu vermeiden, sollte man gewisse Grundsätze beim Definieren von XACML Regeln,
Policys und PolicySets festlegen. Deren Einhaltung wird umso essentieller, je größer
das Regelwerk ist, je mehr SSOs die Regeln pflegen, wenn Zugriffsregeln sowie Datenbasis
einer Dynamik unterliegen und wenn die Policen verteilt gespeichert werden. Da die genannten
Faktoren in Zugriffskontrollsystemen für (Geo) Web Services vorliegen können, ist es in
diesem Anwendungsgebiet unbedingt nötig, ein klar strukturiertes Regelwerk zu entwerfen,
das nach festen Modellierungsprinzipien erstellt wurde. Im Folgenden soll versucht werden,
einige Entwurfsprinzipien festzulegen, die dem Autor nach intensiver Auseinandersetzung
mit der Thematik als sinnvoll erscheinen.
C.1 Vorgeschaltete Überprüfung inhaltsunabhängiger Zugriffsregeln
Zur Performanceverbesserung des Zugriffskontrollsystems ist es empfehlenswert, dass der
Context Handler nach Erhalt einer vom PEP generierten globalen Zugriffsentscheidungsanfrage
als erstes eine spezielle individuelle Zugriffsentscheidungsanfrage (Aufbau vgl. Ausführungen
unten) generiert.
Der Einsatz dieser speziellen Zugriffsanfrage ist unabhängig davon, ob der Pre- oder der Post-
Processing Ansatz verwendet wird und ist in beiden Fällen zur Optimierung des Zugriffskontrollsystems
anzuraten. Dadurch kann das Zugriffskontrollsystem und gegebenenfalls der
Web Service vor unnötiger Belastung (z.B. durch unautorisierte Anfragen, „denial of service“
Attacken, unnötige Regelauswertungen usw.) geschützt werden. Durch die spezielle Zugriffskontrollanfrage
kann ermittelt werden, ob der Nutzer bzw. die Rolle:
• dem Zugriffskontrollsystem überhaupt bekannt ist.
• für die gewünschte Aktion jemals ausreichend Rechte hat.
• seine Anfrage an einen für ihn nutzbaren WS geleitet hat.
• die Anfrage an den richtigen Port geleitet hat.
• …

148
All diesen Überprüfungen ist gemeinsam, dass die Zugriffsentscheidung unabhängig vom
konkreten Inhalt der Web Service Anfrage bzw. Antwort ist und dafür keine Auswertung inhalts-
und raumbezogener Zugriffsregeln stattfinden muss. Bei der Auswertung der speziellen
individuellen Zugriffsentscheidungsanfrage wird daher das ResourceContent Element, in
dem das zu schützende XML Dokument enthalten ist, nicht berücksichtigt.
Würde man die eben genannten Überprüfungen in das Hauptregelwerk integrieren, so würden
diese zu jeder individuellen Zugriffsentscheidungsanfrage aufs Neue kontrolliert werden, obwohl
sie konstant für alle individuellen Anfragen zum selben Ergebnis evaluieren.
Erwähnt sei, dass unabhängig von der vorgeschalteten Überprüfung einiger Zugriffsregeln,
die Action und Subject Attribute der Zugriffsentscheidungsanfrage im Kontext der Ressource
bei der nachfolgenden Anwendung des Hauptregelwerkes kontrolliert werden müssen.
Zur Realisierung der vorgeschalteten Überprüfung einiger Zugriffsregeln muss neben dem
Hauptregelwerk für den Web Service ein zweites Regelwerk existieren. In diesem sind nur
Zugriffsregeln enthalten, die unabhängig vom Resource Teil der Zugriffsentscheidungsanfrage
sind. Damit im PDP entschieden werden kann, ob es sich bei einer Zugriffsentscheidungsanfrage
um die vorgeschaltete spezielle Zugriffsentscheidungsanfrage handelt, muss
diese entsprechend vom PEP gekennzeichnet werden. Dazu wird das resource-id Attribut
der speziellen Zugriffsentscheidungsanfrage mit einem Wert wie beispielsweise „generalChecks“
belegt. Ansonsten ist deren Inhalt identisch der globalen Zugriffsentscheidungsanfrage.
Der resource-id Wert wirkt in diesem Fall wie ein Schalter. Entspricht der Wert
von resource-id „generalChecks“, dann verwendet der PDP das spezielle Regelwerk für
die vorgeschalteten Überprüfungen, die unabhängig von der Ressource sind. Ansonsten wird
das eigentliche Regelwerk der Anwendung zur Zugriffsentscheidung herangezogen. Das Verzweigen
in das entsprechende Regelwerk wird über zwei PolicySets unterhalb der Wurzel
des Regelwerkes erreicht. Diese überprüfen in ihrem Target ausschließlich den Wert des resource-id
Attributes.
C.2 Grobstruktur des Regelwerkes bei Web Services
Ausgangsituation ist, dass eine individuelle Zugriffsentscheidungsanfrage an den PDP übermittelt
wird. Diese wird durch das Tupel Subjekt, Knoten und Aktion charakterisiert. Aufgabe
des PDPs ist es, schnell die zu diesem Tupel passenden Regeln zu identifizieren.
Abgesehen von der besonderen Police, die sich auf die vorgeschaltete spezielle Zugriffsentscheidungsanfrage
bezieht, sollte das eigentliche Hauptregelwerk für den Web Service als ein
Baum organisiert werden. Die Alternative wäre, sich bei der Wahl der Grobstruktur für eine
flache Strukturierung zu entscheiden. Mit flacher Strukturierung ist gemeint, dass alle Regeln

149
in einer Policy liegen. Dadurch müssen zu jeder Zugriffsentscheidungsanfrage alle Regeln
auf Anwendbarkeit geprüft werden. Da sich dadurch ein Aufwand von O (Anzahl Regel) ergeben
würde, ist die baumartige Strukturierung der flachen Strukturierung vorzuziehen.
Die Wurzel des baumartigen Regelwerkes ist ein PolicySet Element mit einem Target
Element, das folgendermaßen aufgebaut ist:
generalChecks
...
Dadurch kommt das Hauptregelwerk zur Anwendung, unabhängig davon welcher Nutzer eine
Operation auf dem Web Service tätigt. Es spielt außerdem keine Rolle, welche Aktion er auf
dem Web Service ausführt. Der Abgleich des resource-id Attributs mit dem Literal „generalChecks“
über die Funktion string-NOT-equal ist nötig, um die vorgeschaltete spezielle
Zugriffsentscheidungsanfrage (vgl. C.1) abweisen zu können.
Unterhalb des eben eingeführten Wurzel-PolicySets des Hauptregelwerkes folgt eine
baumartige Schachtelung der PolicySets (PolicySet…PolicyRules), wobei
die Target Bereiche der PolicySets, Policies oder Rules je Level im Regelwerkbaum
stetig eingegrenzt werden sollten (d.h die Targets der Kinder-PolicySets sollten
das Target des Vater-PolicySets weiter einschränken). Dies entspricht einem Clustering
Prinzip. Dadurch sind die für eine individuelle Zugriffsentscheidungsanfrage relevanten
Regeln schnell bestimmbar. Nach Identifikation der relevanten Regeln kann der PDP diese
auswerten und die Zugriffsentscheidung ermitteln. Vorteil einer solchen Organisation des Regelwerkes
ist, dass sich die Laufzeit bei der Auswertung einer konkreten individuellen
Zugriffsentscheidungsanfrage an O (log (Anzahl Regeln)) annähern kann, vorausgesetzt es
existieren zu jeder Policy ungefähr gleich viele Regeln und der Regelwerkbaum ist möglichst
höhenausgeglichen.
40 ist selbst zu definieren, da im Target die not Funktion nicht die string-equal Funktion umhüllen
kann.

150
Neben der baumartigen Strukturierung sollte das Ziel sein, alle Regeln, die zu einer individuellen
Zugriffsentscheidungsanfrage greifen könnten, in einer Policy zu halten. Dadurch
kann einfach und übersichtlich durch den regelverbindenden Algorithmus das Gesamtergebnis
bei mehrfachem Regelmatch bestimmt werden.
Zur Entscheidungsfindung, wie ein Regelwerkbaum zu strukturieren ist, spielen folgende
Faktoren eine entscheidende Rolle:
• Anzahl an Nutzern
• Anzahl an Operationen
• Anzahl an Schemaknoten
• Anzahl und Art der Regeln
• Hierarchie der SSOs
• unterschiedliche konfliktauflösende Strategien
• fehlende Knoten sind unterschiedlich berücksichtigt
• Open vs. Closed Policy
• feinere Strukturierungen (z.B. „räumliches Clustering“ von Raumregeln – vgl. C.3)
• usw.
Wie die zahlreichen Faktoren zeigen, kann aufgrund der Abhängigkeit vom Anwendungsfall
kein allgemeingültiger Vorschlag für eine sinnvolle Strukturierung des Regelwerkes gemacht
werden. Dennoch soll eine Empfehlung zur Grobstrukturierung des Regelwerkes diskutiert
werden, deren Ziel es ist, für möglichst viele Anwendungsfälle sinnvoll zu sein. Selbst wenn
aufgrund besonderer Gegebenheiten der Vorschlag unbrauchbar sein sollte, demonstriert er
dennoch, welche Überlegungen bei der Strukturierung berücksichtigt werden müssen.
Geschachtelte PolicySets sollen, wie oben erwähnt, die Target Bereiche nach innen
weiter einschränken. Dadurch wird die Menge der potentiell anwendbaren Anfragen geringer.
Dies entspricht der Tatsache, dass aus Sicht eines beliebigen Knotens des XML Schemas der
zu schützenden Daten die Anzahl der darunter liegenden Knoten abnimmt. Es bietet sich daher
an, die Struktur des Regelwerkbaumes dem Schemabaum anzupassen.
An das Schema der zu schützenden Daten angepasste Strukturierung:
Um dies zu realisieren, müssen die regulären Ausdrücke im Resource Element der Targets
der PolicySet Elemente einem Knoten im Schemabaum entsprechen. Zu jedem E-
lement- oder Attributknoten im Schema existiert daher genau ein PolicySet. In diesem
PolicySet Element existieren „Anzahl Kinder des Schema-Knotens“, darunter liegende
PolicySet Elemente und ein „lokales PolicySet" für den Knoten selbst. Welche Organisation
unterhalb des lokalen PolicySets vorliegt wird als Feinstruktur des Regelwerkes
angesehen und wird unter C.3 behandelt.

151
Zusätzlich zu der an den Schemabaum angepassten Struktur des Regelwerkbaumes bietet es
sich an, in Abhängigkeit der Operation und/oder in Abhängigkeit des Nutzers zu strukturieren.
Strukturierung in Abhängigkeit der Operation auf den Web Service:
Ist das Regelwerk je Operation sehr unterschiedlich (z.B. Regeln für die Leseoperationen und
Regeln für die Löschoperationen auf den Web Service), so ist es empfehlenswert, auf dem
ersten Level des Hauptregelwerkes nach der Operation auf den Web Service zu differenzieren
(Level null entspricht der Wurzel des Regelwerkes). Unterhalb der Differenzierung nach der
Operation schließt sich die Strukturierung in Abhängigkeit des Schemas an.
Strukturierung in Abhängigkeit des Nutzers des Dienstes:
Auf welcher Ebene in dem am XML Schema orientierten Regelwerkbaum nach Nutzer unterschieden
werden soll, ist ausschließlich vom Anwendungsfall abhängig (Anzahl Nutzer, Anzahl
Regeln je Nutzer, Ähnlichkeit der Regeln je Nutzer etc.). Es kann kein sinnvoller, allgemein
gültiger Vorschlag gemacht werden.
Vorgestellt wurden drei kombinierbare Strukturierungsmöglichkeiten. Eine nur am Schema
orienterte Strukturierung impliziert automatisch, dass Kinder eines PolicySets immer disjunkt
und vollständig sind, was Ziel eines sauber strukturierten Regelwerkes sein sollte.
(Zur Verdeutlichung, was unter der Disjunktheit der Kinder verstanden wird:
M sei die Menge der Anfragen, für die PolicySet A greift. Vollständig und disjunkt bedeutet
nun, dass für alle M i ’s genau ein Kind-PolicySet von A bzw. eine Kind-Policy
von A greift.)
Sollen weitere Strukturierungsvarianten verfolgt werden (z.B. nach Nutzern), dann muss der
SSO bei der Definition des Regelwerkes explizit für den Erhalt der Disjunktheit sowie Vollständigkeit
sorgen. Hierzu sei erwähnt, dass Vollständigkeit auf Regelebene durch eine default
Regel (diese ist immer anwendbar) erreicht werden sollte. Eine Alternative, die Vollständigkeit
indirekt zu erreichen, wäre not applicable als deny zu werten. Existiert zu einer
Anfrage kein PolicySet, keine Policy und keine Regel, dann gibt der PDP zu dieser
Zugriffsentscheidungsanfrage not applicable zurück. Dies kann im PEP dann als ein deny gewertet
werden.

152
C.3 Feinstruktur des Regelwerkes
Die weitere Strukturierung des Regelwerkes unterhalb der lokalen PolicySets – charakterisiert
durch das Target-Tupel (Nutzer, Schemaknoten, Aktion) – wird als Feinstruktur bezeichnet.
Diese sollte, wie schon die Grobstruktur, Vollständigkeit sowie Disjunktheit von den PolicySets
bzw. Policies unterhalb des lokalen PolicySets fordern. Mögliche Variablen
für eine verfeinerte Unterteilung sind beispielsweise Raumbezug, SRS, zuständiger SSO etc..
Bei einer Zugriffskontrolle für Geodaten bzw. für einen Geo Web Service ist wegen des
Raumbezuges eine besondere Feinstrukturierung möglich (das so genannte räumliche Clustering
Prinzip), die im Folgenden kurz vorgestellt werden soll.
Ziel ist es, zu einem „lokalen PolicySet“ eine darunter liegende räumliche Clustering PolicySet-Hierarchie
aufzubauen, die den Raum vollständig und in disjunkte Teilgebiete zerlegt.
Jedes dieser Teilgebiete kann wiederum in Teilgebiete zerlegt werden. Je Teilgebiet wird
ein eigenes PolicySet erzeugt. In diesem gibt es wieder je Unterteilgebiet ein eigenes PolicySet.
Auf der untersten Ebene – kleingranularste Teilgebiete – existiert eine Policy,
welche die Raum- und RaumInstanzregeln, die sich auf dieses Teilgebiet beziehen, beinhaltet.
Beziehen sich die Regeln auf zwei Teilgebiete, weil sich die Featureinstanz über die Teilgebietgrenzen
erstreckt, so müssen sie redundant in den entsprechenden Policies auftauchen.
Regeln, die keinen Raumbezug haben, stehen auf der selben Ebene wie die Wurzel der räumlichen
Clustering PolicySet-Hierarchie.
Durch die Beispiele auf der CD-ROM wird demonstriert, wie die genannten Strukturierungsvorschläge
umgesetzt werden können.
C.4 Organisation der SSOs
In der Praxis ist der Fall eines einzigen SSOs eher die Ausnahme. Zudem stellt er in Bezug
auf die Anforderungen an eine Zugriffskontrolle eine echte Untermenge des Multi-SSO Falls
(d.h. mehrere SSOs verwalten das Regelwerk) dar. Nachfolgend wird daher immer angenommen,
dass mehrere Administratoren das Regelwerk pflegen. Es ist sinnvoll, den SSOs
möglichst disjunkte Zuständigkeitsbereiche zu geben. Beispiele für Variablen, die zur disjunkten
Aufteilung der Zuständigkeitsbereiche der SSOs dienen könnten, sind:
• nach Nutzern
• nach Featuretypen
• nach Raumbezug

153
• nach Operation auf den Web Service bzw. auf die Objekte
• …
In Fällen, in denen dies nicht möglich ist (z.B. SSO Aufteilung nach Regeltyp – SSO A legt
allgemeine Regeln fest und SSO B definiert Verfeinerungs-Regeln), müssen die parallel zuständigen
SSOs durch ein weiteres Regelwerk koordiniert werden (vgl. C.5). In diesem kann
z.B. durch die Vergabe von Prioritäten je SSO – vergeben durch einen Master-SSO – geregelt
werden welcher SSO wann welche Regeln festlegen darf. Durch die Prioritäten ausgewertet
von regelverbindenden Algorithmen lassen sich administrative Hierarchien abbilden. Höherer
Rang bedeutet höhere Priorität. Die Regeln eines höherrangigen SSOs sind nicht durch die
niederrangigen SSOs veränderbar. Verändert dagegen ein höherrangiger SSO die Regeln eines
untergeordneten SSOs, so ist dies erlaubt. Allerdings sollte der betroffene SSO von der
Veränderung seiner Regeln benachrichtigt werden. Gleiche Priorität würde bedeuten, dass die
Regeln des konkurrierenden SSOs wie die eigenen behandelt werden können. Dies bedeutet,
dass die SSOs aus Sicht des Zugriffskontrollsystems wie ein SSO behandelt werden. Daher
ist es zu vermeiden, den SSOs bei gleichem Zuständigkeitsbereich die selbe Priorität zu geben.
C. 5 Regelwerk für die Verwaltung der Zugriffsgesetze der Anwendung
Um ein ungewolltes Abändern der konfliktauflösenden Strategie oder ein unkontrolliertes
Überschreiben vorhandener Regeln zu vermeiden, ist eine Zugriffskontrolle für die Verwaltung
des Regelwerkes selbst nötig. Mit solchen Zugriffsregeln wird festgelegt, wer auf welche
Art und Weise gewisse Zugriffsgesetze verändern kann. Um das Zugriffskontrollsystem der
Anwendung nicht unnötig zu verkomplizieren, sollte entweder nur eine Person diese administrativen
Zugriffsgesetze festlegen können oder die Zuständigkeitsbereiche der einzelnen
„Ebene 2 Administratoren“ müssen disjunkt sein. Würden nämlich mehrere Personen die „Ebene
2 Zugriffsgesetze“ für den selben SSO verwalten, so müsste, um die Aktionen der „Ebene
2 Administratoren“ untereinander zu koordinieren, ein drittes Regelwerk existieren. Das
dritte Regelwerk regelt die Administration des „Ebene 2 Regelwerkes“.
Die Zugriffskontrolle für die Verwaltung des Regelwerkes muss festlegen, für wen welche
Zugriffsregeln modifizierbar sind, ob sowohl positive als auch negative Regeln möglich sein
sollen, wann welche konfliktauflösenden Strategien verwendet werden können, welcher Administrator
welche Attribute in der Regel festlegen darf (z.B. Prio etc.),…
Wie Zugriffsregelwerke auf Ebene 2 oder gegebenenfalls auf höheren Ebenen verwaltet werden,
soll in dieser Arbeit nicht näher betrachtet werden. Zu erwähnen ist allerdings, dass die
gleichen Probleme und Lösungsansätze wie bei einer Zugriffskontrolle für die Anwendung
selbst auftreten und daher konzeptionell nichts Neues hinter dieser Thematik steckt. Neue

154
Herausforderung eines mehrschichtigen Zugriffskontrollsystems ist lediglich die erhöhte semantische
Komplexität durch die unterschiedlichen aufeinander aufbauenden Regelwerke.
C.6 Designprinzipien bei der Deklaration von Zugriffsegeln für XML Dokumente
Basis für die Definition von Zugriffsregeln für dynamisch generierte XML Dokumente ist das
den Dokumentinstanzen zugrundeliegende XML Schema. Das Regelwerk muss berücksichtigen,
dass in diesem Schema Existenz, Anzahl und Reihenfolge gewisser Knoten offen festgelegt
ist. Ziel eines guten Regelwerkes sollte es sein, Regeln so allgemeingültig wie möglich
zu definieren, damit sie eine maximale Stabilität gegenüber einer Dynamik der Datenbasis
aufweisen (z.B. Nutzen des Raumbezuges bei Zugriffsregeln für immobile Featuretypen).
Der SSO kann bei der Definition von Zugriffsregeln positive und/oder negative Regeln unterschiedlichsten
Typs definieren. Traditionell unterscheidet man zwischen zwei unterschiedlichen
Ansätzen:
Geschlossene Verfahrensweise ( engl. Closed Policy):
Man definiert nur positive Autorisationen. Alle nicht explizit für zugänglich erklärten Daten
sind zugriffsbeschränkt – dies entspricht also der Grundeinstellung (Anglizismus: default Regel)
„Zugriff verboten“. Dieser Ansatz ist besonders dann geeignet, wenn der Großteil der
Daten zugriffsbeschränkt sein soll.
Offene Verfahrensweise ( engl. Open Policy):
Es werden nur negative Autorisationen explizit spezifiziert. Bei dieser Taktik wird Zugriff
gewährt, wenn keine einschränkende Autorisation vorliegt. Somit lautet die default Regel in
diesem Fall „Zugriff erlaubt“. Diese Variante wird in Szenarien bevorzugt, in denen nur wenige
Zugriffsbeschränkungen festzulegen sind.
Hinter beiden Varianten steckt die gleiche Idee. Die expliziten Regeldefinitionen bestimmen
die zugreifbaren bzw. zugriffsbeschränkten Datenobjekte. Der Rest wird durch die default
Regel abgedeckt. Welche Variante zu bevorzugen ist, hängt ganz vom Anwendungsszenario
ab.
Verwendet man bei der Definition der Zugriffsregeln entweder die Open Policy oder die Closed
Policy, so hat man zwei entscheidende Vorteile:

155
• Vollständigkeit:
Zu jeder Zugriffsanfrage greift mindestens eine Zugriffsregel.
• Konfliktfreiheit:
Zu einer Zugriffsanfrage greifen entweder nur positive oder nur negative Zugriffsregeln.
Allerdings kann die Forderung, dass ausschließlich explizite positive Regeln oder nur explizite
negative Regeln in einer Regelgruppe vorkommen dürfen, unerwünscht sein. Gründe sind
beispielsweise:
• Geringere Flexibilität bei der Regeldefinition
• Die Ausdrucksstärke des Regelwerkes ist eingeschränkt.
In Szenarien, in denen eine neue Zugriffssemantik nur durch eine Regel gegensätzlichen Effekts
im Regelwerk umgesetzt wird, ist eine Kombination von positiven und negativen Regeln
gefordert.
Beispiel:
Eine Firma definiert in einer offenen Verfahrensweise (Open Policy) eine Menge an negativen
Regeln, welche die globale Firmenstrategie umsetzen. Eine dieser globalen Regeln verbietet
den Zugriff auf Daten zu Gebäuden innerhalb Bayerns. Möchte eine Abteilung dieser
Firma aber, dass Daten zu Gebäuden mit einem Kaufpreis über einer Million zugänglich sind,
so kann dies nur erreicht werden, wenn die Regelsemantik aus der globalen Firmenstrategie
umgeändert wird. Dies kann auf zwei Weisen geschehen:
• Umschreiben der vorhandenen Regel
• explizites Deklarieren einer positiven Regel und Festlegen eines konfliktauflösenden Algorithmuses,
der die Regel dieser Abteilung bevorzugt
Wie dieses Beispiel verdeutlicht, hat das Zulassen von Regeln gegensätzlichen Vorzeichens
nicht nur eine Erhöhung des Komforts im Regeldefinitionsprozess zur Folge, sondern ermöglicht
auch eine sauberere Trennung der Regeln der unterschiedlichen SSOs (Umschreiben
impliziert Verschmelzen von Regeln).
Erwähnt sei, dass man an der Forderung nach einer Open Policy durchaus festhalten kann,
ohne Einschränkungen bei der Umsetzung einer Zugriffssemantik unterworfen zu sein, wenn
für jedes Feature immer nur ein SSO zuständig ist. Allerdings ist der dafür nötige Prozess des
Integrierens einer positiven Regel sehr komplex und fehleranfällig. Um dieselbe Regelsemantik
durch negative Regeln ausdrücken zu können, muss gegebenenfalls ein Umschreiben der
vorhandenen negativen Regeln und/oder ein Hinzufügen neuer negativer Regeln erfolgen.

156
Möchte bzw. muss man zu einer Policy sowohl positive als auch negative Regeln festlegen,
so hat dies zur Folge, dass die Konfliktfreiheit nicht mehr unbedingt sichergestellt ist. Vollständigkeit
des Regelwerkes kann nach wie vor über eine zusätzliche default Regel gewährleistet
werden. Alternativ könnte man dieses Ziel auch durch explizite Regeldefinition erreichen.
Wie aber in Samarati 2000 auf Seite 32 aufgeführt, ist das Fordern von Vollständigkeit
durch explizite Regeldefinition zu schwierig und verkompliziert unnötig die Administration
der Regeln.
Nachfolgende Designprinzipien beziehen sich auf eine Post-Processing Zugriffskontrolle
nach dem „so viel wie geht“ Prinzip. Es werden Vorschläge gemacht, wie das Resource E-
lement im Target der Regel und gegebenenfalls deren Condition Element zu spezifizieren
ist.
Der reguläre Ausdruck im Resource Element des Targets der Regel genügt den Knoten,
ab denen die Regel den Zugriff beschränkt.
Regeln sollten den Zugriff auf Knoten so differenziert wie möglich beschränken, da dadurch
Post-Processing nach dem „so viel wie geht“ Prinzip begünstigt wird.
Im Target wird ganz allgemein definiert, für welche Knoten die Regel greifen soll. Eine
verfeinerte Selektion der Knoten in Abhängigkeit der Inhalte der Objektinstanzen findet erst
im Condition Teil der Regel statt.
Anzuraten ist, dass die SSOs bei der Definition inhaltsbezogener Zugriffsregeln nur Knoten in
den Regelbedingungen heranziehen dürfen, die erstens immer vorhanden sind und zweitens
immer einen Wert ungleich null haben (im XML Schema mit nilable=false gekennzeichnet).
Daraus folgt, dass in diesen Regeln die MustBePresent Attribute in den Attributselectoren
bzw. InformationSelectoren den Wert true haben müssen. Dadurch evaluiert die Regel sicher
zu „indeterminate“, wenn der entsprechende Knoten fehlt.