Full paper (pdf) - CDC

Fachbereich Informatik
Fachgebiet Theoretische Informatik
Prof. Dr. Johannes Buchmann
Zentralisierte Konfigurationsverwaltung
komplexer IT-Systeme
Diplomarbeit
Betreuer: Markus Ruppert
Vladislav Satanovski
Darmstadt, 25. August 2005

Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die vorliegende Diplomarbeit ohne Hilfe Dritter und
nur mit den angegebenen Quellen und Hilfsmitteln angefertigt habe. Diese Arbeit hat
in gleicher oder ähnlicher Form noch keiner Prüfungsehörde vorgelegen.
Darmstadt, 25. August 2005
iii

iv
EIDESSTATTLICHE ERKLÄRUNG

Danksagung
In erster Linie möchte ich meiner Frau Irina von ganzem Herzen für die Unterstützung
und Geduld danken. Sie bemühte sich immer, Rahmenbedingungen zu schaffen, die mir
ein erfolgreiches Studium ermöglichten. Deshalb widme ich ihr diese Arbeit.
Auch meiner Schwester Daria, die sich neben dem Korrektur lesen auch mit meinen
Kinder beschäftigte, während ich an dieser Arbeit schrieb, möchte ich ganz herzlich
danken. Für die Spaziergänge mit meinen Kindern danke ich auch meiner ganzen Familie,
die mir dadurch mehr Ruhe verschaffte, welche ich zum Schreiben dieser Arbeit
verwenden konnte.
Ein besonderer Dank geht an meinen Kollegen Georgios Raptis, der mit mir Konzepte
der Arbeit analysierte und mir wertvolle Verbesserungsvorschläge gab.
Zum Schluss möchte ich mich bei meinem Betreuer Markus Ruppert für das interessante
Thema, sowie die Unterstützung während der Arbeit bedanken. Obwohl die
Fertigstellung meiner Arbeit nach jedem Gespräch mit ihm weiter in die Ferne rückte,
waren seine Ideen und Vorschläge immer sehr konstruktiv und führten zu einer besseren
Lösung des gestellten Problems.
v

vi
DANKSAGUNG

Vorwort
Bei der vorliegenden Diplomarbeit handelt es sich nicht um eine theoretische Arbeit, bei
welcher der Diplomand sich erst viele Wochen lang in das Thema ”
einarbeiten“ muss,
um überhaupt zu verstehen, worum es geht. Diese Arbeit ist sehr praxis-orientiert, da
sie als Folge zahlreicher Probleme beim Konfigurieren und Installieren von komplexen
Anwendungen entstanden ist.
Das Ziel dieser Arbeit war von Anfang an klar – eine Konfiguration eines komplexen
Systems zu vereinfachen und zu standardisieren. Nicht klar war dagegen, wie dieses Ziel
erreicht werden soll.
Bei der Analyse ist ein großes Problem aufgefallen. Aufgrund dessen, dass das Zielsystem
( FlexiTRUST) von vielen Entwicklern während einer langen Zeitperiode entstand,
wurden in unterschiedlichen Modulen öfters unterschiedliche Architekturen verwendet,
welche sich nicht ohne Weiteres zu einem gemeinsamen Nenner bringen lassen. Bei den
ersten Versuchen, einheitliche Schnittstellen zu definieren, stoß man auf Widerstand
seitens Entwickler, weil die Änderungen manchmal einen komplett anderen Ablauf im
jeweiligen Modul nach sich ziehen würden.
Manche Module konnten generell nicht verändert werden, weil sie z.B. nicht direkt von
TUD kamen, sondern in Kooperation mit anderen Unternehmen entwickelt wurden.
Da solche Module aber immer noch einen Teil des Gesamtsystems bilden, müsste man
auch für diese eine Möglichkeit finden, ihre Konfiguration in die Gesamtkonfiguration
des Systems integrieren zu können.
Die Laufzeitumgebung spielte auch eine große Rolle. Manche Umgebungen wie z.B. ein
EJB-Container lassen nicht alle Operationen mit äußeren Resourcen zu, u.A. sind auch
Dateizugriffe eingeschränkt bzw. nur mit großem Aufwand möglich. Ein weiterer Aspekt
bilden Konfigurationsdateien solcher Umgebungen wie EJB-Container, Webserver etc.
Ihre Formate lassen sich nicht verändern, die Inhalte repräsentieren aber einen sehr
wichtigen Teil der Systemkonfiguration, müssen daher auch integriert werden.
Und schließlich spielt die Benutzbarkeit des zu entwickelnden Konfigurationssystems
auch nicht die letzte Rolle. Wird das System zu abstrakt entwickelt und dadurch nicht
benutzerfreundlich, so wird dieses von Entwicklern umgangen, zumindest in der Entwicklungsphase.
In einem solchen Fall bekommt man vor einer Auslieferung des Produktes
das alte Problem wieder - man muss die Konfiguration erst ”
bereinigen“, was
wieder unzählige Tage und Wochen Zeit in Anspruch nehmen kann.
vii

viii
VORWORT
Gesucht ist also ein Konfigurationssystem, welches allen oben genannten technischen
Anforderungen entspricht und dabei noch einfach zu bedienen ist, so dass es während
der gesamten Entwicklung ohne großen Aufwand mit verwendet werden und das fertige
Produkt anschließend mit der existierenden Konfiguration ausgeliefert werden kann.
Hoffentlich präsentiert diese Diplomarbeit eine entsprechende Lösung des Problems.

Inhaltsverzeichnis
Eidesstattliche Erklärung
iii
Danksagung
v
Vorwort
vii
1 Einleitung 1
1.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 FlexiTRUST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Konfigurationsdaten . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Zugriffsmechanismus . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.2 logische Strukturierung der Daten . . . . . . . . . . . . . . . . . 8
1.2.3 gleichnamige Parameterlisten . . . . . . . . . . . . . . . . . . . . 9
1.2.4 Wertebereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.5 Integritätsschutz . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.6 Profil-Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.7 Abhängigkeiten der Konfigurationsdaten . . . . . . . . . . . . . . 10
ix

x
INHALTSVERZEICHNIS
2 Problemanalyse 11
2.1 Meta-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Transformation der Daten . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Verteilungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Rollout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Datenmodell 17
3.1 Gliederung der Datenblöcke . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 leere Ebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Adressierung der Dateneinheiten - CCMPath . . . . . . . . . . . . 21
3.2 Konfigurationseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Standardtypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Ableitungen der Typen . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Ref-Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 EQ-Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Verwaltung und Verteilung der Daten 35
4.1 Abstrakte Sicht der Daten – RAA . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Verteilung der Daten – Connections . . . . . . . . . . . . . . . . . . . . 36
4.3 Daten-Absicherung – LSA/RSA . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Abstraktion des Schlüssel-Konzeptes . . . . . . . . . . . . . . . . 38
4.4 Datentranformation – XML/INI . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Zustellung der Konfigurationsdaten . . . . . . . . . . . . . . . . . . . . . 40
4.5.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.2 Roll-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 CCM-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

INHALTSVERZEICHNIS
xi
4.6.1 ADMIN-Zugang . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.7 Gesamtablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.7.1 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7.2 Rollout-Besonderheiten . . . . . . . . . . . . . . . . . . . . . . . 45
5 Administrierung des CCM-Systems 47
5.1 Problemanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.1 CCM-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.2 Content-Administrierung . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Vergleich der existierenden XML-Editoren . . . . . . . . . . . . . . . . . 49
5.2.1 XMLSpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.2 XAmple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3 Lösungsvorschlag - das configTOOL . . . . . . . . . . . . . . . . . . . . . 51
6 Ausblick 55
6.1 Abhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.1.1 Definition der Abhängigkeiten . . . . . . . . . . . . . . . . . . . . 55
6.1.2 Auflösung der Abhängigkeiten . . . . . . . . . . . . . . . . . . . 59
6.2 Automatische Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.1 Installationsdokumentation . . . . . . . . . . . . . . . . . . . . . 60
6.3 Erweiterung zur funktionsbasierten Sicht . . . . . . . . . . . . . . . . . . 61
6.3.1 Abbildung von Policies . . . . . . . . . . . . . . . . . . . . . . . . 62
7 Zusammenfassung 65
7.1 Rückblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2 So geht es weiter ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

xii
INHALTSVERZEICHNIS
A Schnittstellen 69
A.1 Secret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2 RuntimeInitializable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.3 ResourceAccessAdapter . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.4 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.5 LocalSecurityAdapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.6 RemoteSecurityAdapter . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B Datenmodell 77
B.1 Schema-Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.2 Beispiel-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.3 Abhängigkeitsdefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . 88
C CCM-Konfiguration 91
C.1 XMLSchema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
C.2 Beispiel-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.2.1 Server-seitige Konfiguration . . . . . . . . . . . . . . . . . . . . . 93
C.2.2 Client-seitige Konfiguration . . . . . . . . . . . . . . . . . . . . . 96
Glossar 99

Abbildungsverzeichnis
1.1 FlexiTRUST-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 FlexiTRUST-Interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 EQ-Vererbung, Elementen-Vergleich . . . . . . . . . . . . . . . . . . . . 30
3.2 Gesamtkonfiguration, Application-Sicht . . . . . . . . . . . . . . . . . . 30
3.3 Datenbank-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 IS-Konfiguration (EQ-Vererbung) . . . . . . . . . . . . . . . . . . . . . . 33
3.5 PI-Konfiguration (explizite EQ-Vererbung) . . . . . . . . . . . . . . . . 34
4.1 RemoteAccessAdapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 CCM-Sicherheitsadaptoren . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 CCM-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 CCM-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1 XMLSpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 XAmple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 configTOOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 configTOOL- CCM-Einstellungen . . . . . . . . . . . . . . . . . . . . . . 53
6.1 Funktions- vs. Komponentensicht . . . . . . . . . . . . . . . . . . . . . . 62
6.2 Policy-Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
xiii

xiv
ABBILDUNGSVERZEICHNIS

Kapitel 1
Einleitung
1.1 Problembeschreibung
Egal, welches Computerprogramm man betrachtet, stellt man fest, dass es stets Mechanismen
zur Steuerung vom Programmablauf gibt. Man spricht dabei über das Konfigurieren
eines Programms. Mit Hilfe von sog. Konfigurationsparametern teilt man dem
Programm mit, welche Aufgaben und auf welche Art erledigt werden sollen.
Je einfacher das Programm ist, desto weniger Konfigurationsmöglichkeiten hat es. Zählt
man jedoch die Anforderungen an die Umgebung dazu, so stellt man fest, dass sogar
einfachste ”
Hello World“-Programme über gewisse Konfigurationsmöglichkeiten solcher
Art verfügen – sie müssen z.B. für das lokale Betriebssystem übersetzt worden und hier
ausführbar sein.
Betrachtet man dagegen komplexere Anwendungen, so muss die Laufzeitumgebung
vielen Anforderungen genügen, damit die Anwendung überhaupt ausführbar wird, wie
z.B. Lese- und Schreibrechte auf Programmresourcen, Bestehen einer Netzwerkverbindung
bei verteilten Anwendungen, Authorisierung des Benutzers bei sicherheitskritischen
Komponenten u.V.m.
Das erste Problem tritt auf, wenn der Benutzer die Laufzeitanforderungen des Programms
nicht kennt. Dies mag bei einfachen Programmen kein großes Problem sein,
wenn man aber zu komplexeren Anwendungen übergeht stellt man schnell fest, dass
die Antworte auf manche Fragen nicht immer auf der Hand liegen. Nicht ausreichendes
Dokumentieren einer Anwendung führt sehr oft dazu, dass sie in einer nicht korrekten
Laufzeitumgebung ausgeführt wird. Das führt manchmal zu unerwarteten und schwer
erklärlichen Fehlern und irritiert den Benutzer.
Ein anderes Problem stellen extern für ein Programm abgelegte Konfigurationsdaten
dar. Typischerweise sind es Textdateien, welche bei der Initialisierung des Programms
eingelesen werden und deren Inhalte Programmabläufe steuern. Neben den bereits
erwähnten Anforderungen an die Laufzeitumgebung, die ebenso für solche Dateien
1

2 KAPITEL 1. EINLEITUNG
gelten (z.B. Zugriffsrechte), verbergen sich in den Konfigurationsdaten oft versteckte
Abhängigkeiten, welche manchmal auch komponentenübergreifende Auswirkungen
haben. So setzt z.B. eine Veränderung der Datenbank-Zugangsdaten die Existenz eines
korrespondierenden Datenbank-Benutzerprofils voraus.
Allgemein gesehen beschränken sich alle möglichen Konfigurationsprobleme auf die
oben erwähnten Fälle. An dieser Stelle würde man sich vielleicht fragen, ob das wirklich
Probleme sind, die man in einer Diplomarbeit behandeln müsste. Nun, wenn es um
Eigenprodukte geht, bei denen alle beteiligten Entwickler ständig erreichbar sind, dann
ist es tatsächlich kein so großes Problem, denn die Entwickler selbst können bestimmt
mit eigenen Programmen umgehen und wissen genau, welche Einstellungen welche Folgen
nach sich ziehen. Eine andere Situation hat man, wenn es ums Konfigurieren eines
fremden Produktes geht oder wenn die für eine Komponente verantwortliche Personen
gerade nicht da sind.
Um dies zu verdeutlichen wird an dieser Stelle das Verhalten eines komplexen IT-
Systems analysiert. Als Beispiel für fast alle in dieser Arbeit diskutierten Fälle wird
die Trustcenter-Software FlexiTRUST (siehe [9]) verwendet. Dabei handelt es sich um
ein komplexes verteiltes System, welches sehr viele Konfigurationsmöglichkeiten bietet
und dabei zeigt, wie viele Abhängigkeiten es zwischen einzelnen Komponenten eines
Systems geben kann und wie diese das Konfigurieren des gesamten Systems erschweren
können.
1.1.1 FlexiTRUST
An dieser Stelle wird kurz Architektur von FlexiTRUSTpräsentiert. Dabei wird das Ziel
sein, kein Benutzerhandbuch für FlexiTRUSTzu erstellen, sondern die Funktionen vom
Trustcenter kurz zu beschreiben und einzelne Komponenten des Systems darzustellen.
Trustcenter
Bei einer Public Key Infrastruktur (PKI, siehe [4]) bildet das Vertrauen in sog. digitale
Ausweise das Fundament. Solche Ausweise (auch Zertifikate genannt) beinhalten neben
den Identifizierungsdaten einer Person (Name, Firma etc.) und ihrem öffentlichen
Schlüssel auch eine digitale Signatur einer vertrauenswürdigen Instanz, welche Identität
dieser Person bestätigt. So eine Instanz kann z.B. eine Bank oder eine Behörde sein. Der
Benutzer, welcher ein solches Zertifikat einer anderen Person empfängt, sieht, welche
Person damit autorisiert wird und welche Instanz dies bestätigt. Daraufhin entscheidet
man, ob man dem Zertifikat (und der dahinter stehenden Person) vertraut werden
kann.
Bei angesprochenen vertrauenswürdigen Instanzen handelt es sich um sog. Trustcenter.
Die Aufgaben eines Trustcenters sind u.a.:
• Registrierung neuer Anträge zum Erstellen von Benutzerzertifikaten.

1.1. PROBLEMBESCHREIBUNG 3
• Generieren eines Zertifikates
• Publizieren von Zertifikaten in öffentlichen Verzeichnisdiensten (z.B. LDAP)
• jederzeitiges Verifizieren eines jeden Zertifikates
• Durchführung einer Sperrung von Zertifikaten
Die folgende Abbildung 1.1 auf Seite 3 zeigt eine allgemeine Aufbau eines Trustcenters.
Bei diesem Bild handelt es sich um eine leicht stilisierte Darstellung von Trustcenter-
Komponenten. Man sieht die drei Hauptkomponenten (RA, CA und IS), welche das
Kern eines Trustcenters bilden sowie den FlexiProvider (Kryptoprovider), der alle notwendige
kryptografische Algorithmen implementiert.
Abbildung 1.1: FlexiTRUST-Architektur
Verlässt man diese Abstraktionsebene und taucht etwas tiefer ein, so findet man eine
Fülle von Komponenten, die in ständiger Interaktion miteinander sind und Funktionalitäten
der Hauptkomponenten erweitern. Im Bild 1.2 auf Seite 4 wird das Zusammenspiel
der Komponenten grafisch dargestellt.
Komponentenüberblick
Nachfolgend werden alle im Bild 1.2 dargestellte Komponenten benannt und ihre Funktionen
erläutert. Dabei wird hier ausdrücklich darauf hingewiesen, dass die nachfolgende

4 KAPITEL 1. EINLEITUNG
Abbildung 1.2: FlexiTRUST-Interna
Liste der Komponenten nicht alle zur Zeit implementierte und eingesetzte Komponenten
umfasst und dass nicht alle Konfigurationsvarianten beschrieben werden.
Alle Komponenten sind in zwei Hauptgruppen (RA/IS und CA) und noch zwei weiteren
optionalen Gruppen (Letter-Print und Personalisierung) unterteilt. Normalerweise
werden RA/IS- und CA-Gruppen auf unterschiedlichen Rechnern betrieben, was zur
Sicherheit des Gesamtsystems beiträgt. Optionale Komponentengruppen können bei
Bedarf entweder auf dem RA/IS-Rechner laufen oder auf weitere externe Rechner verteilt
werden.
Registration Authority (RA) Die Aufgaben der RA sind u.A. Entgegennahme
von Anträgen, ihre Überprüfung auf Vollständigkeit und Weiterleitung an die CA. Die
Antragsdaten können übers Web-Frontend oder mittels eines Import-Tools eingegeben
werden und bleiben in der lokalen Datenbank abgelegt.

1.1. PROBLEMBESCHREIBUNG 5
Infrastructure Services (IS) Abhängig vom Aufgabenprofil müssen generierte Daten
(Zertifikate, Schlüsselpaare etc.) weiter verarbeitet werden, z.B. in Verzeichnisdiensten
veröffentlicht, in der Datenbank archiviert, an den Kunden verschickt etc. Dies und
mehr sind die Aufgaben der IS-Komponente.
Import Export Tool (ImpEx) Um den Datentransfer zum Trustcenter sowie zwischen
einzelnen Trustcenter-Rechnern zu automatisieren wurde die ImpEx-Komponente
entwickelt. Zu ihren Aufgaben zählen u.A. der Import von Antragsdaten in Form von
CSV-Dateien, Transfer der Daten zwischen dem RA/IS- und dem CA-Rechner, Erstellung
von Statistiken sowie Sortierung der Dateien nach Mandantenzugehörigkeit.
ProductInspector (PI) Am Anfang nur als ein Tool zum Administrieren der RA/IS-
Datenbank gedacht entwickelte sich der ProductInspector zu einem mächtigen, fast
beliebig erweiterbaren Werkzeug, welches Datenbankinhalte der Trustcenter-Tabellen
über das Web-Frontend anzeigt, BLOB-Felder inspizieren lässt, profilspezifische Operationen
und Tabellenfilter anbietet u.V.m.
Certification Authority (CA) Die Kernkomponente eines jeden Trustcenters! Die
CA übernimmt die eigentliche Generierung von Zertifikaten und evtl. Schlüsselpaaren,
Erstellung von Revokationslisten zum Sperren von Zertifikaten sowie optional elektronische
Personalisierung von Smartkarten. Die CA verwendet ihre eigene Datenbank,
in welcher alle antragsrelevante Daten abgelegt werden. Optional kann die CA mit
einer Eracom-Karte ausgestattet werden, welche sicheres Generieren von Schlüsselpaaren
auf der Hardware-Ebene ermöglicht. Werden Smartkarten personalisiert, so wird
ein Eltron-Drucker angeschlossen, welcher den Karten entsprechend eingetroffene Anträgen
einzieht und elektronisch personalisiert (= Zertifikate und Schlüsselpaare auf die
Karten schreibt)
Listener Die Personalisierung der Smartkarten kann nachträglich auch außerhalb
der CA erfolgen. In diesem Fall werden alle Daten von der CA vorbereitet und an den
RA/IS-Rechner zurückgegeben. Hier werden sie vom Listener erwartet und mit Hilfe
eines Eltron-Druckers elektronisch personalisiert. Im gleichen Schritt werden Karten
auch optisch personalisiert (= bedruckt), und zwar mit einer Fremdkomponente namens
”BadgeMaker”.
Letter-/PIN-Print Bei vielen Systemkonstellationen müssen Benachrichtigung- bzw.
PIN-Briefe gedruckt werden. Diese Aufgaben übernimmt die Letter-/PIN-Print-Komponente,
welche Daten der RA/IS-Datenbank entnimmt, diese nach XML konvertiert
und mittels einer extern definierten XSLT-Datei (XSL-FO-Transformation) ausdruckt.

6 KAPITEL 1. EINLEITUNG
Wie man sieht, wurde FlexiTRUST nicht ohne Grund als Beispiel für Diskussion über
komplexe Beziehungen innerhalb eines Systems ausgewählt. Man hat hier viele Komponenten,
die miteinander in Relationen stehen und deren Abläufe durch Veränderung
der Konfigurationsdaten leicht beeinflusst werden können.
1.1.2 Konfigurationsdaten
An dieser Stelle wird ein weiteres Problem eines solchen Systems dargestellt – heterogene
Konfigurationsdatei-Formate. Dieses Problem taucht auf bei komplexen Systemen,
welche während einer langen Zeitperiode und durch mehrere Entwickler entstanden
sind und dabei immer wieder weiterentwickelt wurden. Aber auch andere Systeme, die
nach einer genaueren Planungsphase entstanden sind, können über solche Heterogenität
verfügen und zwar z.B. durch Benutzung anderer Fremdkomponenten, bei welchen man
auf ein bestimmtes Format von Konfigurationsdaten angewiesen ist.
Property-Files
Typischerweise werden Konfigurationsdaten in Form von Property-Files (auch INI-
Files genannt) abgelegt. Dabei handelt es sich um einfache Textdateien, bei welchen in
jeder Zeile ein Konfigurationspaar = zu finden ist. Die eigentlichen
Konfigurationswerte (value) werden von Programmen über zugehörige Namen (name)
angesprochen.
Die so definierten Properties müssen dabei eindeutige Namen tragen, wodurch diese
Art der Speicherung folgende Schwächen aufweist:
1. Eine Gruppierung der auf der logischen Ebene zusammengehörenden Konfigurationseinheiten
ist nicht möglich;
2. Listen von gleichnamigen Parametern lassen sich nicht ohne Weiteres beschreiben;
3. Der Wertebereich ist für Konfigurationsparameter nicht definierbar;
4. Es ist kein Integritätsschutz der Konfigurationsdaten ohne zusätzlichen Maßnahmen
möglich;
5. Abhängigkeiten zwischen Konfigurationsdaten können nicht automatisch ermittelt
und aufgelöst werden.
Dazu ein erläuterndes Beispiel:
Beispiel 1 Es wird eine abstrakte Konfiguration beschrieben, welche u.A. eine variable
Anzahl der Datenbankverbindungen beschreiben soll. Dabei wird eine DB-Verbindung
durch folgende Größen definiert:

1.1. PROBLEMBESCHREIBUNG 7
• Datenbank-URL
• Datenbank-Treiber (mySQL, Oracle, ...)
• Benutzername
• Benutzerpasswort
Will man eine solche Struktur in Form eines Property-Files beschreiben, so entsteht in
etwa folgendes:
URL = jdbc:mysql://localhost/flexitrust
DRIVER = org.gjt.mm.mysql.Driver
USER = root
PASS = root
...
Versucht man eine Art Strukturierung durch Vergabe entsprechenden Prefixe (z.B. DB )
für Parameternamen deutlich zu machen (→ 1), so entsteht in etwa folgende Beschreibung:
DB_URL = jdbc:mysql://localhost/flexitrust
DB_DRIVER = org.gjt.mm.mysql.Driver
DB_USER = root
DB_PASS = root
...
Da in diesem Beispiel n verschiedene Datenbank-Verbindungen definierbar sein sollen
(→ 2), ändert sich die Property-File-Beschreibung zu:
# n = 5
DB_COUNT = 5
# für n = 1
DB_1_URL = jdbc:mysql://localhost/flexitrust_1
DB_1_DRIVER = org.gjt.mm.mysql.Driver
DB_1_USER = rauser
DB_1_PASS = rauser
# ...
# für n = 5

8 KAPITEL 1. EINLEITUNG
DB_5_URL = jdbc:mysql://localhost/flexitrust_2
DB_5_DRIVER = org.gjt.mm.mysql.Driver
DB_5_USER = isuser
DB_5_PASS = isuser
1.2 Anforderungen
Um die im oberen Kapitel genannte Veränderungen der Programmabläufe unter Kontrolle
zu halten sollte das Konfigurationsmanagementsystem gewissen Anforderungen
genügen. Nach langer Analyse kristallisierten sich folgende Anforderungen aus:
1.2.1 Zugriffsmechanismus
Obwohl Property-Files auf einfache Weise mittels java.util.Properties-Klasse geladen
werden können, müssen die darin enthaltene Datenstrukturen anschließend durch
das manuelle Interpretieren der Konfigurationswerte ausgelesen werden. Die Anwendung,
die die obere Beispielkonfiguration einliest, muss z.B. erst die Anzahl der darin
definierten DB-Konfigurationsblöcke auslesen (hier – 5), dann die Parameternamen für
verschiedene Blöcke bilden (DB 1 URL, DB 2 URL, ...) und anschließend entsprechende
Werte auslesen. Dabei sollte man die Prozedur der Fehlerbehandlung auf keinen Fall
vergessen!
Gewünscht ist also ein Mechanismus, der einheitliche Lese-/Schreibzugriffe auf Konfigurationsdaten
erlaubt, so dass auch auf die komplexen Datenstrukturen über diese
einheitliche Schnittstelle zugegriffen werden könnte.
1.2.2 logische Strukturierung der Daten
Eine Strukturierung der Konfigurationsdaten dient in erster Linie der besseren Lesbarkeit
der Dateien. Obwohl man bei Property-File-Strukturen gewisse Pseudo-Strukturierung
durch Hinzufügen von Prefixen erreicht, sieht die Konfigurationsdatei trotzdem
noch ”flach” unstrukturiert aus. Außerdem müssen die einzelnen Konfigurationsparameter
getrennt voneinander ausgelesen und interpretiert werden. So sind es in der oberen
Beispielkonfiguration 4 Werte, die eine Datenbank-Verbindung beschreiben; diese
werden auch getrennt voneinander eingelesen und ausgewertet, obwohl sie auf der logischen
Ebene zur gleichen Struktur gehören.
Für eine Beschreibung der komplexen Daten benötigt man unbedingt eine Möglichkeit,
Daten strukturiert zu definieren.

1.2. ANFORDERUNGEN 9
1.2.3 gleichnamige Parameterlisten
Weil Properties eindeutig benannt werden müssen, kommt es bei der Beschreibung von
Listen gleichnamiger Parametern zu einem weiteren Problem – eigentlich gleich heißende
Properties sollen nun verschiede Namen tragen. Die Beispielkonfiguration stellt diese
Situation gut dar: Es werden 5 Datenbank-Verbindungen beschrieben, alle Properties
beginnen mit dem Prefix DB (Gruppierung), gefolgt von der Nummer der Property in
der Liste (1...5).
Obwohl es auch bei Property-Files möglich ist, Listen gleichnamiger Properties zu beschreiben,
erfordert diese Lösung gewissen Programmieraufwand und ist nicht ohne
Weiteres einsetzbar. Man bräuchte also eine standardisierte Möglichkeit, solche Listen
zu beschreiben, ohne dass es zu großem Aufwand beim Lesen/Schreiben der Konfigurationsdaten
kommt.
1.2.4 Wertebereich
Je größer die Konfigurationsdateien sind, desto genauer sollen die Properties benannt
werden! Denn bei einer großen Anzahl der Konfigurationsparametern wird ein Entwickler
sehr schnell durcheinander gebracht. Wenn die Konfigurationsdateien dabei nicht
ausreichend kommentiert sind, dann bekommt man sehr schnell das Problem, dass
man nicht weiß, welche Werte für ein Property zulässig sind und was sie bedeuten.
So muss man z.B. wissen, dass der Datenbank-Treiber (Beispielkonfiguration) inklusive
alle Packagenamen angegeben werden soll, und dass der Datenbank-URL Kommunikationsprotokoll
(jdbc:mysql:) vorangestellt werden soll.
Es wäre sehr hilfreich, eine Möglichkeit zu haben, eine Art Definitionsbereich für die
Konfigurationswerte anzugeben. Noch besser wäre es, wenn im Falle einer Liste möglicher
Werte diese dem Benutzer zur Auswahl angeboten werden. Die gesetzten Werte
sollen am Besten noch vor der Ausführung des Programms auf Korrektheit überprüft
werden!
1.2.5 Integritätsschutz
Oft sind die in der Konfiguration definierten Parameter sicherheitskritisch. Falsch definierte
Kombinationen von Parametern können zu einer Sicherheitslücke führen, im
schlimmsten Fall sogar zum Crash des ganzen Systems! Daher sollen korrekte Konfigurationen
von ”nicht gut durchdachten” Änderungen seitens Dritter geschützt werden.
Wünschenswert wäre es, wenn man ein Mechanismus hätte, der die abgelegten Konfigurationen
sicher aufbewahrt und vor unauthorisierten Veränderungen schützt. Dies wäre
z.B. durch digitale Signaturen, die über die Konfigurationsdateien gebildet werden,
möglich.

10 KAPITEL 1. EINLEITUNG
1.2.6 Profil-Verwaltung
Komplexe Systeme wie z.B. FlexiTRUST haben oft mehrere Profile (verschiedene Konfigurationen),
die das System den Bedürfnissen des Auftraggebers anpassen. ”Fertige”
Konfigurationen (oder anders genannt – Releases) möchte man gerne als eigenes Konfigurationsprofil
ablegen und bei Bedarf schnell widerherstellen, ohne dass die anderen
Profile davon betroffen werden.
Konfigurationsmanagementsystem soll den Anwendern eine Möglichkeit geben, solche
Profile mit geringem Aufwand zu erstellen und zu verwalten. Dabei sollen Abhängigkeiten
zwischen einzelnen Konfigurationsdateien mit verwaltet werden, so dass ein Profil
selber weiß, aus welchen Dateien es besteht.
1.2.7 Abhängigkeiten der Konfigurationsdaten
Manchmal existieren gewisse Abhängigkeiten zwischen verschiedenen Konfigurationsdaten,
die evtl. auch in unterschiedlichen Dateien definiert werden. Oder es werden
gleiche Parameter in mehreren Dateien definiert, so dass sie eigentlich immer gleich
sein sollen.
Ein anderes Beispiel: Eine Anwendung verwendet Konfigurationsdateien, die von der
Umgebung bereitgestellt werden und die
• in einem anderen Datenformat abgelegt worden sind (z.B. XML vs. Properties)
oder
• an einer vordefinierten Stelle liegen müssen (z.B. Tomcat, JBoss)
Solche Konfigurationsdateien können nicht vollständig vom Management-System verwaltet
werden, eine Teilmenge der Konfigurationsparametern soll daher aus dem Management-System
in diese übertragen werden (sog. Synchronisation der Konfigurationsdaten).
Hierbei hat man oft große Schwierigkeiten, weil man nicht immer weiß,
welche Abhängigkeiten es überhaupt existieren und ob sie alle bereits berücksichtigt
wurden. Wenn ein Konfigurationsparameter geändert werden muss, so muss man auch
sicherstellen, dass alle deswegen notwendigen Änderungen (auch an weiteren Parametern)
durchgeführt wurden. Hat man eine Abhängigkeit vergessen zu berücksichtigen, so
führt es oft zu ”komischen” Seiteneffekten bzw. Fehlern, die sehr schwer zu lokalisieren
sind!
Das Management-System soll in der Lage sein, solche Abhängigkeiten zwischen Konfigurationsdaten
zu definieren bzw. zu verwalten. Am besten sollen bei Änderungen
eines Datensatzen alle dafür notwendige Änderungen anderer Datensätze automatisch
durchgeführt werden. Ist dies nicht möglich, so soll zumindest eine Liste der betroffenen
Abhängigkeiten ausgegeben werden, jeweils mit einem Kommentar, wie diese aufgelöst
werden könnten.

Kapitel 2
Problemanalyse
Noch ohne sich auf ein bestimmtes Datenformat oder eine bestimmte Architektur zu
binden werden in diesem Kapitel Überlegungen über mögliche Verwaltungsstrategien
der Konfigurationsdaten solcher komplexen IT-Systemen erläutert.
Abstrakt betrachtet existieren zwei Möglichkeiten solche Systeme zu verwalten:
• Konfigurationseinheiten (Dateien) bleiben zwischen den Systemkomponenten verteilt.
Ein Verwaltungsmodul enthält Informationen über das jeweilige Speicherort,
Dateiformat sowie weitere Metadaten (wie z.B. Definitionsbereiche, Profilzugehörigkeit,
etc.);
• Alle Konfigurationsdaten werden zentral in einer abstrakten Form gespeichert.
Beim Initialisieren des Systems werden einzelne Dateneinheiten an die Komponenten
verteilt.
Beide dieser Möglichkeiten haben sowohl Vor- als auch Nachteile.
Im Fall von verteilter Konfiguration hat man eine heterogene Datenmenge, die nur
mit erheblichem Aufwand auf Abhängigkeiten geprüft werden kann. Dazu kommen
Probleme der Zugriffsrechte für einzelne Dateien, wenn es sich um ein Unix/Linuxbasiertes
System handelt.
Im Falle einer zentralen Speicherstelle hat man die oben genannten Probleme nicht,
dagegen kommen aber ein paar andere hinzu. So ist es bei zentralisierter Konfigurationsverwaltung
notwendig, einzelne Dateneinheiten (Dateien) den Anwendungen zur
Verfügung zu stellen. Da die Daten an sich in einer abstrakten Form abgelegt sind
müssen entweder alle Komponenten des Systems umgebaut werden, damit sie Konfigurationsdaten
dieser Art verarbeiten können, oder die Daten zu ursprünglichen Dateiformaten
transformiert und den Komponenten in dieser für sie verständlichen Form
zugestellt werden.
11

12 KAPITEL 2. PROBLEMANALYSE
Trotz aller oben erwähnten Probleme wird hier (wie man dem Titel dieser Arbeit entnehmen
kann) die letztere Variante der Konfigurationsverwaltung bevorzugt, und das
aus folgendem Grund:
Probleme der zentralisierten Konfigurationsverwaltung sind zwar nicht trivial zu
lösen, dafür sind sie aber definitiv lösbar, und zwar mit Hilfe von unterschiedlichen
Standardverfahren, die auf nächsten Seiten näher erläutert werden. Eine
Verwaltung der verteilten Konfigurationseinheiten erzwingt dagegen Entwicklung
neuer Verfahren, die speziell auf diese Probleme orientiert werden müssen.
Darüber hinaus sind mehrere Probleme (wie z.B. Anaylse der Datenabhängigkeiten,
Definitionsbereich, etc.) im Allgemeinen gar nicht oder nur bedingt lösbar.
2.1 Meta-Konfiguration
Unter Metadaten werden hier Konfigurationsdaten verstanden, welche an einer zentralen
Stelle in einer abstrakten Form vorliegen. Neben eigentlichen Konfigurationsdaten
gehören dazu:
• Datentypen zur Eingrenzung der Definitionsbereiche;
• ursprüngliches Format der Konfigurationsdatei sowie zu einer Rücktransformation
in dieses Format notwendige Angaben.
2.1.1 Anforderungen
Betrachtet man alle oben genannten Anforderungen an das Verwaltungssystem, so stellt
man schnell fest, dass die Struktur solcher Metadaten sehr flexibel sein muss. Ausgehend
von dieser Feststellung führt ein weiterer Schritt unvermeidlich zur Festlegung des
Formats, und zwar zu XML. Die Gründe dafür liegen auf der Hand (folgend werden
oben definierte Anforderungen nochmals iteriert):
Zugriffsmechanismen
Es gibt viele standardisierte Zugriffsmechanismen für XML-Datenstrukturen. Die
meisten davon können über JAVA sehr einfach verwendet werden. Hier sei JAXB
hervorzuheben, da es sehr intuitive Lese-/Schreibmöglichkeiten für XML-Datenstrukturen
bietet.
logische Strukturierung der Daten
XML erlaubt beliebig tief verschachtelte Datenstrukturen zu definieren. Die Beispielkonfiguration
einer Datenbank-Verbindung aus dem letzten Kapitel hätte wie
folgt aussehen können:

2.1. META-KONFIGURATION 13
jdbc:mysql://localhost/flexitrust
org.gjt.mm.mysql.Driver
root
root
oder als eine Attribut-Variante:
gleichnamige Parameterlisten
Das Problem der Beschreibung von Listen gleichnamiger Elemente existiert bei
XML nicht! Mehrere Konfigurationsparameter mit gleichen Namen können einfach
nacheinander definiert werden, stellen somit verschiedene XML-Knoten dar
und werden dementsprechend getrennt behandelt. Beim Lesen der Daten mit
JAXB bekommt man z.B. einen Vektor von Elementen gleichen Typs zurück und
kann von diesem die Werte sehr leicht ablesen.
Wertebereich
Verwendung von XMLSchema-Sprache erlaubt eine präzise Definition von erlaubten
Werten eines jeden XML-Knoten. XMLSchema erlaubt genaue Typisierung
der Daten, Einschränkung und Erweiterung der Standardtypen wie Zahl, Text
etc. sowie Bildung komplexer Datenstrukturen. Durch entsprechende XMLSchema-
Definitionen könnte man also festlegen, welche Konfigurationsknoten welche Werte
annehmen können und somit eine Art Syntax-Überprüfung der Gesamtkonfiguration
implizit durchführen.
Integritätsschutz
Integritätsschutz der XML-Dateien kann durch digitale Signaturen dieser gewährleisten
werden. Es existieren bereits Verfahren zum Bilden und zum anschließenden
Verifizieren von digitalen Signaturen eines XML-Dokumentes.
Profil-Verwaltung
Das Problem der Profil-Verwaltung lässt sich durch Entwicklung zusätzlicher Verwaltungstools
lösen und hängt nicht vom eigentlichen Datenformat ab.
Abhängigkeiten
Datenabhängigkeiten lassen sich mit Hilfe zusätzlich definierten Metadaten auflösen.
Man könnte spezielle XML-Tags definieren, welche die Abhängigkeit(en)

14 KAPITEL 2. PROBLEMANALYSE
eines Datensatzes sowie das Verhalten des Management-Systems beim Auftreten
dieser beschreiben. Synchronisationsaktionen lassen sich dagegen komplett mit
Verwaltungstools realisieren, die dann solche Zusatzinformationen in den Metadaten
interpretieren.
2.1.2 Transformation der Daten
Konfigurationsdateien liegen normalerweise in einem lesbaren Format vor. Sei es INI-,
CSV- oder XML-Dateien, der Oberbegriff dafür lautet - Textdateien. Man braucht also
aus einer XML-Struktur (Metadaten) eine Textdatei zu erzeugen oder anders formuliert
- XML-Daten sollen in eine TEXT-Form überführt (=tranformiert) werden.
Spätestens beim Wort ”Transformieren” denkt jeder Informatiker an die XSLT-Technologie,
welche als Ziel gerade das Transformieren von XML-Dokumenten in andere Text-
Formate hat. Für Transformation von Metadaten können also entsprechende XSLT-
Transformationen definiert werden. Da es sich bei Konfigurationsdateien meistens um
Textdateien einer einfachen Form handelt, sind solche Transformationen sehr einfach
zu definieren.
2.2 Verteilungsstrategien
An dieser Stelle, an der das Format der Metadaten bereits festliegt und die allgemeine
Architektur des Systems zur Konfigurationsverwaltung bekannt ist, werden zwei
mögliche Arten der Verteilung von Konfigurationseinheiten (Dateien) analysiert.
2.2.1 Rollout
Unter dem Begriff Rollout versteht man eine Strategie zur Verteilung der Konfigurationsdateien,
bei welcher alle Dateien auf einmal erzeugt und im ganzen Systems an
die richtigen Plätze abgelegt werden. Die Gesamtkonfiguration wird quasi vom Verwaltungsmodul
ausgerollt und betrifft immer alle Knoten des Sytems (alle Konfigurationsdateien).
Das Positive an dieser Strategie ist:
• es sind keine Modifikationen der einzelnen Komponenten des Systems notwendig,
da diese wie gehabt die Konfigurationen auslesen;
• mit einer Aktion ausgehend vom Konfigurationverwaltungsmodul wird die gesamte
Konfiguration des Systems aktualisiert.
Die Strategie hat aber auch folgende Nachteile:

2.2. VERTEILUNGSSTRATEGIEN 15
• bei komplexen Systemen wie FlexiTRUST gibt es Offline-Komponenten (z.B. CA),
welche über keine Netzwerkverbindung mit anderen Komponenten verfügen. Konfigurationen
solcher Komponenten können nicht automatisch aktualisiert werden.
• Darüber hinaus ist es nicht immer möglich sicherzustellen, ob eine Aktualisierung
der Konfigurationsdaten tatsächlich erfolgte, weil manche Komponenten z.B. zum
Zeitpunkt der Aktualisierung laufen könnten und ihre Konfigurationsdateien dadurch
nicht beschreibbar wären.
• bei der Rollout-Strategie müssen zusätzliche Angaben in die Metadaten aufgenommen
werden, wie z.B. Namen und Pfade der Konfigurationsdateien, ihre
Rechte etc. Dabei erzeugt alleine die Angabe von Pfaden ein erhebliches Problem:
Diese zählen ebenso zu Konfigurationsdaten und müssen entsprechend behandelt
werden (z.B. Abhängigkeiten mit anderen Konfigurationseinheiten)
• Da das Ausrollen erst nach der Umformung der Daten zum ursprünglichen Format
erfolgt, können keine weiteren Maßnahmen zum Schutz der Datenintegrität
getroffen werden. Denn die Konfigurationsdaten liegen im Endeffekt im Klartext
vor und können evtl. nach dem Ausrollen geändert werden. Um dieses Problem
zu lösen könnte man vor jedem Systemstart einen zusätzlichen Test durchführen,
welcher ausgerollte Konfigurationsdaten nach Unversehrtheit prüft. Dies stößt
aber wiederum auf das Problem von Offline-Komponenten, bei welchen es keine
Verbindung nach draußen und somit keine Kontrolle-Möglichkeit gibt.
Allgemeiner gesehen besteht das Problem der Rollout-Strategie in der unidirektionalen
Kontrolle über die Konfigurationsdaten: In jenem Moment, in welchem Daten das
Verwaltungssystem verlassen, geht auch jegliche Kontrolle über sie verloren.
2.2.2 Request
Die Idee der Request-Verteilungsstrategie ist sehr einfach: Konfigurationseinheiten (Dateien)
werden von einzelnen Komponenten bei Bedarf angefragt und werden ihnen zur
Laufzeit zur Verfügung gestellt. Es wird vom System also ein kleines Proxy-Modul bereitgestellt,
welches Anfragen solcher Art empfängt und an den Konfigurationsdienst
weiterleitet.
Vorteile einer solchen Lösung sind:
• Integritätsschutz wird immer gewährleistet, da die Konfigurationsdaten erst bei
der Anfrage in das Originalformat konvertiert und an die jeweilige Komponenten
geschickt werden. Konfigurationsdaten können also immer signiert vorliegen und
werden bei jedem Zugriff auf Korrektheit geprüft!
• Durch beidseitige Kontrolle kann auch das Problem der Offline-Komponenten
gelöst werden, indem die Kommunikation mit dem Dienst auf einer abstrakteren
Ebene mit Hilfe von sich auf einem Datenträger befindenden Dateien darstellen
lässt.

16 KAPITEL 2. PROBLEMANALYSE
• Bei jedem Start einer Komponente kann ihr stets die aktuellste Konfiguration zur
Verfügung gestellt werden.
Als Varianten der Request-Strategie gibt es eine Online- und eine Offline-Version.
Bei der Online-Version werden einzelne Komponenten so geändert, dass sie keine Konfigurationsdateien
einlesen, sondern einen Konfigurationsstream auswerten, welchen sie
von dem Proxy bekommen. Dadurch braucht man z.B. Angaben zu Konfigurationsdateinamen,
-pfaden und -rechten nicht zu speichern, was schon einen großen Vorteil mit
sich bringt!
Möchte man keine Änderungen an den Komponenten vornehmen, so kann man die
Offline-Variante verwenden, welche einen Hybrid der Rollout- und Request-Strategie
darstellt – Konfigurationsdaten werden immer noch (bei Bedarf) angefragt, anschließend
aber von den lokal vorhandenen Proxies ausgerollt (an die richtigen Plätze gebracht).
Durch das Kombinieren dieser beiden Varianten bekommt man einen flexiblen
Mechanismus, welcher sowohl Probleme der Offline-Komponenten als auch Konfiguration
von Fremdkomponenten verwalten lässt, bei den man auf das Format und Pfad
der Konfigurationsdateien gebunden ist.

Kapitel 3
Datenmodell
In diesem Kapitel wird die Struktur der Meta-Konfiguration festgelegt. Unter Meta-
Konfiguration versteht man, wie bereits erwähnt, Konfigurationsdaten inklusive zusätzlicher
Informationen wie Wertebereiche, Kommentare, etc.
Am Anfang sollte man das allgemeine Problem der Ablageform lösen. Damit sind zwei
Varianten gemeint, um Konfigurationsdaten auf einem Datenträger abzulegen:
• Konfigurationen einzelner System-Komponenten werden in unterschiedlichen Dateien
(oder sogar Verzeichnissen) abgelegt. Die Unterteilung auf der obersten
logischen Ebene wird also dem Dateisystem überlassen.
• Alle Konfigurationsdaten aller Komponenten werden in einer globalen XML-Datei
abgelegt, welche entsprechende logische Gliederung der Datenblöcke vornimmt.
Auf den ersten Blick scheint die erste Ablageform einfacher realisierbar zu sein. Je
mehr man aber darüber nachdenkt, desto klarer wird die Tatsache, dass die erste
Einschätzung falsch ist – Man überlässt zwar eine bis zwei logischen Strukturierungsebenen
(siehe weiter unten) dem Dateisystem, bekommt dadurch aber mehr Probleme als
Vorteile, wie z.B. Verwaltung von Datei- und Verzeichnissrechten, Synchronisationsmechanismen
bei gleichzeitiger Benutzung einzelner Dateien, das Verhalten im Fehlerfall,
wenn eine oder mehrere Dateien fehlen usw.
3.1 Gliederung der Datenblöcke
Nach langer Überlegung wurde in dieser Arbeit eine Entscheidung für die zweite Ablageform
getroffen. D.h. alle Konfigurationsdaten werden in einer gemeinsamen Datei
abgelegt. Dies ist aber keine endgültige Entscheidung - im Falle einer anderen Ablageform
soll die Aufteilung in die weiter unten beschriebene logische Gliederungsebenen
auf einer anderen Weise erfolgen (siehe Kapitel 4.1 auf der Seite 35).
17

18 KAPITEL 3. DATENMODELL
Die erste logische Gliederungsebene bilden sog. Profiles. Unter einem profile versteht
man eine Konfigurationsmenge, welche ein komplettes IT-System beschreibt. So können
z.B. unterschiedliche Systeme in verschiedenen Profilen definiert und somit an einer einzigen
Stelle verwaltet werden. Es können aber auch unterschiedliche Konfigurationen eines
Systems sein, welche z.B. für verschiedene Ausführungen gedacht sind. Nimmt man
FlexiTRUST als Beispiel, so sind es unterschiedliche kundenspezifische Konfigurationen,
die die Profile bilden - ein TrustCenter mit der Chipkarten-Personalisierung und ein
nur für die Erzeugung von SoftToken ausgelegtes System, eine XEnroll-Konfiguration
für die Out-Of-The-Box-PKI etc.
XML-Ausschnitt 3.1 profile-Definition
Dies ist die Konfiguration eines
Chipkarten-Personalisierungssystems
Konfigurationsbeschreibung
weitere Profile
Das Attribut name gibt einen Namen des Profils an. Der Unterknoten description
lässt eine Profil-Beschreibung definieren.
Ein profile beinhaltet also eine komplette Konfiguration des Systems. Theoretisch
gesehen sollte es möglich sein, durch das einfache Austauschen von Profilen auf ein
anderes System, bestehend aus den gleichen Kernkomponenten, umzustellen und so
unterschiedliche Ausführungen eines Produkts (wie z.B. FlexiTRUST) zu testen oder
vorzuführen. Leider sind noch nicht alle FlexiTRUST-Komponenten in der Lage, ohne
eine Code-Änderung mit unterschiedlichen Profilen zu arbeiten. Das Ziel soll aber sein,
Komponenten zu haben, welche durch das einfache Austauschen der Konfiguration neuen
Anforderungen der Umgebung entsprechen können. Es soll also möglich sein, solche
Komponenten ohne eine einzige Code-Änderung in anderen Systemen einzusetzen.
Daraus folgt, dass das Verwaltungssystem von einem vordefinierten Profil ausgehen soll.
Wird dieses vom Administrator umdefiniert, so wird automatisch eine andere Konfiguration
zur Verfügung gestellt, ohne dass die einzelnen Komponenten etwas davon
mitbekommen.

3.1. GLIEDERUNG DER DATENBLÖCKE 19
Eine weitere logische Ebene bilden sog. applications. Ein profile besteht also aus
beliebig vielen applications, welche Konfigurationen einzelner Komponenten (Anwendungen)
repräsentieren.
XML-Ausschnitt 3.2 application-Definition
Konfiguration der LetterPrint-Komponente
Konfigurationsbeschreibung
weitere Applications
Wie beim profile-Knoten gibt das Attribut name den Namen der Application und der
Unterknoten description ihre Beschreibung an.
Da eine Komponente u.U. mehrere Konfigurationsdateien braucht, wird eine dritte Ebene
logischer Unterteilung eingeführt - Units. Hierbei handelt es sich ursprünglich um
Dateien unterschiedlichen Formats, die von einer Komponente eingelesen werden. Dies
ist z.B. bei der Komponente IS von FlexiTRUST zu sehen – es wird eine Konfigurationsdatei
namens ”
is.ini“ und eine andere namens ”
ca.xml“ verwendet.
XML-Ausschnitt 3.3 unit-Definition
Hauptkonfiguration der Komponente
Konfigurationsbeschreibung
weitere Units

20 KAPITEL 3. DATENMODELL
Genau wie bei profile und application definieren das Attribute name den Name des
Units und der Unterknoten description seine Beschreibung.
Die vierte und letzte logische Ebene bilden sog. Versions, welche inhaltlich unterschiedliche
Konfigurationsdateien gleichen Formats beschreiben. So findet man bei der IS-
Komponente aus dem letzten Beispiel mehrere Varianten von der ”
ca.xml“-Datei, für
unterschiedliche Mandantenversionen der Konfiguration (ca1001.xml, ca1012.xml, . . . )
XML-Ausschnitt 3.4 version-Definition
Vlad Satanovski, vlad.s@ervion.de
LetterPrint-Konfiguration des Mandanten 1001
Konfigurationsbeschreibung
weitere Versions
Außer dem Attribut name für den Namen des Units und des Unterknoten description
für seine Beschreibung kann man im Unterknoten author den für diesen Unit verantwortlichen
eintragen.
3.1.1 leere Ebenen
In oberen Abschnitten wurde die Komponente LetterPrint extra ausgewählt, weil bei
ihr alle logischen Konfigurationsebenen present sind. Ist gibt aber oft Komponenten,
welche ihre Konfigurationsdaten auf weniger als vier Ebenen verteilen. Dies ist der
Fall, wenn z.B. keine unterschiedlichen Versionen einer Konfiguration vorliegen (keine
mehreren versions) oder wenn eine Komponente ihre gesamte Konfiguration aus einer
Datei einliest (keine mehreren units).
In solchen Fällen darf man entsprechende Ebene aber trotzdem nicht überspringen,
weil es sonst zu unübersichtlicher Struktur der Gesamtkonfiguration führen würde.
Stattdessen definiert man einen Knoten namens ”
ccm:default-name“, was vom System
als ein unbenannter Knoten interpretiert wird. So wird eine Konfiguration mit einer
einzigen Version wie folgt definiert:

3.1. GLIEDERUNG DER DATENBLÖCKE 21
XML-Ausschnitt 3.5 leere version
Konfigurationsdaten
3.1.2 Adressierung der Dateneinheiten - CCMPath
Zur Adressierung einzelnen Konfigurationseinheiten (i.d.R. Konfigurationsdateien) wurde
ein Adressierungsformat namens CCMPath festgelegt. Hierbei werden alle vier logischen
Ebenen definiert, welche im Endeffekt zu exakt einer Konfigurationseinheit
führen.
CCMPath ::= [:][/[()]]
PROFILE ::=
APPLICATION ::= :default-name |
UNIT ::= :default-name |
VERSION ::= :default-name |
CCM-Name ::= NMToken-String (XML)
Beispielhaft zeigt ChipcardPerso:LetterPrint/config(1001) auf die bereits oben
erwähnte Konfigurationseinheit der Anwendung LetterPrint für den Mandanten 1001.
Dabei wird die Konfiguration aus dem Profil ChipcardPerso genommen.
Die CCM-Referenz ChipcardPerso:ImpEx/impex clients.xml(ccm:default-name)
zeigt auf die ImpEx-Konfigurationsdaten impex clients.xml aus dem gleichen Profil.
Hierfür gibt es keine version, daher wird ccm:default-name verwendet. Zur Vereinfachung
können solche leeren Pfadkomponenten ausgelassen werden, so dass der Pfad
ChipcardPerso:ImpEx/impex clients.xml dem ersten equivalent ist.
Profile bei Pfadangaben werden besonders behandelt. Beim Auslassen des Profilnamen
wird ein Standardprofil verwendet. Damit ist nicht das Profil mit dem Namen
ccm:default-name gemeint, sondern das im CCM-System als Standard festgelegtes Profil.
Dieser Mechanismus erlaubt bei laufenden Systemen Profile auszutauschen, ohne
dass die Systemkomponenten dafür umprogrammiert werden müssen. Daher wird an
dieser Stelle dringend empfohlen, bei allen Pfadangaben zu Konfigurationseinheiten
keinen Profilnamen explizit anzugeben. Der Pfad ImpEx/impex clients.xml verweist
zum Beispiel auf die ImpEx-Konfigurationsdatei impex clients.xml des aktuellen Profils.

22 KAPITEL 3. DATENMODELL
3.2 Konfigurationseinheiten
Erst unterhalb von versions werden eigentliche Konfigurationsdaten angegeben. Dabei
stellt man die Menge der Konfigurationsdaten als Liste von Datenelementen dar. Diese
Liste kann neben einfachen Datenknoten auch komplexe Knoten enthalten, welche
eine weitere Liste der Knoten beschreiben. Mit einem solchen Mechanismus lassen sich
sowohl flache Konfigurationsstrukturen (wie INI-Files) als auch komplexe baumartige
Strukturen (XML-Dateien) beschreiben.
XML-Ausschnitt 3.6 element-Definition
Vlad Satanovski, vlad.s@ervion.de
...
...
...
Knoteninhalt
weitere Elemente
Innerhalb eines sequence-Knotens können beliebig viele element-Knoten vorkommen,
welche die jeweiligen Konfigurationseinheiten definieren. Die Unterknoten name und
display-name geben den Namen sowie den Screennamen des Knotens an. Mit dem
Knoten description kann eine Beschreibung hinzugefügt werden. Die eigentliche Konfigurationsdaten
findet man innerhalb vom content-Knoten.
Im nächsten XML-Ausschnitt ist eine Definition eines einfachen (root-path) und eines
komplexen (logging) Konfigurationsknotens zu finden.
XML-Ausschnitt 3.7 element-Definition
Vlad Satanovski, vlad.s@ervion.de

3.2. KONFIGURATIONSEINHEITEN 23
root-path
Application’s root path
string
/usr/local/impex
logging
Log settings
path
Logfile path
string
/data/logs/impex.log
level
Log level
string
INFO
Diese Definition könnte z.B. folgende XML-Konfiguration abbilden:
/usr/local/impex
/data/logs/impex.log
INFO
Im Falle eines einfachen Knotens enthält der content-Knoten die Unterknoten type
und value, welche den Typ und den Wert des Knotens angeben. Optional kann im
Unterknoten default-value auch der Standardwert definiert werden.

24 KAPITEL 3. DATENMODELL
Wird dagegen ein komplexer Knoten beschrieben, so enthält der content einen weiteren
sequence-Knoten mit wiederum mehreren element-Knoten. Eine solche Verschachtelung
kann beliebige Tiefe aufweisen.
3.2.1 Standardtypen
Im Rahmen der Datenmodellierung wurden Standardtypen für Zeichenketten, Zahlen
und anderes definiert, welche als Werte von type-Knoten vorkommen. Durch Angabe
eines am besten passenden Typs wird der Definitionsbereich des zugehörigen Konfigurationsparameters
eingeschränkt.
Folgende Typen wurden definiert:
• string - beliebige Zeichenkette
• int - eine ganze Zahl
• boolean - ein boolescher Wert (true | false)
• float - eine Fließkommazahl
• date - ein Datum/Uhrzeit
• path - eine Pfadangabe (c:\programme\... oder /usr/local/...)
• url - eine URL (http://www.flexsecure.de/ccm/index.html)
So definiert beispielsweise folgender XML-Fragment einen Pfad zu einer Datei:
root-cert-path
Path of the root certificate
path
/usr/local/impex/etc/root.crt
3.2.2 Ableitungen der Typen
Die Standarddatentypen bilden ein Fundament für Definition neuer einfachen Datentypen.
Denn sehr oft ist es der Fall, dass man bei manchen Parametern Werte angeben
möchte, die zwar einem String ähnlich sind, aber doch einem gewissen Muster entsprechen
müssen.
Ein typisches Beispiel ist der Loglevel - es können normalerweise nur Werte DEBUG“, ”
” INFO“, ” WARNING“ und ERROR“ verwenden werden. Dies ist offensichtlich eine
”
Einschränkung des Types string, was mit folgendem XML-Ausschnitt definiert wird:

3.2. KONFIGURATIONSEINHEITEN 25
XML-Ausschnitt 3.8 Einschränkung
log-level
Log-Level
INFO
Anstatt type wird hier restriction verwendet. Das Attribute base gibt an, welcher
Standardtyp dadurch eingeschränkt wird. Es können folgende Knoten innerhalb eines
restriction-Knotens vorkommen:
list Auflistungen
Der Basistyp wird auf eine Untermenge der aufgelisteten Werten eingeschränkt.
Die Auflistung der erlaubten Werte erfolgt wie im obigen Beispiel mittels item-
Knoten, bei welchen die jeweiligen Werte durch das Attribut value angegeben
werden. Das optionale Attribute comment gibt die Möglichkeit, den zugehörigen
Wert zu kommentieren.
range Intervale
Mittels range werden dem Basistyp untere bzw. obere Grenzen gesetzt. Dazu dienen
die Attribute min und max. Im folgenden Beispiel wird ein Zahlentyp definiert,
welcher nur Werte von 0 bis 9 annehmen darf:
regex Reguläre Ausdrücke
Mit Hilfe von regex schränkt man Basistypen mittels eines regulären Ausdrucks
ein. Folgendes Beispiel definiert ein Telefonnummer-Datentyp:

26 KAPITEL 3. DATENMODELL
value Wert-Angabe
Mit value definiert man einen erlaubten Wert des Parameters. Dies gleicht einer
list-Definition mit Angabe eines einzigen item-Wertes. Das value-Tag wird
öfters als Bestandteil komplexer Ausdrücke verwendet (siehe unten).
and UND-Verknüpfung
Das Tag and erlaubt eine UND-Verknüpfung zweier logischen Ausdrücke. Ein
Parameter, welcher z.B. Zahlenwerte zwischen 1 und 5 sowie einen String-Wert
NULL“ annehmen soll, wird wie folgt beschrieben:
”
NULL
or ODER-Verknüpfung
Analog zum and bildet das or-Tag eine logische ODER-Verknüpfung zweier Ausdrücke.
Will man z.B. die Schulnoten sowohl mittels Zahlen 1 - 6 als auch mit
entsprechenden Bezeichnungen angeben können, so könnte es wie folgt aussehen:
not Verneinung
Eine Verneinung eines Ausdrucks wird mit dem not-Tag erreicht. Für Abergläubige
lässt sich z.B. der int-Basistyp auf eine Zahlenmenge ohne die ”
13“ reduzieren:
13

3.3. VERERBUNG 27
3.3 Vererbung
Eines der größten Problemen bei der Konfigurationsverwaltung stellen interne Datenabhängigkeiten
dar. Obwohl dieses Thema später noch näher betrachtet wird, muss es
hier ebenfalls erwähnt werden, weil solche Abhängigkeiten sehr oft durch Datenredundanz
entstehen. Ein Beispiel dafür:
Beispiel 2 Die FlexiTRUST-Komponenten RA, IS und ProductInspector greifen auf
eine gemeinsame Datenbank zu und tauschen somit gegenseitig Daten aus. Dies implizit,
dass die Datenbank-Konfiguration dieser Komponenten auf die gleiche Datenbank
verweisen muss. Wird die Datenbank durch eine andere ersetzt, so muss eine entsprechende
Änderung bei allen diesen Komponenten durchgeführt werden.
Durch Vererbung lassen sich solche Abhängigkeiten bereits an der Wurzel eliminieren.
Man definiert solche Konfigurationsblöcke an einer anderen Stelle und vererbt diese
an alle betroffene Konfigurationen. Bezogen auf das obere Beispiel hätte man die Datenbankkonfiguration
an einer Stelle definieren und diese dann an alle Komponenten-
Konfigurationen vererben können. Eine Änderung der Datenbank-Konfiguration wirkt
sich automatisch bei allen Konfigurationseinheiten aus.
Gerade bei einer Datenbank-Verbindung ist es so, dass die Datenbank-URL und -
Treiber konstant für alle Komponenten bleiben, die Zugangsdaten (Username, Password)
aber variieren. Um dieses Problem zu lösen können die variierende Dateneinheiten
bei der jeweiligen Komponente direkt angegeben werden, womit die vererbten
Standardwerte überschrieben werden. Die nicht neu definierten Werte bleiben dabei
aber weiterhin erhalten.
Geht man auf eine höhere Abstraktionsebene, so stellt man fest, dass manchmal komplette
Komponenten-Konfigurationen ohne jeglicher Änderung in anderen Profilen verwendet
werden. Durch Vererbung ganzer applications lässt sich auch dieses Problem
lösen.
Es wurden zwei Formen der Vererbung definiert:
• explizite Vererbung durch Verweis (sog. EQ-Vererbung) und
• implizite Vererbung durch Namensgleichheit (sog. Ref-Vererbung)
3.3.1 Ref-Vererbung
Generell kann auf den drei ersten logischen Ebenen vererbt werden:

28 KAPITEL 3. DATENMODELL
profile Profil-Vererbung
Bei einer Profile-Vererbung werden alle applications des Vater-Profils dem Kind-
Profil bekannt und können vom Letzten referenziert werden. Eine solche Vererbung
wird mittels eines Verweises im extends-Attribut des Kind-Profils definiert.
Das Profil mit dem vordefinierten Namen ”
ccm:default-name“ wird beim Vorhandensein
von allen weiteren Profilen vererbt, ohne dass dazu eine explizite
Angabe notwendig ist. Will man Vererbung eines Profils verhindern, so kann man
dies durch den Wert ”
false“ im Attribut inheritable erreichen - solche Profile
werden von anderen nicht referenziert.
XML-Ausschnitt 3.9 (Profile-Vererbung)
...
...
application Application-Vererbung
Eine Application-Vererbung ähnelt der Profil-Vererbung sehr. Dabei werden diesmal
alle units der Vater-Application an die Kind-Application weitergeleitet. Um
so eine Vererbung zu definieren verwendet man auch bei applications das Attribut
extends. Und auch hier wird die application mit dem vordefinierten
Namen ”
ccm:default-name“ automatisch von allen anderen (auch bereits vererbten)
applications vererbt. Genauso wie bei Profilen wird eine Vererbung
durch inheritable="false" verhindert.
XML-Ausschnitt 3.10 (Application-Vererbung)
...
...
unit Unit-Vererbung
Auch eine Unit-Vererbung unterscheidet sich von einer Profil- bzw. Application-
Vererbung kaum. Hier werden alle in dem Vater-Unit definierte versions an den
Kind-Unit übergeben. Zur Definition einer solchen Vererbung wird auch bei units
das Attribut extends verwendet. Die versions des units ”
ccm:default-name“
fließen automatisch in alle andere units rein. Und auch bei units kann eine
Vererbung durch Angabe von inheritable="false" verhindert werden.
XML-Ausschnitt 3.11 (Unit-Vererbung)

3.3. VERERBUNG 29
...
...
Bei einer Ref-Vererbung werden also ganze Konfigurationsabschnitte übernommen. So
werden z.B. Konfigurationen von Komponenten, welche in anderen Umgebungen (z.B.
Profilen) beschrieben wurden, in die aktuelle Umgebung aufgenommen.
3.3.2 EQ-Vererbung
Durch eine Ref-Vererbung auf einer höheren Ebene kann eine EQ-Vererbung implizit
entstehen. Dies ist der Fall, wenn bei einer Profil-Vererbung (Ref-Vererbung)
beide Profile applications gleichen Namen besitzen. Solche applications werden
übereinander gelegt und ”
gemerged“. Das Gleiche passiert auch bei einer Application-
Vererbung mit gleichnamigen units, oder bei einer Unit-Vererbung - mit gleichnamigen
versions.
Eine EQ-Vererbung hört aber auf der version-Ebene nicht auf, wie es bei einer Ref-Vererbung
der Fall ist. Beim Übereinanderlegen (mergen) von zwei Konfigurationsblöcken
werden einzelne Konfigurationseinheiten miteinander verglichen. Nimmt man das obere
Beispiel mit einer gemeinsamen Datenbank, so fließen alle vier Parameter (URL, Treiber,
Username, Password) des Vater-Knotens in den Kind-Knoten und werden hier mit
einem gleichnamigen Knoten verglichen. Gleichnamige Elemente werden durch die gleichen
des Kind-Kontens ersetzt, die nicht im Kind-Knoten vorhandene Elemente werden
hinzugefügt.
explizite EQ-Vererbung
Will man einen bestimmten element-Knoten referenzieren, welcher durch Vererbung
zwar referenzierbar ist, aber einen anderen Namen hat, so kann man dies mit dem
optionalen Tag extends innerhalb eines element tun. Dadurch lassen sich verschiedene
Vererbungsvarianten beliebig kombinieren. Dazu ein Beispiel:
Beispiel 3 In einer Umgebung werden u.a. Komponenten ProductInspector und IS
eingesetzt. Beide dieser Komponenten greifen auf dieselbe Datenbank zu, allerdings werden
dabei unterschiedliche Benutzerkennungen verwendet. Die Datenbank wird nicht
nur in dieser Umgebung verwendet, sondern auch in mehreren weiteren Testumgebungen
(Profilen).
Eine Lösung des geschilderten Problems könnte wie folgt aussehen:

30 KAPITEL 3. DATENMODELL
Abbildung 3.1: EQ-Vererbung, Elementen-Vergleich
1. Die Beschreibung der Datenbank-Konfigurationsparameter soll ausgelagert werden.
Da diese auch außerhalb der aktuellen Umgebung verwendet wird, wird sie
in dem allgemeinen Profile (der mit dem Namen ”
ccm:default-name“) definiert
(siehe Abbildung 3.2). Damit ist ein expliziter Vererbungsverweis vom aktuellen
profile nicht nötig.
Abbildung 3.2: Gesamtkonfiguration, Application-Sicht
2. Die eigentliche Datenbank-Konfiguration wird in Form eines komplexen Knotens
namens ”
db“ mit vier Unterknoten ”
url“, ”
driver“, ”
username“ und ”
password“
angegeben (siehe Abbildung 3.3).

3.3. VERERBUNG 31
3. Da die Konfigurationsparameter keinem unit oder version zugeordnet werden
können, werden diese in einer application beschrieben. Als Name dafür
wird hier Database“ gewählt. Zugehörige unit und version tragen den Namen
”
ccm:default-name“, damit die Parameter allen untergeordneten Einheiten zur
”
Verfügung stehen.
4. Die application ”
ProductInspector“ und ”
IS“ sollen von der ”
Database“ abgeleitet
sein (erben).
5.
6. In der IS-Konfiguration wird ein Element namens ”
db“ definiert, welches durch
EQ-Vererbung alle Unterknoten der Datenbank-Konfiguration besitzt (siehe Abbildung
3.4). Durch Überschreiben der Unterknoten ”
username“ und ”
password“
mit passenden Werten wird die IS-Konfiguration der Datenbankverbindung beendet.
7. Bei der ProductInspector-Konfiguration werden viele aufgabenspezifische PI-
Profile angegeben, welche evtl. mit unterschiedlichen Datenbanken operieren können.
In diesem Beispiel sollen aber alle PI-Profile auf der gleichen Datenbank
basieren, deswegen soll die Datenbank-Konfiguration geerbt werden. Dafür bekommt
jeder PI-Profil-Knoten einen Unterknoten namens ”
database“, welcher
durch eine explizite EQ-Vererbung mit der Datenbank-Konfiguration in Relation
gesetzt wird (siehe Abbildung 3.5). Eine einfache EQ-Vererbung ist an dieser
Stelle nicht möglich, da in einem solchen Fall die Datenbank-Konfiguration nur
einmal present sein würde.

32 KAPITEL 3. DATENMODELL
Abbildung 3.3: Datenbank-Konfiguration

3.3. VERERBUNG 33
Abbildung 3.4: IS-Konfiguration (EQ-Vererbung)

34 KAPITEL 3. DATENMODELL
Abbildung 3.5: PI-Konfiguration (explizite EQ-Vererbung)

Kapitel 4
Verwaltung und Verteilung der
Daten
Dieses Kapitel beschäftigt sich mit dem Problem der Verwaltung und anschließender
Verteilung der Konfigurationsdaten. Bei der Datenverwaltung müssen folgende Kriterien
erfüllt sein, damit das System als benutzbar und vertrauenswürdig sowohl im technischen
als auch im rechtlichen Sinne eingestuft werden kann. Die Konfigurationsdaten
sollen:
• leicht durch einen Administrator modifizierbar sein
• das komplette Anwendungssystem beschreiben, inklusive aller externen Anwendungen
und Schnittstellen
• vor unbefugten Modifikationen geschützt und ihre Unversehrtheit jederzeit verifizierbar
sein
4.1 Abstrakte Sicht der Daten – RAA
Trotz der Analyse und der Festlegung des Datenformats für die Konfigurationsdaten
(siehe Kapitel 3 auf Seite 17) wurde in dieser Arbeit eine entsprechende Schnittstelle
eingeführt, welche das Format der Daten abbildet. Dies ermöglicht eine spätere Erweiterung
des Datenformats oder Verwendung unterschiedlicher Formate, ohne dass die
bestehenden Anwendungen dafür modifiziert werden müssen.
Die Schnittstelle ist durch die Klasse ResourceAccessAdapter (RAA ) beschrieben. Neben
anderen abstrakten Methoden zum Erstellen oder Löschen einzelner Dateneinheiten
wurden zwei folgenden Methoden definiert:
public abstract InputStream getConfigResource(CCMPath)
public abstract void setConfigResource(CCMPath, byte[])
35

36 KAPITEL 4. VERWALTUNG UND VERTEILUNG DER DATEN
Abbildung 4.1: RemoteAccessAdapter
Die get-Methode liefert Konfigurationsdaten für den angegebenen Pfad (siehe Kapitel
3.1.2 auf Seite 21). Um Konfigurationsdaten zu speichern wird die set-Methode verwendet.
Diese erwartet zwei Parameter - den Pfad zum Ziel-Datenblock sowie eigentliche
Daten in Form eines Byte-Arrays.
4.2 Verteilung der Daten – Connections
Bei den zu verwaltenden Systemen handelt es sich meistens um verteilte Systeme. Um
Konfigurationsdaten allen Komponenten zur Verfügung zu stellen, müssen diese zwischen
den Komponenten ausgetauscht werden können, was auf folgende Weise geschehen
kann:
• mittels ”
gemounteten“ Verzeichnissen (mapped folders) innerhalb eines internen
Netzwerkes;
• über einfache Socket-Verbindungen zwischen zwei über Netzwerk erreichbaren
Rechnern;
• mit Hilfe anderer Client/Server-Technologien (wie z.B. RMI, CORBA, JINI);
• durch manuellen Datenaustausch mittels Dateien etc.
Eine abstrakte Schnittstelle einer solchen Verbindung stellt die Klasse Connection dar.
Diese Klasse definiert (neben anderen) zwei folgenden Methoden:
public abstract void send(Message)
public abstract Message receive()

4.3. DATEN-ABSICHERUNG – LSA/RSA 37
Abbildung 4.2: Connection
Dabei werden send - zum Versenden und receive - zum Empfangen einer Nachricht
verwendet.
Im Rahmen dieser Arbeit wurden folgende Varianten einer Connection implementiert:
• SocketConnection - Datenaustausch über eine Socketverbindung zwischen einer
Komponente und dem CCM-System.
• FileConnection - Datenaustausch bei Offline-Systemen. Hierbei handelt es sich
um Datenaustausch über Dateien eines speziellen Formats, welche Systemanfragen
und -antworten in zwei unterschiedlichen Warteschlangen ablegen, um eine
asynchrone Kommunikation zu erlauben. Solche Dateien können als ein virtueller
Kommunikationskanal angesehen und müssen vom Bediener manuell zwischen
den Komponenten transferiert werden.
Bei Bedarf können weitere Connection-Varianten hinzugefügt werden.
4.3 Daten-Absicherung – LSA/RSA
Mittels digitalen Signaturen kann Unversehrtheit der Konfigurationsdaten nachgewiesen
werden. In sicherheitskritischen Umgebungen sollen die Konfigurationsdaten lieber
von Administratoren nach jeder Änderung signiert abgelegt werden. Werden solche
Daten von Dritten verändert, so soll das System dies abfangen und den Administrator
darüber verständigen.
Beinhalten Konfigurationen sicherheitskritische Informationen wie z.B. Passwörter, so
sollten sie nicht nur digital signiert, sondern auch verschlüsselt abgelegt werden, damit
diese Informationen nicht im Klartext vorliegen.

38 KAPITEL 4. VERWALTUNG UND VERTEILUNG DER DATEN
Um die obigen Probleme zu lösen wurde eine Schnittstelle namens Sicherheitsadaptor
definiert, welche Ver- und Entschlüsselung, Signieren und Verifizieren geleisteter Signaturen
der Konfigurationsdaten erlaubt. Dabei werden nicht die kompletten Daten
samt Informationen über profiles, units etc., sondern nur die Inhalte der Konfigurationsblöcke
modifiziert. Bei der Entwicklung des Datenformats wurde dafür gesorgt,
dass der Inhalt des obersten Elementes einer jeden version anstatt im
Klartext mittels name- und content-Knotens auch binär angegeben werden kann.
Es wurden zwei Varianten der Sicherheitsadaptoren definiert:
• LocalSecurityAdapter (kurz LSA ) - Diese Klasse übernimmt die Aufgaben der
lokalen Absicherung der Konfigurationsdaten. Instanzen dieser Klasse werden
direkt in den ResourceAccessAdapter integriert und erlauben somit eine verschlüsselte
bzw. signierte Speicherung der Konfigurationsdaten.
• RemoteSecurityAdapter (kurz RSA )- Um auch den Datentransfer zu dem Client
zu sichern, wurde diese weitere Schnittstelle eingeführt. Sie wird an beiden Kommunikationspunkten
einer Verbindung eingesetzt, um so die Daten während der
Übertragung zu schützen.
LocalSecurityAdapter stellt u.A. folgende Methoden zur Verfügung:
public abstract InputStream getConfig(InputStream in)
public abstract void setConfig(OutputStream out, InputStream data)
Darin erkennt man Ähnlichkeit mit der Schnittstelle des ResourceAccessAdapters. Eine
entsprechende Ähnlichkeit mit dem Connection-Interface bieten auch die Schnittstellen-Methoden
des RemoteSecurityAdapters, da dieser auf eine Connection aufgesetzt
wird:
public abstract void send(Message)
public abstract Message receive()
4.3.1 Abstraktion des Schlüssel-Konzeptes
Die im oberen Abschnitt beschriebenen Sicherheitsadaptoren müssen natürlich in der
Lage sein, Daten verschlüsseln und signieren. Dazu muss intern auf asymmetrische Verschlüsselungs-
und Signaturverfahren zugegriffen werden, was wiederum Verwendung
eines Schlüsselpaars erwartet.
Da es unterschiedliche Möglichkeiten gibt, solche Schlüsselpaare zu verwalten und aufzubewahren,
wurde hier eine weitere abstrakte Schnittstelle namens Secret definiert.
Diese legt folgende Methoden fest:

4.3. DATEN-ABSICHERUNG – LSA/RSA 39
Abbildung 4.3: CCM-Sicherheitsadaptoren
public abstract X509Certificate getCertificate()
public abstract SignedData sign(byte[])
public abstract byte[] decrypt(EnvelopedData)
Beim Ergebnis des getCertificate()-Aufrufs handelt es sich um eine Instanz der Klasse
java.security.cert.X509Certificate, welche ein Benutzerzertifikat repräsentiert.
Die Klassen codec.pkcs7.SignedData und codec.pkcs7.EnvelopedData stammen
vom codec-Paket, welches von der Arbeitsgruppe des Prof. Buchmann (CDC) in Zusammenarbeit
mit der Frauenhofer Gesellschaft entwickelt wurde. Eine signierte Dateneinheit
wird durch die SignedData- und eine verschlüsselte - durch die EnvelopedData-
Klasse repräsentiert.
Es werden keine Methoden zum Verschlüsseln bzw. zum Verifizieren einer Signatur
angeboten, da solche Operationen kein Schlüsselpaar, sondern lediglich den öffentlichen
Schlüssel benötigen, welcher dem Benutzerzertifikat entnommen werden kann.
Während der Entwicklung des CCM-Systems wurden zwei Arten von Secrets implementiert,
nämlich:
• SoftTokenSecret - eine Secret-Abstraktion, welche Schlüsselpaare im PKCS#12-
Format in einer Datei erwartet und
• SmartCardSecret - eine Abbildung einer SmartCard, auf welcher das Schlüsselpaar
abgelegt wurde.
Sowohl RSA als auch LSA können mit einer Secret-Instanz initialisiert werden. Das
entsprechende Schlüsselpaar mit jeweiligen, für den Schlüsselcontainer spezifischen, Zugriffsmechanismen
wird dann bei kryptografischen Operationen verwendet.

40 KAPITEL 4. VERWALTUNG UND VERTEILUNG DER DATEN
4.4 Datentranformation – XML/INI
Die mittels Connections zugestellte Konfigurationsdaten müssen im Falle einer Roll-
Out-Zustellung anschließend in das Originalformat überführt werden. Dies wird mit
einer XSL-Transformation durchgeführt, welche als Teil der Konfigurationsdaten definiert
sein soll. Da diese Informationen nicht direkt zur Menge der Konfigurationsdaten
gehören, werden sie nicht neben anderen Daten in die Konfigurationsknoten geschrieben,
sondern müssen in einem anderen Abschnitt namens parameter definiert werden.
Solche parameter-Abschnitte können weder vererbt noch referenziert werden. Bei Vererbung
werden nur Parameter des direkt angesprochenen Knotens ausgewertet!
Neben dem Format der Originaldaten sollen auch weitere Informationen vorhanden
sein, wie z.B. Datennamen und -rechte. Solche Daten können ebenfalls als Inhalte von
parameter-Knoten beschrieben werden, welchen sie bei der Zustellung der Konfigurationsdaten
entnommen werden.
4.5 Zustellung der Konfigurationsdaten
Nachdem einzelne Elemente der Konfigurationsverwaltung angesprochen waren, wird
hier der Gesamtablauf der Zustellung von Konfigurationsdaten näher erläutert. Dabei
werden zwei bereits erwähnten Arten der Datenzustellung beschrieben - Zustellung bei
Anfrage (Request) und Zustellung per Ausrollen der Daten (Roll-Out).
4.5.1 Request
Bei einer Request-Zustellung werden Daten von der jeweiligen Anwendung des Systems
direkt angefragt. Dazu wird eine Schnittstelle namens Client verwendet, welche über
die Methode InputStream getConfiguration(CCMPath) verfügt.
Client client = Client.getInstance();
try {
// try to connect the server
client.connectServer();
}
catch (CCMPException ex) { // Unable to connect the server! }
// read the configuration of CCMPath: ImpEx/impex_clients.xml
CCMPath path = new CCMPath("ImpEx", "impex_clients.xml");
InputStream is = client.getConfiguration(path);

4.6. CCM-PROTOKOLL 41
Macht die Anwendung im CCMPath keine Angaben über die Profil-Zugehörigkeit der
Konfigurationsdaten (was im Regelfall passieren soll, vgl. Kapitel 3.1.2 auf Seite 21),
so wird vom CCM-System das Standardprofil verwendet.
Wie man sieht, besteht der eigentliche Aufruf aus drei Zeilen, in welchen die Schnittstellenklasse
Client instanziiert (Client.getInstance()) und mit dem server verbunden
wird (client.connectServer()). Anschließend wird die Konfiguration mittels
client.getConfiguration() angefragt.
Schlägt der Versuch den Server zu kontaktieren fehl (client.connectServer()), so
wird eine Warnmeldung (CCMPException) ausgegeben. In diesem Falle kann die Anwendung
entscheiden, wie sie darauf reagieren soll - ob sie mit einer Fehlermeldung
beendet wird (bei besonders sicherheitskritischen Komponenten) oder ob sie mit der
lokal gespeicherten Konfiguration weiter arbeiten soll. Wird die geworfene Exception
ignoriert, so wird eine lokal gespeicherte Kopie der Konfigurationsdaten geliefert.
Konnte eine Verbindung zum CCM-Server hergestellt werden, dann werden für die anfragende
Komponente definierte Sicherheitsadaptoren (LSA und RSA) instantiiert. Es
werden die zentral auf dem CCM-Server abgelegte Daten geladen und an den Client
geschickt. Daraufhin wird die Verbindung geschlossen.
Die neu vom Server erhaltene Daten werden mittels eines lokal definierten RAA auf
dem Zielrecher gespeichert, um im Falle eines Server-Ausfalls doch eine Zustellung
der Daten zu gewährleisten. Anschließend werden die Daten beim Vorhandensein einer
XSL-Transformation dieser unterzogen und so an die Komponente in Form eines
InputStream-Objektes gegeben.
4.5.2 Roll-Out
Eine Rollout-Zustellung der Daten unterscheidet sich von einer Request-basierten Zustellung
nur auf der Client-Seite. Hier kommt eine neue Systemkomponente namens
configTOOL zum Erscheinen, welche sowohl für Konfiguration des CCM-Systems, als
auch für Verwaltung der Konfigurationsdaten zuständig ist.
Will man bestimmte Konfigurationseinheiten ”
ausrollen“, so selektiert man diese Einheiten
im configTOOL und startet den Roll-Out-Prozess. Daraufhin fragt das config-
TOOL genau wie bei der Request-Variante nach der aktuellsten verfügbaren Konfigurationsdaten
und speichert diese mit Hilfe von definierten parameter-Knoten an die
richtigen Stellen ab. Dort werden Konfigurationsdateien von der jeweiligen Anwendung
ausgelesen, ohne dass diese verändert werden müssen.
4.6 CCM-Protokoll
Vollständigkeitshalber wird an dieser Stelle das festgelegte Protokoll des internen Datenaustausches
(CCMP ) erläutert.

42 KAPITEL 4. VERWALTUNG UND VERTEILUNG DER DATEN
Abbildung 4.4: CCM-Protokoll
Die Abbildung 4.4 zeigt schematisch den Kommunikationsdialog an. Auf der Client-
Seite kommt eine Anfrage einer Konfiguration für eine bestimmte Anwendung an. Daraufhin
ermittelt der Client eine Liste der für diese Anwendung festgelegten RSAs und
schickt diese samt dem Namen der Anwendung an den Server.
Nach dem Empfang der Anfrage ermittelt der Server den sichersten RSA aus der gelieferten
Liste, welcher gleichzeitig laut Server-Einstellungen für die genannte Anwendung
verwendet werden darf. Der Name dieses RSAs wird im Klartext an den Client zurück
geschickt.
Im nächsten Schritt instantiieren beide Seiten den gleichen RSA und können somit
weitere Kommunikation absichern. Die instantiierten RSAs führen selbsttätig eine gegenseitige
Authentisierung aus, um sicher zu stellen, dass sie tatsächlich miteinander
kommunizieren können bzw. dürfen.
Nach der Authentisierung wird vom Client der komplette CCM-Path der benötigten

4.7. GESAMTABLAUF 43
Konfiguration versendet. Mit diesen Informationen ist der Server in der Lage, alle für die
angefragte Konfiguration relevanten Daten zusammen zu stellen und in einem Bündel
an den Client zu senden.
4.6.1 ADMIN-Zugang
Eine Ausnahme bilden sog. ADMIN-Anfragen, welche von Administrationswerkzeugen
bzw. Administratoren selbst versendet werden können, um z.B. eine Sicherheitskopie
aller Daten zu erstellen, Daten verschiedener Systeme abzugleichen etc.
Der ADMIN-Zugang unterscheidet sich von einem normalen insofern, dass hierbei
stets ein bestimmter RSA eingesetzt wird, nämlich der AdminRemoteSecurityAdapter.
Um also über ADMIN-Zugang Anfragen tätigen zu können, muss man im Besitz des
ADMIN-Secrets sein, welcher in Regelfall in Form einer Chipkarte vorliegen sollte.
Aus dieser Definition folgt implizit, dass alle Konfigurationsdaten des Systems mit einem
(bzw. mehreren) solchen ADMIN-Secret sollen entschlüsselt werden können. Dies
kann man z.B. durch Einsatz von PKCS#7 als Verschlüsselungsformat realisieren, indem
das entsprechende ADMIN-Zertifikat des Secrets in die Liste der Verschlüsselungszertifikaten
mit aufgenommen wird, was spätere Entschlüsselung mit dem zugehörigen
PublicKey ermöglicht. Dieser Aspekt soll bei Entwicklung neuer RSAs unbedingt berücksichtigt
werden - Datensätze sollen stets neben eigentlichen ”
Empfängern“ auch von
ADMINs entschlüsselbar sein!
4.7 Gesamtablauf
Anschließend wird ein kompletter Ablauf einer Anfrage beschrieben. Diese Beschreibung
dient dem Zweck, alle bisher beschriebene Komponenten des CCM-Systems unter
einen Dach zu bringen und zu zeigen, wie sie alle miteinander funktionieren.
Das Gesamtschema der CCM-Architektur ist im Bild 4.5 auf Seite 46 zu sehen. Der Ablauf
wird anhand eines Beispiels erklärt, wobei zwischen den Anfragetypen (Request oder
Rollout) nicht unterschieden wird, weil die interne Kommunikation in beiden Fällen
identisch abläuft.
Beispiel 4 Anfrage der Konfigurationsdaten
CCMPath Ziel der Anfrage
Konfigurationsdaten werden durch den Pfad ImpEx/impex sequence.xml(1001)
adressiert, was soviel wie ”
impex sequence.xml für den Mandanten 1001 der
Komponente ImpEx“ bedeutet.

44 KAPITEL 4. VERWALTUNG UND VERTEILUNG DER DATEN
RAA Datenformat
Auf der Server-Seite werden Konfigurationsdaten vom File-RAA in eine gemeinsame
Datei geschrieben, der Client schreibt lokale Kopien der Daten in unterschiedlichen
Dateien ab (mittels FileSet-RAA-Klasse).
LSA lokale Absicherung der Daten
Zur Absicherung der lokal gespeicherten Konfigurationsdaten wird beim Client
der PasswordLocalSecurityAdapter und beim Server der PKILocalSecurity-
Adapter eingesetzt.
RSA Absicherung der Datenübertragung
Es seien für ImpEx zwei RSAs auf der Client-Seite (PlainRemoteSecurityAdapter
und PKIRemoteSecurityAdapter) und zwei anderen RSAs auf der Server-Seite
(PasswordRemotesecurityAdapter und PKIRemotesecurityAdapter) erlaubt.
4.7.1 Ablauf
1. Es wird versucht eine Verbindung zum Server herzustellen. (Scheitert der Versuch,
dann wird eine entsprechende Exception weitergegeben und es werden lokal
gespeicherte Daten verwendet.)
2. Der Client entnimmt den Application-Namen dem angegebenen CCMPath. Aus
der Client-Konfiguration wird eine Liste der erlaubten RSAs ermittelt. In diesem
Beispiel werden also der Name ”
ImpEx“ mit der RSA-Liste (hier - Plain- und
PKI-RSA) an den Server im Klartext versendet.
3. Server liest seine Konfiguration und holt die Liste der für diese Anwendung zugelassenen
RSAs (hier - Password- und PKI-RSA). Es wird eine Schnittmenge der
erlaubten und der gesendeten RSA-Listen ermittelt und darin der sicherste RSA
(hier also - PKIRemoteSecurityAdapter) bestimmt. Dieser Schritt gibt dem CCM-
Administrator die Möglichkeit, eine minimale Sicherheitsstufe der Kommunikationskanäle
vorzugeben, ohne dass diese von den Client-Anwendungen umgangen
werden kann.
4. Der RSA-Name (hier - PKIRemotesecurityAdapter) wird an den Client geschickt.
Daraufhin werden RSA-Instanzen auf beiden Seiten instantiiert und gegenseitig
authentisiert. Beim PKI-RSA z.B. wird die Authentisierung in Form von
Versenden zweier digital signierten Nachrichtenblöcken erreicht, was die jeweilige
Kommunikationsseite vor Authentizität der anderen überzeugt.
5. Jetzt wird der CCMPath ”
ImpEx/impex sequence.xml(1001)“ über den gesicherten
Kanal gesendet.
6. Nach Empfang der Nachricht werden vom Server die Konfigurationsdaten entsprechend
der Anfrage zusammengestellt. Dabei werden nicht nur direkt angesprochene
Datenblöcke, sondern auch die von ihnen referenzierte Blöcke mitgeschickt
(siehe 3.3 auf Seite 27). Geladen werden die Daten über den lokal spezifizierten

4.7. GESAMTABLAUF 45
RAA (hier - FileResourceAccessAdapter), wobei diese mit Hilfe vom lokalen LSA
(hier - PKILocalSecurityAdapter) entschlüsselt und verifiziert werden.
7. Client empfängt die Konfigurationsdaten und speichert diese mittels lokal definierten
RAA ab (hier - FileSetResourceAccessAdapter). An dieser Stelle werden
Daten durch den spezifizierten LSA (hier - PasswordLocalSecurityAdapter) verschlüsselt
bzw. signiert.
8. Die empfangenen Datenblöcke werden miteinander verschmolzen (gemerged), was
zu einem resultierenden Datenblock führt, welcher anschließend zurückgegeben
werden soll.
9. Wurde eine Transformation der Ergebnismenge definiert, so wird diese durch den
DataTransformer (im Bild 4.5 als DT gekennzeichnet) durchgeführt. Bei der Roll-
Out-Verteilungsstrategie werden durch die Transformation Konfigurationsdateien
generiert, welche dem Originalformat der ursprünglich von der Anwendung erwartenden
Datei entsprechen.
4.7.2 Rollout-Besonderheiten
Online-Komponenten
Wird das CCM-Modul bei Online-Systemen eingesetzt und wird dabei die Rollout-Verteilungsstrategie
verwendet, so lässt sich der Ablauf deutlich vereinfachen.
Das Ausrollen der Konfigurationsdaten, wie bereits in 4.5.2 auf Seite 41 beschrieben,
wird vom configTOOL angesteuert, welches sowohl auf der Client- als auch direkt auf
der Server-Seite ans System angeschlossen werden kann (siehe Abbildung 4.5).
Da es bei Online-Systemen immer möglich ist, Daten direkt übers Netzwerk zu versenden,
ohne auf implementierte Connection-Klassen zurückzugreifen, kann das Ausrollen
direkt von Server-Knoten aus erfolgen. In diesem Falle kommuniziert das configTOOL
direkt mit dem Server-RAA über den Admin-LSA. Die Schritte zum Herstellen einer
Verbindung sowie zum Festlegen eines RSA fallen komplett weg.
Offline-Komponenten
Das Vorhandensein von Offline-Komponenten im System lässt die Verwendung der vereinfachten
Kommunikationsversion des letzten Abschnittes trotzdem zu - Konfigurationen
aller Online-Komponenten können immer direkt vom Server aus ausgerollt werden.
Nur bei Offline-Komponenten müssen diese über das lokal auf dem Rechner installierte
configTOOL angefragt werden, was in diesem Falle eine Kommunikation über eine der
Offline-Connections (z.B. FileConnection) bedeutet. Das Ausrollen direkt vom Server
aus ist in einem solchen Fall nicht möglich, da es stets eine bestimmte Aktion auf
der Empfänger-Seite erwartet, was bei Offline-Systemen nicht möglich ist.

46 KAPITEL 4. VERWALTUNG UND VERTEILUNG DER DATEN
Abbildung 4.5: CCM-Architektur

Kapitel 5
Administrierung des CCM-Systems
Unter Administrierung des CCM-Systems verbergen sich zwei unterschiedliche Aufgaben,
nämlich:
1. Administrierung des eigentlichen CCM-Systems und ihrer Komponenten wie Client
und Server, Definition von verwendeten Connections und Sicherheitsadaptoren
u.v.m. Diese Art der Administrierung wird folglich als ”
CCM-Konfiguration“ bezeichnet.
2. Administrierung der zu verwaltenden Konfigurationsdaten des Systems (auch
Content-Administrierung“ genannt).
”
5.1 Problemanalyse
Abstrakt betrachtet lassen sich beide oben definierten Aufgaben auf das Editieren von
XML-Dateien zurückführen. Verfügt der CCM-Administrator über ausreichendes Wissen
und Erfahrung, so erweisen sich die Aufgaben sogar als recht einfach. Allerdings kann
eine Fehlkonfiguration des Systems für den Betrachter unerklärliche Folgen nach sich
ziehen, die Problembehebung kann dabei sehr viel Zeit in Anspruch nehmen. Wird das
CCM-System in Umgebungen eingesetzt, welche über keinen CCM-Administrator verfügen
oder werden Änderungen von mehreren Personen vorgenommen, so steigt das Risiko
einer Fehlkonfiguration enorm!
Ein manuelles Verändern der XML-Daten mit einem einfachen Text-Editor scheint
daher nicht die richtige Lösung zu sein. Solche Veränderungen wären sehr zeitaufwendig
und fehleranfällig. Der erste Ansatz wäre die Verwendung der bereits existierenden
Werkzeuge zum Editieren von XML-Dateien, welche zumindest Teile der Aufgaben wie
Wohlgeformtheit oder syntaktische Korrektheit des Gesamtdokumentes übernehmen.
47

48 KAPITEL 5. ADMINISTRIERUNG DES CCM-SYSTEMS
5.1.1 CCM-Konfiguration
Im Grunde genommen ist die CCM-Konfiguration nichts anderes, als eine Konfiguration
einer Systemanwendung. Es handelt sich hierbei um eine XML-Datei einer ziemlich
einfachen Struktur. Da solche Dateien aber an mehreren Stellen vorkommen können
(zum Beispiel bei Offline-Konfigurationen), wäre es sehr empfehlenswert, auch für solche
XML-Strukturen bequemere Editier-Möglichkeiten vorzusehen, als nur die Daten
direkt mit einem Text-Editor einzutragen.
Im Allgemeinen erfasst die CCM-Konfiguration folgende Einstellungen:
• Name des verwendeten RAA. Diese Einstellung bildet die physikalische Struktur
der Daten des Datenträgers auf die CCM-Datenstruktur ab.
• Liste der im System definierten Secrets, welche bei kryptografischen Operationen
verwendet werden.
• Liste der im System definierten Anwendungen, welche ihre Konfigurationen über
eine der Verteilungsstrategien übermitteln. Diese Information beinhaltet u.a. folgende
Angaben:
– Name der Anwendung in Form einer CCMPath-Angabe
– Name des zu verwendeten LSA
– Liste der für diese Anwendung zugelassenen RSAs.
– Mapping von den im System definierten Secrets auf die jeweilige Sicherheitsadaptors
5.1.2 Content-Administrierung
Die Aufgabe der Content-Administrierung besteht i.A. darin, XML-Konfigurationen
entsprechend Systemanforderungen anzupassen oder anders ausgedruckt - Konfigurationsänderungen
einzelnen Systemkomponenten vorzunehmen.
Dabei müssen u.U. viele Abhängigkeiten von anderen XML-Blöcken berücksichtigt werden.
So sind bei der Content-Administrierung folgende Probleme hervorzuheben:
• Die Lokalisierung eines bestimmten Datenblocks ist nicht immer einfach, weil im
CCM-System Konfigurationen mehrerer Anwendungen gleichzeitig verwaltet werden.
• Durch Vererbung wird Datenredundanz erheblich verringert. Dadurch werden
aber Abhängigkeiten zwischen einzelnen Konfigurationen immer komplexer. Bei
vielen Komponenten im System sind solche Abhängigkeiten oft sogar mehrstufig!
• Werden Konfigurationsdaten verschlüsselt bzw. signiert abgelegt (durch einen entsprechenden
Sicherheitsadaptor geschützt), so ist das manuelle Verändern der
Daten nicht möglich.

5.2. VERGLEICH DER EXISTIERENDEN XML-EDITOREN 49
5.2 Vergleich der existierenden XML-Editoren
In folgenden Abschnitten werden zwei XML-Editoren als Repräsentanten zweier Gruppen
der Editoren auf ihre Eignung zum Einsatz im CCM-System analysiert.
5.2.1 XMLSpy
XMLSpy ist einer der verbreitetsten und der mächtigsten XML-Editoren. Es folgt eine
kleine Liste der wichtigsten Features von XMLSpy:
• Der Benutzer wird beim Editieren durch das syntaktische Hervorheben des XML-
Tags und die Möglichkeit XML-Fragmente zusammen zu klappen unterstützt - so
können bereits bearbeitete Fragmente zu einer Zeile minimiert dargestellt werden.
• Darüber hinaus kann die Korrektheit der Datenstruktur durch externe DTD- bzw.
XMLSchema-Definitionen überprüft werden (sog. Validierung der Daten).
• Beim Vorhandensein von solchen DTD- bzw. XMLSchema-Definitionen des Dokumentes
werden Benutzereingaben durch Auswahllisten (Dropdown-Menus) mit
möglichen Parametern/Werten unterstützt und vervollständigt.
• Sowohl XSL-Transformationen der XML-Daten als auch XSL:FO werden unterstützt.
Neben den aufgelisteten Features der kostenlosen private-Version von XMLSpy verfügen
Versionen professional und enterprise über weitere mächtige Werkzeuge zum Editieren
von XML-Dateien. XMLSpy kann übers Internet bei www.xmlspy.com bezogen werden.
Die Abbildung 5.1 zeigt einen Screenshot von XMLSpy mit dem Ausschnitt der großen
CCM-Konfigurationsdatei. Der Benutzer wird zwar (wie bereits beschrieben) bei der
Eingabe der Daten unterstützt, indem mögliche Werte/TAGs entsprechend der CCM-
Schemadefinition zur Auswahl angeboten werden. Dies reicht aber für eine komfortable
Arbeit nicht aus, denn durch die großen Datenmengen in der CCM-Datei wird z.B. die
Suche nach bestimmten XML-Knoten erheblich erschwert. Außerdem müssen sehr viele
Metadaten neben eigentlichen Konfigurationsdaten mit eingegeben werden, was lange
Editierzeiten implizit.
5.2.2 XAmple
Im Gegensatz zu XMLSpy ist XAmple kein normaler, sondern ein speziell für den
Einsatz von XMLSchema-basierten XML-Dateien entwickelter Editor. Er erlaubt dem
Benutzer, XML-Dateien eines durch das XMLSchema festgelegten Formates zu generieren
bzw. zu bearbeiten. Dabei werden Daten in Form von Formular-Eingabefeldern
dargestellt und erfasst.

50 KAPITEL 5. ADMINISTRIERUNG DES CCM-SYSTEMS
Abbildung 5.1: XMLSpy
Die Bedienung von XAmple ist sehr intuitiv (siehe Abbildung 5.2). Zu Beginn wählt
man eine XMLSchema-Datei aus, welche als Basis der Daten dient. Als Nächstes kann
man eine existierende XML-Datei des ausgewählten Formats öffnen oder eine neue
anlegen. Die hierarchische Struktur des Dokumentes wird grafisch dargestellt. Daten
werden bereits während der Eingabe auf ihre Korrektheit bzgl. der Schema-Definition
überprüft.
XAmple scheint geeigneter zu sein, CCM-Konfigurationsdateien zu editieren. Durch die
grafische Abbildung von XML-Knoten als Text-Eingabefelder und automatische Validierung
der Daten während ihrer Eingabe ist man mit XAmple einen großen Schritt
weiter als mit XMLSpy, was Bedienungsfreundlichkeit bzgl. CCM-Dateien angeht.
Allerdings löst XAmple nicht alle Probleme, welche beim Editieren von CCM-Dateien
auftauchen. So ist die Suche eines bestimmten Knotens immer noch sehr Zeitaufwendig.
Außerdem werden von XAmple alle XML-Knoten des Dokumentes dargestellt,
was eigentlich beim einfachen Editieren oft überflüssig ist. Zum Beispiel bekommt eine
Liste von profiles beim XAmple ein übergeordnetes Element namens ”
array (1..unbounded
of profile)“, welches dann erst einzelne profile-Knoten enthält. Analog dazu
werden auch andere XMLSchema-Definitionen abgebildet - Wird ein complexType mit
einem eingebetteten choice-Element definiert, so erscheint das choice als ein zusätzliches
Element der Eingabemaske, wodurch alle anderen untergeordneten Elemente eine

5.3. LÖSUNGSVORSCHLAG - DAS CONFIGTOOL 51
Abbildung 5.2: XAmple
logische Stufe tiefer verschoben werden.
Dieses Verhalten mag allgemein richtig und nützlich sein, nicht aber bei festgelegten
CCM-Strukturen. Denn der Administrator muss nicht genau wissen, wie eine CCM-Datei
aufgebaut ist - es würde reichen, wenn er mit der groben Struktur vertraut ist und
bestimmte Informationen aus einer solchen Datei ablesen kann. Das Problem besteht
i.A. darin, dass der Editor keine Besonderheiten der festgelegten Struktur kennt und
deswegen auch nicht optimal eingesetzt werden kann.
5.3 Lösungsvorschlag - das configTOOL
Nach einer Analyse der vorhandenen Werkzeuge wird klar, dass ein solches System wie
CCM eine spezielle, auf ihre Bedürfnisse zugeschnittene Lösung braucht. In einer solchen
Lösung ließen sich z.B. Vorgänge wie ”
Neues Profil anlegen“, ”
Profile synchronisieren“
etc. definieren, welche im Grunde genommen nur bestimmte Manipulationen von XML-
Knoten bedeuten.
Als Prototyp einer solchen Lösung dient im Rahmen dieser Diplomarbeit entwickeltes
Werkzeug namens ”
configTOOL“. Folgendes Bild zeigt einen Screenshot von configTOOL.

52 KAPITEL 5. ADMINISTRIERUNG DES CCM-SYSTEMS
Abbildung 5.3: configTOOL
Das Hauptfenster des configTOOLs ist in drei Regionen unterteilt:
• Der Bereich Path stellt CCM-Metadaten dar. Dazu zählen profile, application,
unit und version-Angaben.
• Im Bereich Content ist die Konfigurationsdaten-Hierarchie abgebildet. Es wird
die Baumstruktur des gerade ausgewählten version-Knotens dargestellt.
• Der Bereich Properties enthält Konfigurationsdaten eines gerade ausgewählten
Elementes der Hierarchie. Hier werden alle Eigenschaften eines Elements dargestellt
und können verändert werden.
Eine solche Aufteilung in drei logische Bereiche bringt mit sich viele Vorteile. So ist
allgemein die Übersichtlichkeit und speziell die Suche nach einem konkreten Konfigurationselement
viel einfacher, weil man bei der Suche den CCMPath der Konfiguration
kennt und somit über den Path-Bereich sofort zum ”
richtigen“ Konfigurationsabschnitt
übergeht. Dieser wird im Content-Bereich in einer kompakten Form dargestellt, welche
Einzelheiten über die genaue Struktur und Typisierung der Daten verbirgt.

5.3. LÖSUNGSVORSCHLAG - DAS CONFIGTOOL 53
Auch im Falle der CCM-Administrierung bietet das configTOOL zum Teil bereits Einstellungsmöglichkeiten.
Diese sollen während bzw. nach der Einführung des CCM-Systems
weiter entwickelt werden.
Das Bild 5.4 zeigt das Dialogfenster vom configTOOL, welches über den Menüpunkt
” Repository“ - Properties“ aufgerufen wird.
”
Abbildung 5.4: configTOOL- CCM-Einstellungen
Der Dialog verfügt über fünf Seiten (Tabs), welche fünf CCM-Konfigurationsbereiche
abbilden:
Preferences - allgemeine Einstellungen von Repository-Pfaden und CCM-Logging.
Secrets - Liste der eingesetzten Secrets
Connections - Liste der verfügbaren Connections
Resource - Liste der definierten Konfigurationsresourcen, welche über entsprechende
ResourceAccessAdapter-Klassen erreichbar sind.
Applications - Liste der zugelassenen Anwendungen, welche direkte Konfigurationsanfragen
stellen dürfen.

54 KAPITEL 5. ADMINISTRIERUNG DES CCM-SYSTEMS

Kapitel 6
Ausblick
Basierend auf langjähriger Erfahrung kann man jetzt schon sagen, dass so eine komplexe
Anwendung wie das CCM nie ganz fertig implementiert werden kann. Es wird immer
wieder Verbesserungs- und Erweiterungsvorschläge geben, welche das System einerseits
weiterentwickeln, andererseits aber auch noch komplexer machen werden.
Ein paar solcher Erweiterungsmöglichkeiten werden in diesem Kapitel vorgestellt. Dabei
handelt sich um System-Erweiterungen, welche bereits in der Entwicklungsphase in
den Modellierungsprozess mit aufgenommen wurden, die aber erst nach praktischer
Erfahrung mit dem CCM-System implementiert werden können.
6.1 Abhängigkeiten
Abbildung von Abhängigkeiten zwischen einzelnen CCM-Komponenten wurde in dieser
Arbeit bereits mehrfach erwähnt. Definitionen solcher Abhängigkeiten und ihre spätere
Auflösung stellen ein weiteres design- und programmiertechnisches Problem dar.
Durch den Einsatz von Vererbungstechniken kann die Anzahl solcher system-internen
Abhängigkeiten enorm reduziert, aber leider nicht komplett eliminiert werden. Es bleiben
außerdem noch die externen Abhängigkeiten wie hardware-spezifische Konfigurationsparameter
etc.
6.1.1 Definition der Abhängigkeiten
Wie bereits in der Praktikum-Ausarbeitung [12] von Niklas Jakob und Sebastian Stark
kurz erwähnt, wurde eine XML-Struktur auf der profile-Ebene definiert, welche Definitionen
von profile-spezifischen Abhängigkeiten erlaubt. Solche Definitionen werden
innerhalb des -Knotens nach allen application’s angegeben.
Eine vollständige (Pseudo-)BNF-Grammatik solcher Definitionen befindet sich im Anhang
auf Seite 88.
55

56 KAPITEL 6. AUSBLICK
Im Allgemeinen wird eine Abhängigkeit durch drei folgenden Merkmale beschrieben:
condition - eine optionale Bedingung, bei welcher die Abhängigkeit auftritt
statement - eine Beschreibung der Abhängigkeit
action - eine Beschreibung der Vorgehensweise zur Auflösung der Abhängigkeit
Condition
Die Bedingung wird mit dem -Knoten definiert, welcher als Inhalt einen
komplexen Ausdruck haben kann. Folgendes Beispiel beschreibt die Bedingung ”
Datei
flexitrust.lck existiert“:
. . .
In einem anderen Beispiel wird überprüft, ob es sich bei der FlexiTRUST-Konfiguration
um eine Online-Variante handelt (dies ist dann der Fall, wenn alle drei Hauptkomponenten
des Systems auf dem gleichen Rechner laufen):
(RA)/IP-Adresse
(CA)/local/ip-addr
(IS)/IpAddr
. . .
Hier steht im -Knoten der CCMPath (in Klammern) gefolgt von einem
XPath-Ausdruck, welcher auf den Konfigurationsknoten unterhalb des adressierten CCM-
Blocks verweist. In diesem Beispiel wurde angenommen, dass die RA-Komponente ihre
IP-Adresse unter dem Parameternamen ”
IP-Adresse“, die CA - unter ”
local/ip-addr“
und die IS - unter ”
IpAddr“ abgelegt haben.

6.1. ABHÄNGIGKEITEN 57
Statement
Die Abhängigkeit selbst wird durch einen weiteren komplexen Ausdruck beschrieben.
Dieser wird nach dem -Knoten angegeben oder direkt als erstes Kind-
Element des -Knotens, falls für diese Abhängigkeit keine Bedingung
definierbar ist. Folgendes Beispiel zeigt eine Abhängigkeitsdefinition, welche besagt,
dass die RA- und die IS-Komponenten auf der gleichen Datenbank arbeiten sollen.
Dabei wird die Gleichheit der Datenbank durch Gleichheit des DB-Treibers sowie der
DB-URL sichergestellt.
(RA)/database/url
(IS)/db-url
(RA)/database/driver
(IS)/db-treiber
. . .
Das nächste Beispiel zeigt einen größeren XML-Fragment, welcher erst überprüft, ob
es sich um die Online-Konfiguration handelt (wie im oberen Beispiel) und dann eine
Gleichheit der Ein- und Ausgabeverzeichnissen verlangt:
(RA)/IP-Adresse
(CA)/local/ip-addr
(IS)/IpAddr
(RA)/Ausgabeverzeichnis
(CA)/dirs/p7In

58 KAPITEL 6. AUSBLICK
(CA)/dirs/p7Out
(IS)/productsDir
. . .
Action
Schließlich kommt man zur Definition einer Aktion, welche die gefundene Abhängigkeit
auflösen soll. Hierfür wird das Element definiert. Momentan wurden folgende
Arten von Aktionen spezifiziert:
synchronize - Daten werden synchronisiert.
message - es wird eine Meldung ausgegeben, der Benutzer kümmert sich um die
Auflösung der Abhängigkeit.
execute - ein Skript oder ein Programm werden zur Auflösung der Abhängigkeit aufgerufen.
Die Aktionen können einzeln oder auch in beliebiger Kombination aufgeführt werden.
Es folgt wieder ein Beispiel. Hier wird die Synchronisation der Daten als Auflösungsmethode
gewählt. Anschließend wird eine Statusmeldung ausgegeben.
. . .
Daten wurden aktualisiert
Durch die Angabe mode="update" wird mitgeteilt, dass die neuere Version der Daten
übernommen werden soll. user-confirmation="yes" erzwingt eine Benutzer-Bestätigung
des Updates.

6.2. AUTOMATISCHE INSTALLATION 59
6.1.2 Auflösung der Abhängigkeiten
An dieser Stelle würde man sich vielleicht fragen, warum all dies im Kapitel ”
Ausblick“
einer Diplomarbeit steht, wenn alles bereits so detailliert durchdacht und spezifiziert
wurde.
Dies ist deswegen der Fall, weil die eigentliche Auflösung der Abhängigkeiten programmiertechnisch
noch nicht realisiert wurde. Außerdem werden nach der Einführung des
CCM-Systems sicherlich weitere Arten von Abhängigkeiten auftauchen, welche dem Autor
während des Modellierungsprozesses nicht aufgefallen sind. Ebenso werden sich
technische Methoden zur Auflösung verschiedener Abhängigkeiten rauskristallisieren.
Außerdem ist es fraglich, ob sich alle Abhängigkeiten mit dem beschriebenen Konstrukt
definieren lassen. Momentan lassen sind Abhängigkeiten anhand folgender Merkmale
beschreiben:
• Konfigurationsparameter können mit bestimmten Werten oder mit weiteren Parametern
verglichen werden;
• Dateien können auf ihre Existenz überprüft werden, Dateirechte bz. -größen lassen
sich mit einbeziehen;
Sehr oft lassen sich komplexere Abhängigkeiten auf die eine der beiden Arten reduzieren.
So könnte Verwendung einer gemeinsamen Datenbank auf die Gleichheit zweier
Konfigurationsparameter reduziert oder das Vorhandensein einer Komponente durch
das Vorhandensein einer für diese Komponente spezifischen Datei nachgewiesen werden.
Dies wird vermutlich aber nicht immer der Fall sein. Eine reine Hardware-Überprüfung
kann z.B. mit definierten Mechanismen nicht durchgeführt werden, abgesehen von der
Möglichkeit, nach bestimmten Treibern der betroffenen Hardwarekomponente zu suchen,
welche als Nachweis des Vorhandenseins der Komponente selbst interpretiert
werden könnten.
6.2 Automatische Installation
Für Benutzer - eine Selbstverständlichkeit, für Programmierer dagegen oft extrem aufwendig
ist die Entwicklung einer Prozedur für eine automatische Installation des programmierten
Systems. Besonders bei verteilten Systemen wie FlexiTRUST, welche so
viele interne wie auch externe Abhängigkeiten haben, ist eine automatische Installation
keine Selbstverständlichkeit, sondern erweist sich immer wieder als ein langwieriger
und fehleranfälliger Prozess.
Eines der Ziele des CCM-Systems ist solche automatische Installationen zu ermöglichen.
Diese könnten dann wie folgt ablaufen:

60 KAPITEL 6. AUSBLICK
• Vor dem Installieren beim Kunden wird die Konfiguration des Systems getestet
und als CCM-Konfigurationsdatei gespeichert;
• eine Installationskomponente überträgt alle für diese Installation notwendige Programmdateien
auf den/die Rechner vom Kunden;
• die Systemkonfiguration wird mit definierten Verteilungsstrategien eingespielt;
• es wird eine Überprüfung auf Abhängigkeiten durchgeführt, welche u.U. weitere
Installationsvorgänge startet;
• anschließend wird das installierte System initialisiert, wonach optional eine weitere
Abhängigkeitsübreprüfung stattfinden könnte.
Bei der Installationskomponente wird es sich um ein Skript oder ein Programm handeln.
Daten, die die Installation beschreiben, können als Teil der CCM-Konfiguration erfasst
werden, so dass die Installationskomponente keiner besonderen Behandlung bedarf.
Um eine automatische Installation zu ermöglichen müssen alle Systemkomponenten
über eine gemeinsame Schnittstelle zum Installieren/Initialisieren verfügen. Dies muss
nicht unbedingt eine programm-technische Schnittstelle sein - u.U. reicht es aus, wenn
das CCM-System über einen entsprechenden Konfigurationsblock pro Komponente verfügen
würde, in welchem alle zur Installation notwendigen Schritte beschrieben sind.
Solche Installationsschritte sollen aber auf eine abstrakte Weise definiert werden, so
dass der Syntax eine generische/automatische Abarbeitung ermöglicht.
6.2.1 Installationsdokumentation
Die Problematik der automatischen Installation könnte auch auf eine andere Weise
gelöst werden. Werden alle Komponenten des Systems eine Installationsanleitung als
Teil der CCM-Konfiguration bereitstellen, so könnte eine komplette Anleitung zur Systeminstallation
per Knopfdruck generiert werden. So eine Anleitung würde dann neben
Anleitungen einzelner Komponenten auch eine Liste der Abhängigkeiten beinhalten,
mit Angaben zu ihrer Auflösung.
Durch den Einsatz von Vererbung und Datenstrukturierung kann die Installationsbeschreibung
komponenten- und profilspezifisch generiert werden, wobei einzelne Teile
der Beschreibung aus unterschiedlichen Konfigurationsblöcken kommen würden. Das
Gleiche betrifft auch die Abhängigkeiten.
Mit einem solchen Ausdruck in der Hand wäre eine Installation viel einfacher, weil man
die Beschreibung als eine Art Checkliste verwenden könnte. Diese Lösung könnte auch
als eine Vorstufe vor einer komplett automatischen Installation eingeführt werden, um
Erfahrungen über Installationsproblematik zu sammeln und entsprechende Techniken
zu entwickeln, welche später in der Installationskomponente realisiert werden sollten.

6.3. ERWEITERUNG ZUR FUNKTIONSBASIERTEN SICHT 61
6.3 Erweiterung zur funktionsbasierten Sicht
Die jetzige Definition von Konfigurationsparametern bildet die Gesamtkonfiguration
des Systems auf die Komponenten-Ebene ab. D.h., das System wird als eine Menge von
Komponenten angesehen.
Diese komponentenbasierte Sicht auf die Systemkonfiguration bildet das Fundament für
weitere Abstraktionen, welche komplexere Analysen des Gesamtsystems ermöglichen
sollen. So wäre eine funktionsbasierte Sicht denkbar (und sogar sehr wünschenswert!),
bei welcher nicht nach Komponenten, sondern nach Funktionen geordnet wird, die vom
System zur Verfügung gestellt werden. Folgendes Beispiel zeigt den Unterschied dieser
zweier Sichten:
FlexiTRUST Komponenten-Sicht:
Das System besteht aus folgenden Komponenten:
• RA,
• CA,
• IS,
• mySQL-DB,
• openLDAP,
. . .
FlexiTRUST Funktionen-Sicht:
Das System bietet folgende Funktionen an:
• PKCS#12,
• CRL,
• SSL,
• CSV-Import,
• PKCS#10-Import,
. . .
Dabei handelt es sich um das gleiche System. Wie man sieht, verrät die Funktionsliste
dem Endanwender viel mehr über das Gesamtsystem, als die Komponentenliste, welche
dagegen einem System-Administrator viel nützlicher erscheinen mag.
Durch eine entsprechende Erweiterung des CCM-Systems ließen sich dann Werkzeuge
entwickeln, welche ja nach Funktonsbedarf unterschiedliche Komponenten anbinden
und somit das Gesamtsystem wie aus einzelnen Bausteinen zusammensetzen. In Verbindung
mit dem Mechanismus für automatische Auflösung der Abhängigkeiten könnte
man dann Systemkonfigurationen ”
zusammenklicken“.

62 KAPITEL 6. AUSBLICK
Abbildung 6.1: Funktions- vs. Komponentensicht
6.3.1 Abbildung von Policies
Durch eine weitere Abstraktion lassen sich auch unterschiedliche Policies abbilden.
Denkbar wäre eine Schnittstelle, welche bestimmte Policy-Definitionssprachen auf entsprechende
Funktionen des Systems abbildet, die wiederum auf Komponentenebene
projiziert werden und somit eine bestimmte Komponentenmenge samt ihren Konfigurationsparametern
beschreiben.
Umgekehrt wäre es auch sehr interessant, eine bestehende Systemkonfiguration auf
Validität bzgl. bestimmten Policy-Vorgaben zu überprüfen. Eine solche Überprüfung,
die auf den ersten Blick als nicht problematisch erscheint, erweist sich leider als alles
andere als trivial. Der erste Ansatz wäre, Policy-Vorgaben bis auf die Komponentenebene
zu projizieren und anschließend das Ergebnis mit der aktuellen Konfiguration
zu vergleichen. Dieses Verfahren würde aber immer ein negatives Ergebnis liefern, weil
eine Gleichheit zweier komponenten-basierten Konfigurationen unmöglich festzustellen
wäre. Solche Konfigurationen unterscheiden sich immer, auch wenn es sich dabei nur
um verschiedene Verzeichnis- oder Benutzernamen handelt.
Erst Funktionsebenen lassen sich miteinander vergleichen. Dafür muss die Komponentenebene
auf die Funktionsebene projiziert und mit dem Ergebnis der Policy-Transformation
verglichen werden.

6.3. ERWEITERUNG ZUR FUNKTIONSBASIERTEN SICHT 63
Abbildung 6.2: Policy-Validierung

64 KAPITEL 6. AUSBLICK

66 KAPITEL 7. ZUSAMMENFASSUNG
(einfachere) Strukturen dafür zu verwenden. Dadurch wird die Konfiguration, und somit
auch die Komponente selbst, übersichtlicher und ”
sauberer“.
Das Konzept der Vererbung ist bestimmt der Kernpunkt der CCM-Architektur. Ihre Verwendung
ist nicht zwingend, aber sehr empfehlenswert. Durch die Vererbung werden
gleich mehrere Ziele erreicht. In erster Linie wird Redundanz der Konfigurationsdaten
vermieden (idealerweise sollen in der Gesamtkonfiguration gar keine Redundanzen
enthalten sein). Dadurch wird das gesamte System besser wartbar - Änderung eines
Parameters wirkt sich auf das gesamte System aus. Natürlich erfordert der Einsatz der
Vererbung mehr Zeit für Modellierung der Konfigurationsstruktur. Analog zu objektorientierter
Programmierung kann man aber sagen, dass dieser Aufwand sich mehrmals
zurück zahlen wird, wenn das System um weitere Komponenten ergänzt wird oder
größere Umstellungen vorgenommen werden.
Dadurch, dass es nun möglich ist, Konfigurationen verschiedener Projekte parallel zu
verwalten und zu verwenden sorgt das CCM-System für bessere Strukturierung der
Hauptanwendung. Ihre Kerngrößen werden zentral gespeichert, projektspezifisch werden
nur noch minimale Justierungen vorgenommen.
7.2 So geht es weiter ...
Jetzt ist das System fertig! Das heißt, die Arbeit kann beginnen! Denn fertig ist nur
die Spezifikation und die Implementierung. Als Nächstes soll das bestehende System
für CCM adoptiert werden.
Dafür soll als Erstes jemand damit beauftragt werden, sich um die zentralisierte Systemkonfiguration
zu kümmern. Denn nur so wird die Konfiguration einen ”
Rahmen“
bekommen, nur so wird sie zu einem gemeinsamen Nenner gebracht. Versuche, dieses
komplexe und flexible System dezentral zu verwalten werden scheitern!
Der Verantwortliche wählt sich eine Komponente des Gesamtsystems und versucht ihre
Konfiguration in das CCM-System einzutragen. Dafür kann entweder das implementierte
configTOOL oder ein anderer XML-Editor verwendet werden. Beim configTOOL handelt
es sich um ein Prototyp, daher wird es notwendig sein dieses zu erweitern.
Um die Konfiguration der Komponente zu adoptieren wird erst die Laufzeitumgebung
dieser analysiert. Dazu gehören Konfigurationsdateien, Skripte, Umgebungsvariablen
etc. Danach wird in der CCM-Konfiguration ein neuer application-Abschnitt angelegt,
welcher alle für diese Komponente relevanten Angaben beschreibt. Die Konfigurationsdaten
sollen dabei nach logischer Zugehörigkeit gruppiert werden, und die mehrmals
bzw. mit anderen Komponenten verwendete Parameter in einen anderen application-
Abschnitt (oder sogar einen profile-Abschnitt) ausgelagert und schließlich per Vererbung
eingebunden werden.
Als Nächstes werden XSL-Transformationen definiert, welche die neu erstellte XML-
Struktur auf die der ”
alten“ Konfigurationsdateien abbilden. Dadurch kann die Komponente
ohne jeglicher Code-Anpassung gestartet werden.

7.2. SO GEHT ES WEITER ... 67
Entscheidet man sich für eine Rollout-Lösung, dann ist man an dieser Stelle schon fertig.
Ansonsten muss die Komponente für die Request-Verteilung leicht angepasst werden.
Anschließend wird die Konfiguration der Komponente zur Verfügung gestellt (ob durch
einen Roll-Out oder durch den Start des CCM-Servers) und die Komponente getestet.
Sobald alles läuft begibt man sich in Richtung einer weiteren Komponente des Systems...

68 KAPITEL 7. ZUSAMMENFASSUNG

Anhang A
Schnittstellen
A.1 Secret
Die Klasse flexsecure.util.security.pkcs7.Secret repräsentiert ein Zertifikatbasiertes
Geheimnis mit einem dazugehörigen Mechanismus, Daten zu entschlüsseln sowie
zu signieren. Ein Objekt der Klasse wird mit der Methoden
void init(java.util.Properties)
initialisiert und stellt anschließend Methoden
codec.pkcs7.SignedData sign(byte[]) und
byte[] decrypt(codec.pkcs7.EnvelopedData)
zur Verfügung.
Mit Hilfe dieser Klasse ist es möglich, sowohl mit SoftTokens als auch auf Chipkartenbasierten
Schlüsselpaaren zu arbeiten. Beide Varianten sind in den Implementierungen
flexsecure.util.security.pkcs7.SoftTokenSecret und
flexsecure.util.security.pkcs7.SmartCardSecret
realisiert.
Beispiel 5 Dieses kurze Beispiel soll zeigen, wie die Klasse Secret verwendet werden
kann, um eine höchstmögliche Transparenz bei der Wahl des verwendeten Sicherheitstyps
(SoftToken vs. Chipkarten) zu gewinnen.
69

70 ANHANG A. SCHNITTSTELLEN
public Secret initSecret(String secretClass, Properties settings)
throws ... {
}
Secret secret = (Secret) Class.forName(secretClass).newInstance();
secret.init(props);
return secret;
// ...
EnveloperData envData = ...
Secret secret = this.initSecret(
"flexsecure.util.security.pkcs7.SmartCardSecret", settings);
byte[] plainData = secret.decrypt(envData);
// ...
byte[] toBeSignData = ...
SignedData signedData = secret.sign(toBeSignData);
// ...
A.2 RuntimeInitializable
Das Interface flexsecure.util.args.RuntimeInitializable definiert eine Schnittstelle,
welche eine Liste der zur Initialisierung der Komponente benötigten Parametern
liefert und somit die Komponente zur Laufzeit initialisieren kann. Diese Vorgehensweise
wird verwendet, um unterschiedliche Ausprägungen von definierten Modellen abhängig
von Konfigurationsdaten zu initialisieren, ohne dass man zuvor etwas über die Anforderungen
der Komponente wissen muss.
Um eine Komponente (Klasse) also zur Laufzeit initialisierbar zu machen muss diese
die Methode
flexsecure.util.args.Arguments getNeededArguments(),
implementieren, wobei die Klasse flexsecure.util.args.Argumens eine Liste der Argumenten
vom Typ flexsecure.util.args.ArgumentDescription kapselt. Bei der
Definition eines Arguments kann sein Typ (String, boolean, Dateireferenz oder Password)
angegeben werden. Außerdem können auch optionale Argumente definiert werden.
Ein besonderer Merkmal dieser Implementierung besteht darin, dass somit nicht definierte
aber zur Initialisierung einer Komponente notwendige Parameter zur Laufzeit
erfragt werden können. Man denke dabei z.B. an Passwörter etc.
Beispiel 6 In diesem Beispiel soll demonstriert werden, wie die oben besprochene
Schnittstelle verwendet werden kann.

A.2. RUNTIMEINITIALIZABLE 71
public class MyClass implements RuntimeInitializable {
// ...
Properties params = new Properties();
// Parameters
private boolean a;
private String b; // Passwort
private String c;
// Getter-/Setter Methoden
public boolean getA(){ return this.a; }
public void setA(boolean a){ this.a = a; }
public String getB(){ return this.b; }
public void setA(String b){ this.b = b; }
public String getC(){ return this.c; }
public void setC(String c){ this.c = c; }
// RuntimeInitializable Funktionalität
public Arguments getNeededArguments() throws ... {
Arguments args = new Arguments();
/*
* zu jedem Parameter werden seinen Namen, Typ, sog. Displaynamen,
* Namen der get-/set-Methoden sowie einen boolean-Werte für
* Erforderlichkeit dieses Parameters angegeben
*/
args.addArgumentDescription("a", ArgumentDescription.TYPE_BOOLEAN,
"Parameter A", "getA", "setA", true);
args.addArgumentDescription("b", ArgumentDescription.TYPE_PASSWORD,
"Parameter B", "getB", "setB", true);
args.addArgumentDescription("c", ArgumentDescription.TYPE_STRING,
"Parameter C", "getC", "setC", false);
}
return args;
// Hauptprogramm
public static void main(String[] args){
MyClass myClass = new MyClass(...);
// params aus dem Configfile laden
params.load(...);
// auf Vollständigkeit überprüfen
Arguments arg = myClass.getNeededArguments();
arg.init(myClass);

72 ANHANG A. SCHNITTSTELLEN
String[] names = arg.getArgumentNames();
for (int i = 0; i < names.length; i++) {
String argName = names[i];
ArgumentDescription argDescr = arg.getArgumentDesciption(argName);
String value = params.getProperty(argName);
if (value == null) {
// Parameter nicht definiert ...
if (argDescr.isRequired()) {
// Parameter erforderlich, Wert erfragen ...
switch (argDescr.getType()) {
case ArgumentDescription.TYPE_STRING :
// String erfragen
value = ...
case ArgumentDescription.TYPE_BOOLEAN :
// boolean erfragen
value = ...
case ArgumentDescription.TYPE_FILE :
// Dateireferenz erfragen
value = ...
case ArgumentDescription.TYPE_PASSWORD :
// Passwort erfragen
value = ...
}
}
// Wert setzen
arg.set(argName, value);
}
// Klasse initialisieren
myClass.update(arg);
}
// ...
A.3 ResourceAccessAdapter
Das Konzept des Zugriffs auf die Konfigurationsdaten ist durch die Schnittstelle
de.flexsecure.ccm.raa.ResourceAccessAdapter
gegeben. Diese definiert mehrere Methoden, welche den Zugriff auf Konfigurationsdaten
erlauben und Änderungen an diesen vornehmen. Zwei wichtigste Methoden sind dabei
java.io.InputStream getResource(CCMPath path) und
void setResource(CCMPath path, byte[] resource)

A.4. CONNECTION 73
Beide Methoden erwarten einen Parameter vom Typ CCMPath, welcher den logischen
Pfad der Konfigurationseinheit bestimmt. Eine Konfigurationseinheit wird von der
getResource()-Methode in Form eines InputStreams zurückgegeben. Geschrieben wird
eine Einheit durch den Aufruf der setResource()-Methode, welche die Daten in Form
eines Byte-Arrays erwartet.
Die Schnittstelle ResourceAccessAdapter erlaubt es, mehrere Varianten der Datenaufteilung
des Systems parallel zu verwenden, ohne dass die restlichen CCM-Mechanismen
modifiziert werden müssen. So wurden im Rahmen dieser Arbeit zwei Referenzimplementierungen
realisiert:
• FileSetResourceAccessAdapter – diese Klasse bildet Konfigurationseinheiten
auf einzelne Dateien ab, gruppiert durch das ”
einfache“ Verzeichnissstruktur der
Festplatte.
• FileResourceAccessAdapter – bei dieser Klasse wird eine einzelne XML-Datei
für Speicherung der gesamten Systemkonfiguration verwendet. Die Unterteilung
in Profiles, Application etc. wird durch interne XML-Strukturierung dieser
Datei realisiert.
Um maximale Flexibilität zu gewährleisten implementieren alle Klassen des Interfaces
die bereits in A.2 beschriebene RuntimeInitializable-Schnittstelle.
A.4 Connection
Für eine saubere Trennung zwischen dem CCM-Client und dem CCM-Server sorgt die
eingeführte Schnittstelle
de.flexsecure.ccm.connection.Connection
Eine jede Implementierung dieser Schnittstelle muss folgende Methoden beschreiben:
void init(List params)
wird zur Initialisierung einer Connection verwendet,
void send(Message req) und
Message receive()
empfangen und versenden Nachrichten,
void startServer() und
void acceptConnection()

74 ANHANG A. SCHNITTSTELLEN
starten den Server und reagieren auf die ankommende Verbindungsanfragen (Serverseitig),
void connectServer()
stellt eine Verbindung mit dem Server her (Client-seitig) und
void close()
schließt eine Verbindung.
Folgende Connection-Implementierungen wurden im Rahmen der Arbeit realisiert:
• SockerConnection – diese Klasse stellt eine Connection über Sockets dar. Dies
ist der Standardfall beim CCM-System.
• FileConnection – diese Connection-Art ermöglicht eine Anbindung von physikalisch
getrennten Komponenten (wie z.B. die Offline-CA). Bei der FileConnection
werden alle Nachrichten nicht über Netzverbindungen übertragen, sondern in speziellen
Dateien abgelegt. Durch Austausch solcher Dateien lässt sich eine Kommunikation
zwischen nicht miteinander verbundenen Komponenten simulieren.
A.5 LocalSecurityAdapter
Das LocalSecurityAdapter-Interface übernimmt die Aufgabe, den Datentransfer zwischen
der Anwendung und dem lokalen Datenträger (Festplatte) zu schützen sowie
Datenintegrität zu gewährleisten.
Neben einer init-Methode zum Initialisieren stellt die Schnittstelle lediglich zwei weiteren
Methoden zur Verfügung:
java.io.InputStream getConfig(java.io.InputStream in) und
void setConfig(java.io.OutputStream out, java.io.InputStream data)
Dabei liefert die getConfig()-Methode Daten vom lokalen Datenträger (und entschlüsselt
diese ggf.). Die setConfig()-Methode schreibt die ”
Plaintext“ Daten auf
die Festplatte (und verschlüsselt bzw. signiert sie dabei).
Die LocalSecurity-Adaptoren werden nie direkt von einer Anwendung verwendet. Diese
werden in den jeweils verwendeten ResourceAccessAdapter integriert und überwachen
den Datenstrom von und zu der Festplatte.
Im Rahmen dieser Arbeit wurde nur eine einfache Variante des Adapters implementiert:

A.6. REMOTESECURITYADAPTER 75
• PlainLocalSecurityAdapter – dieser Adaptor verändert die Daten nicht, sondern
leitet sie einfach weiter.
Eine Implementierung eines Adaptors, welcher Daten verschlüsselt bzw. signiert speichert
und anschließend wieder entschlüsselt bzw. Signatur verifiziert, wäre denkbar und
würde kein Problem darstellen, weil diese Techniken bereits an anderen Stellen (siehe
A.6) zum Einsatz kamen.
A.6 RemoteSecurityAdapter
Analog zum LocalSecurityAdapter dient die Schnittstelle RemoteSecurityAdapter
der Datensicherung. Diesmal aber ist die Sicherung der Datenübertragung über aufgebaute
Connections gemeint. Entsprechend bauen Realisierungen dieser Schnittstelle
nicht auf einem ResourceAccessAdapter, sondern auf einer Connection auf. Aus diesem
Grund müssen hier andere Methoden implementiert werden.
Die zwei wichtigsten Methoden sind
void send(Message req) und
Message receive(),
welche das Versenden und Empfangen von Nachrichten zur Aufgabe haben. Bei diesen
Schritten können Daten durch Verschlüsselung/Signatur geschützt und völlig transparent
für die dahintersteckende Connection übertragen werden.
Um einen sicheren Kommunikationskanal aufbauen zu können müssen sich Client und
Server erst gegenseitig authentisieren. Diese Aufgabe übernehmen die beiden weiteren
Methoden:
void authenticate SSide() und
void authenticate CSide(),
wobei der Suffix ”
SSide“ für die Server-seitige und ”
CSide“ - für die Client-seitige
Authentisierungsprozedur stehen. In dieser Arbeit wurde nicht spezifiziert, wie eine
Authentisierung genau erfolgen soll - dies sei der jeweiligen Implementierung überlassen.
Drei Referenzimplementierungen wurden entwickelt:
• PlainRemoteSecurityAdapter – analog zu der ”
Plain“-Variante des lokalen Adapters
leitet diese Implementierung alle Messages weiter, ohne irgendwelche Änderungen
an versendeten Daten vorzunehmen
• PKIRemoteSecurityAdapter – diese Klasse implementiert einen verschlüsselten
und signierten Datenaustausch, basierend auf dem Secret-Konzept (siehe dazu
A.1)

76 ANHANG A. SCHNITTSTELLEN
• AdminRemoteSecurityAdapter – dies ist die PKI-Variante des Adaptors, welche
bei Admin-Anfragen eingesetzt wird. Der einzige Unterschied besteht in der
internen Verwaltung von Systemzertifikaten.

Anhang B
Datenmodell
B.1 Schema-Definition
Nachfolgend sind Meta-Definitionen für CCM-Konfigurationseinheiten schematisch abgebildet.
Anschließend folgt die XMLSchema-Definition der Dateistruktur.
77

78 ANHANG B. DATENMODELL
< xsd:schema xmlns:xsd =" http: // www .w3.org /2001/ XMLSchema " xmlns:ccm =" http: // www .
flexsecure .de/ccm " xmlns:xsl =" http: // www .w3.org /1999/ XSL / Transform "
targetNamespace =" http: // www . flexsecure .de/ccm ">
< xsd:element name =" config " type =" ccm:configType "/>
< xsd:complexType name =" configType ">
< xsd:sequence >
< xsd:element name =" profile " type =" ccm:profileType " maxOccurs =" unbounded "/>
< xsd:complexType name =" profileType ">
< xsd:sequence >
< xsd:element name =" description " type =" xsd:string " minOccurs ="0"/>
< xsd:element name =" application " type =" ccm:applicationType " maxOccurs ="
unbounded "/>
< xsd:element name =" dependency " type =" ccm:dependencyType " minOccurs ="0"/>
< xsd:element name =" parameter " type =" ccm:parameterType " minOccurs ="0"
maxOccurs =" unbounded "/>
< xsd:attribute name =" name " type =" xsd:string " use =" required "/>
< xsd:attribute name =" extends " type =" xsd:string "/>
< xsd:attribute name =" inheritable " type =" xsd:boolean "/>
< xsd:complexType name =" applicationType ">
< xsd:sequence >
< xsd:element name =" description " type =" xsd:string " minOccurs ="0"/>
< xsd:element name =" unit " type =" ccm:unitType " maxOccurs =" unbounded "/>
< xsd:element name =" parameter " type =" ccm:parameterType " minOccurs ="0"
maxOccurs =" unbounded "/>
< xsd:attribute name =" name " type =" xsd:string " use =" required "/>
< xsd:attribute name =" extends " type =" xsd:string "/>
< xsd:attribute name =" inheritable " type =" xsd:boolean "/>
< xsd:complexType name =" unitType ">
< xsd:sequence >
< xsd:element name =" description " type =" xsd:string " minOccurs ="0"/>
< xsd:element name =" version " type =" ccm:versionType " maxOccurs =" unbounded "/>
< xsd:element name =" parameter " type =" ccm:parameterType " minOccurs ="0"
maxOccurs =" unbounded "/>
< xsd:attribute name =" name " type =" xsd:string " use =" required "/>
< xsd:attribute name =" extends " type =" xsd:string "/>
< xsd:attribute name =" inheritable " type =" xsd:boolean "/>
< xsd:complexType name =" versionType ">
< xsd:choice >
< xsd:sequence >
< xsd:element name =" description " type =" xsd:string " minOccurs ="0"/>
< xsd:element name =" author " type =" xsd:string " minOccurs ="0"/>
< xsd:element name =" sequence " type =" ccm:sequenceType " minOccurs ="0"/>
< xsd:element name =" parameter " type =" ccm:parameterType " minOccurs ="0"
maxOccurs =" unbounded "/>
< xsd:sequence >
< xsd:any processContents =" skip " minOccurs ="0"/>
< xsd:attribute name =" name " type =" xsd:string " use =" required "/>
< xsd:attribute name =" inheritable " type =" xsd:boolean "/>

B.1. SCHEMA-DEFINITION 79
< xsd:complexType name =" parameterType ">
< xsd:sequence >
< xsd:any processContents =" skip " minOccurs ="0" maxOccurs =" unbounded "/>
< xsd:attribute name =" type " type =" xsd:string "/>
< xsd:complexType name =" sequenceType ">
< xsd:sequence >
< xsd:element name =" element " type =" ccm:elementType " maxOccurs =" unbounded "/>
< xsd:complexType name =" elementType ">
< xsd:sequence >
< xsd:element name =" name " type =" xsd:string "/>
< xsd:choice >
< xsd:sequence >
< xsd:element name =" display - name " type =" xsd:string " minOccurs ="0"/>
< xsd:element name =" description " type =" xsd:string " minOccurs ="0"/>
< xsd:element name =" content " type =" ccm:contentType "/>
< xsd:sequence >
< xsd:element name =" extends " type =" xsd:string "/>
< xsd:element name =" content " type =" ccm:contentType " minOccurs ="0"/>
< xsd:attribute name =" identifier " type =" xsd:boolean " use =" optional "/>
< xsd:complexType name =" contentType ">
< xsd:choice >
< xsd:sequence >
< xsd:element name =" sequence " type =" ccm:sequenceType "/>
< xsd:sequence >
< xsd:choice >
< xsd:element name =" type " type =" ccm:baseType "/>
< xsd:element name =" restriction " type =" ccm:typeType "/>
< xsd:element name =" value " type =" xsd:string "/>
< xsd:element name =" default - value " type =" xsd:string " minOccurs ="0"/>
< xsd:group name =" elementGroup ">
< xsd:choice >
< xsd:element name =" value " type =" xsd:string "/>
< xsd:element name =" and " type =" ccm:andorType "/>
< xsd:element name ="or" type =" ccm:andorType "/>
< xsd:element name =" not " type =" ccm:notType "/>
< xsd:element name =" range " type =" ccm:rangeType "/>
< xsd:element name =" list " type =" ccm:listType "/>
< xsd:element name =" regex " type =" ccm:regexType "/>
< xsd:complexType name =" typeType ">
< xsd:group ref =" ccm:elementGroup " minOccurs ="0"/>
< xsd:attribute name =" base " type =" ccm:baseType " use =" required "/>
< xsd:simpleType name =" baseType ">

80 ANHANG B. DATENMODELL
< xsd:restriction base =" xsd:string ">
< xsd:enumeration value =" string "/>
< xsd:enumeration value =" int "/>
< xsd:enumeration value =" boolean "/>
< xsd:enumeration value =" float "/>
< xsd:enumeration value =" date "/>
< xsd:enumeration value =" path "/>
< xsd:enumeration value =" url "/>
< xsd:complexType name =" rangeType ">
< xsd:attribute name =" min " type =" xsd:string " use =" optional "/>
< xsd:attribute name =" max " type =" xsd:string " use =" optional "/>
< xsd:complexType name =" listType ">
< xsd:sequence >
< xsd:element name =" item " type =" ccm:itemType " maxOccurs =" unbounded "/>
< xsd:complexType name =" itemType ">
< xsd:attribute name =" value " type =" xsd:string " use =" required "/>
< xsd:attribute name =" comment " type =" xsd:string " use =" optional "/>
< xsd:complexType name =" regexType ">
< xsd:attribute name =" value " type =" xsd:string " use =" required "/>
< xsd:attribute name =" comment " type =" xsd:string " use =" required "/>
< xsd:complexType name =" andorType ">
< xsd:sequence >
< xsd:group ref =" ccm:elementGroup " minOccurs ="2" maxOccurs ="2"/>
< xsd:complexType name =" notType ">
< xsd:sequence >
< xsd:group ref =" ccm:elementGroup "/>
< xsd:group name =" dependencyGroup ">
< xsd:choice >
< xsd:element name =" and " type =" ccm:dAndOrType "/>
< xsd:element name ="or" type =" ccm:dAndOrType "/>
< xsd:element name =" not " type =" ccm:dNotType "/>
< xsd:choice maxOccurs =" unbounded ">
< xsd:element name =" equals " type =" ccm:equalsType "/>
< xsd:element name =" greater " type =" ccm:lgType "/>
< xsd:element name =" less " type =" ccm:lgType "/>
< xsd:element name ="in" type =" ccm:inType "/>
< xsd:element name =" file " type =" ccm:fileType "/>
< xsd:complexType name =" dependencyType ">
< xsd:sequence >
< xsd:element name =" condition " type =" ccm:conditionType " minOccurs ="0"/>
< xsd:group ref =" ccm:dependencyGroup "/>
< xsd:element name =" action " type =" ccm:actionType "/>
< xsd:attribute name =" name " type =" xsd:string " use =" optional "/>

B.1. SCHEMA-DEFINITION 81
< xsd:complexType name =" conditionType ">
< xsd:group ref =" ccm:dependencyGroup "/>
< xsd:complexType name =" dAndOrType ">
< xsd:group ref =" ccm:dependencyGroup " minOccurs ="2" maxOccurs =" unbounded "/>
< xsd:complexType name =" fileType ">
< xsd:choice maxOccurs =" unbounded ">
< xsd:element name =" exists "/>
< xsd:element name =" version " type =" ccm:MinMaxEqType "/>
< xsd:element name =" filesize " type =" ccm:MinMaxEqType "/>
< xsd:element name =" date " type =" ccm:MinMaxEqType "/>
< xsd:attribute name =" name " type =" xsd:string "/>
< xsd:complexType name =" MinMaxEqType ">
< xsd:attribute name =" min " type =" xsd:string "/>
< xsd:attribute name =" max " type =" xsd:string "/>
< xsd:attribute name =" equals " type =" xsd:string "/>
< xsd:complexType name =" dNotType ">
< xsd:group ref =" ccm:dependencyGroup "/>
< xsd:group name =" paramGroup ">
< xsd:choice >
< xsd:element name =" xpath - value " type =" xsd:string "/>
< xsd:element name ="expr - value " type =" xsd:string "/>
< xsd:element name =" system - property " type =" xsd:string "/>
< xsd:complexType name =" equalsType ">
< xsd:group ref =" ccm:paramGroup " minOccurs ="2" maxOccurs =" unbounded "/>
< xsd:complexType name =" lgType ">
< xsd:group ref =" ccm:paramGroup " minOccurs ="2" maxOccurs ="2"/>
< xsd:complexType name =" inType ">
< xsd:sequence >
< xsd:group ref =" ccm:paramGroup "/>
< xsd:element name =" set " type =" ccm:setType "/>
< xsd:complexType name =" setType ">
< xsd:group ref =" ccm:paramGroup " maxOccurs =" unbounded "/>
< xsd:complexType name =" actionType ">
< xsd:choice maxOccurs =" unbounded ">
< xsd:element name =" synchronize " type =" ccm:synchronizeType "/>
< xsd:element name =" message " type =" xsd:string "/>
< xsd:element name =" execute " type =" xsd:string "/>
< xsd:complexType name =" synchronizeType ">
< xsd:attribute name =" mode " type =" ccm:upresType " use =" optional "/>
< xsd:attribute name ="user - confirmation " type =" ccm:uConfType " use =" optional "/
>
< xsd:simpleType name =" upresType ">
< xsd:restriction base =" xsd:string ">

82 ANHANG B. DATENMODELL
< xsd:enumeration value =" update "/>
< xsd:enumeration value =" reset "/>
< xsd:simpleType name =" uConfType ">
< xsd:restriction base =" xsd:string ">
< xsd:enumeration value =" yes "/>
< xsd:enumeration value ="no"/>
B.2 Beispiel-Konfiguration
In diesem Abschnitt wird eine CCM-Beispilkonfiguration vorgestellt. Sie stellt alle entwickelten
und besprochenen Konstrukte der CCM-Architektur dar und gibt somit eine
Möglichkeit, Ziele dieser Kontrukte besser definieren zu können.
Die Konfiguration besteht aus fünf Profilen. Im Default-Profil werden zwei abstrakte
Konstrukte für eine Datenbankverbindung sowie eine Chipkarten-Konfiguration definiert.
Diese werden von allen anderen Profilen automatisch vererbt.
Im Profil Env-1 werden zwei Applications definiert (ProductInspector und IS), welche
von der default application per Ref-Vererbung die Datenbank-Eigenschaften vererben
und die Konfigurationswerte username und password überschreiben.
Im Profil Env-2 werden alle Env-1-Eigenschaften vererbt. Eine neue application RA
definiert dabei wie im Profil Env-1 die Werte für den Datenbankzugang neu. Dagegen
vererbt die ProductInspector-application per EQ-Vererbung alle Eigenschaften
der gleichnamigen Anwendung aus dem Env-1-Profil, definiert aber Dateirechte der zu
erzeugenden Konfigurationsdatei pi.ini.
Profil Env-3 erbt von Env-2 und stellt somit folgende Applications zur Verfügung:
• Database
• SmartCard
• ProductInspector
• IS
• RA
Die hier neu definierte Application Kobil beschreibt Konfigurationsdaten der Datei
smartkey.inf der Kobil-Umgebung (Chipkarten-Anwendungen) und erbt dafür von der
SmartCard-application. Die RA ergänzt hier aber nur vom Env-2 übernommene Konfiguration.
Zum Schlüß ergänzt das Profil Env-4 beide letzten Profile und überschreibt dabei Konfigurationsdaten
von applications ProductInspector und Kobil.

B.2. BEISPIEL-KONFIGURATION 83
< ccm:config xmlns:x0 =" http: // www .w3.org /2001/ XMLSchema " xmlns:ccm =" http: // www .
flexsecure .de/ccm " xmlns:xsl =" http: // www .w3.org /1999/ XSL / Transform "
xmlns:xsi =" http: // www .w3.org /2001/ XMLSchema - instance " xsi:schemaLocation ="
http: // www . flexsecure .de/ccm
configSchema . xsd ">
< profile name =" ccm:default - name ">
< application name =" Database ">
< description > Database settings
< version name =" ccm:default - name ">
< sequence >
< element >
db
Database settings
< content >
< sequence >
< element >
url
Database - URL
< content >
url
jdbc:mysql: // localhost / flexitrust
< element >
driver
Database - Driver
< content >
string
org . gjt .mm. mysqk . Driver
< element >
username
Database - Username
< content >
string
test
< element >
password
Database - Password
< content >
string
test
< application name =" SmartCard ">
< version name =" ccm:default - name ">
< sequence >
< element >
smartkey
< content >
< sequence >
< element >
port

84 ANHANG B. DATENMODELL
< content >
int
1
1
< element >
ctapi - dll
< content >
path
C:\ WINNT \ system32 \ CT32 . dll
< element >
application
< content >
< sequence >
< element identifier =" true ">
name
< content >
string
BEDIENER SIGNATUR ZERTIFIKAT !!!
< element >
Application
< content >
string
0 xD2 0 x76 0 x00 0 x00 0 x03 0 x01 0 x02
< element >
Certificate
< content >
string
0 x43 0 x31
< element >
Modulus
< content >
string
0 x45 0 x31
< element >
Key Number
< content >
string
0 x00
< element >
options
< content >
string
SIGN_ONLY
< element >
application
< content >

B.2. BEISPIEL-KONFIGURATION 85
< sequence >
< element identifier =" true ">
name
< content >
string
Netkey Verschlüsselungs - Zertifikat
< element >
Application
< content >
string
0 xD2 0 x76 0 x00 0 x00 0 x03 0 x01 0 x02
< element >
Certificate
< content >
string
0 x43 0 xB1
< element >
Modulus
< content >
string
0 x45 0 xB1
< element >
Key Number
< content >
string
0 x01
< element >
PUK
< content >
string
0 x08
< profile name ="Env -1">
< application name =" ProductInspector " extends =" Database ">
< description > PriductInspector
< version name =" ccm:default - name ">
< sequence >
< element >
profile
Profile
< content >
< sequence >

86 ANHANG B. DATENMODELL
< element >
database
< extends >db
< content >
< sequence >
< element >
username
< content >
string
revokator2
< element >
password
< content >
string
pass
< parameter type =" exporter ">
pi.ini
rw -r--r--
flexitru:tomcat
< parameter type =" formatter ">
< xsl:stylesheet >
DB_url =
DB_driver =
DB_user =
DB_pass =
< application name ="IS" extends =" Database ">
< version name =" ccm:default - name ">
< sequence >
< element >
db
< content >
< sequence >
< element >
username
< content >
string
isuser
< element >
password
< content >
string

B.2. BEISPIEL-KONFIGURATION 87
ispass
< profile name ="Env -2" extends ="Env -1">
< application name =" ProductInspector ">
< description > PriductInspector
< version name =" ccm:default - name ">
< parameter type =" exporter ">
pi.ini
rw -r--r--
flexitru:tomcat
< parameter type =" formatter ">
< xsl:stylesheet >
DB_url =
DB_driver =
DB_user =
DB_pass =
< application name ="RA" extends =" Database ">
< version name =" ccm:default - name ">
< sequence >
< element >
db
< content >
< sequence >
< element >
username
< content >
string
isuser
< element >
password
< content >
string
ispass
< profile name ="Env -3" extends ="Env -2">

88 ANHANG B. DATENMODELL
< application name ="RA">
< version name =" ccm:default - name ">
< application name =" Kobil " extends =" SmartCard ">
< version name =" ccm:default - name ">
< profile name ="Env -4" extends ="Env -1 , Env -3">
< application name =" ProductInspector ">
< description > PriductInspector
< version name =" ccm:default - name ">
< parameter type =" exporter ">
pi.ini
rw -r--r--
flexitru:tomcat
< parameter type =" formatter ">
< xsl:stylesheet >
DB_url =
DB_driver =
DB_user =
DB_pass =
< application name =" Kobil ">
< version name =" ccm:default - name ">
< sequence >
< element >
port
< content >
int
2
B.3 Abhängigkeitsdefinitionen
Nachfolgend findet man eine Pseudo-Grammatik von Definitionen der Abhängigkeiten.
Ihre Verwendung ist im Abschnitt 6.1 auf Seiten 55ff. beschrieben.
DEPENDENCY ::= < dependency [ name = STRING ]> [ COND ] STAT ACTION
COND ::= < condition > STAT
STAT ::= ( AGGR | EXPR ) [ STAT ]

B.3. ABHÄNGIGKEITSDEFINITIONEN 89
AGGR ::= AND | OR | NOT
AND ::= EVENT EVENT [ EVENT ...] | AGGR
OR ::= EVENT EVENT [ EVENT ...] | AGGR
NOT ::= EVENT | AGGR
EVENT ::= " STAT " | " ACT "
EXPR ::= EQ | GT | LT | IN | FILE
EQ ::= < equals > PARAM PARAM [ PARAM ...]
GT ::= < greater > PARAM PARAM
LT ::= PARAM PARAM
IN ::= PARAM SET
SET ::= [ PARAM ...]
FILE ::= [ PARAM ...]
PARAM ::= PATH - VALUE | EXPR - VALUE | PROPERTY
PATH - VALUE ::= CCM - PATH /X- PATH
EXPR - VALUE ::= MATH - EXPR | STRING
PROPERTY ::= STRING
CCM - PATH ::= ( MODULE [, PROFILE [, CONFIG - NAME [, VERSION ]]])
MODULE ::= STRING
PROFILE ::= STRING
CONFIG - NAME:: = STRING
VERSION ::= STRING
X- PATH ::= STRING
MATH - EXPR ::= STRING
ACTION ::= < action > AGGR | ACT
ACT ::= SYNC | MSG | EXEC
SYNC ::= < synchronize [ mode =" update | reset "] [user - confirmation =" yes |no"]/ >
MSG ::= < message > STRING
EXEC ::= < execute > STRING
STRING ::= (A-Z|a-z |0 -9|_ -)+

90 ANHANG B. DATENMODELL

Anhang C
CCM-Konfiguration
Hier ist die Struktur der CCM-eigener Konfigurationsdatei zu sehen. Diese umfasst Informationen
über die zu verwendeten Adaptoren (RAA, RSA, LSA, . . . ), definiert Logging-
Parameter etc. Anschließend folgen zur Veranschaulichung Beispiel-Konfigurationen für
Server- sowie Client-seitige Anwendungen.
91

92 ANHANG C. CCM-KONFIGURATION
C.1 XMLSchema
< xsd:schema xmlns:xsd =" http: // www .w3.org /2001/ XMLSchema " xmlns:jaxb =" http: // java
. sun . com / xml /ns/ jaxb " xmlns:xjc =" http: // java . sun . com / xml /ns/ jaxb / xjc "
jaxb:extensionBindingsPrefixes =" xjc " jaxb:version =" 1.0 ">
< xsd:element name ="meta - config " type =" MetaConfigType "/>
< xsd:complexType name =" Parameter ">
< xsd:sequence >
< xsd:element name =" name " type =" xsd:string "/>
< xsd:element name =" value " type =" xsd:string "/>
< xsd:complexType name =" ParameterClass ">
< xsd:sequence >
< xsd:element name =" class - name " type =" xsd:string "/>
< xsd:element name =" parameter " type =" Parameter " minOccurs ="0" maxOccurs ="
unbounded "/>
< xsd:complexType name =" SecretParameterClass ">
< xsd:sequence >
< xsd:element name =" class - name " type =" xsd:string "/>
< xsd:element name =" secret - name " type =" xsd:string " minOccurs ="0"/>
< xsd:element name =" parameter " type =" Parameter " minOccurs ="0" maxOccurs ="
unbounded "/>
< xsd:complexType name =" MetaConfigType ">
< xsd:sequence >
< xsd:element name =" type ">
< xsd:simpleType >
< xsd:restriction base =" xsd:string ">
< xsd:enumeration value =" SERVER "/>
< xsd:enumeration value =" CLIENT "/>
< xsd:element name =" logger " type =" Logger "/>
< xsd:element name =" secret " type =" Secret " minOccurs ="0" maxOccurs ="
unbounded "/>
< xsd:element name =" admin " type =" SecretParameterClass "/>
< xsd:element name =" raa " type =" ParameterClass "/>
< xsd:element name =" lsa " type =" SecretParameterClass "/>
< xsd:element name =" application " type =" Application " maxOccurs =" unbounded "/>
< xsd:element name =" connection " type =" ParameterClass " maxOccurs =" unbounded "
/>
< xsd:complexType name =" Logger ">
< xsd:sequence >
< xsd:element name =" level ">
< xsd:simpleType >
< xsd:restriction base =" xsd:string ">
< xsd:enumeration value =" DEBUG "/>
< xsd:enumeration value =" INFO "/>
< xsd:enumeration value =" WARNING "/>
< xsd:enumeration value =" ERROR "/>
< xsd:enumeration value =" FATAL "/>

C.2. BEISPIEL-KONFIGURATION 93
< xsd:element name =" path " type =" xsd:string "/>
< xsd:complexType name =" Secret ">
< xsd:sequence >
< xsd:element name =" name " type =" xsd:string "/>
< xsd:element name =" class - name " type =" xsd:string "/>
< xsd:element name =" type ">
< xsd:simpleType >
< xsd:restriction base =" xsd:string ">
< xsd:enumeration value =" FILE "/>
< xsd:enumeration value =" SMARTCARD "/>
< xsd:element name =" parameter " type =" Parameter " minOccurs ="0" maxOccurs ="
unbounded "/>
< xsd:complexType name =" Application ">
< xsd:sequence >
< xsd:element name =" name " type =" xsd:string "/>
< xsd:element name =" rsa " type =" SecretParameterClass " maxOccurs =" unbounded "/
>
< xsd:element name =" transformer " type =" ParameterClass " minOccurs ="0"/>
C.2 Beispiel-Konfiguration
C.2.1
Server-seitige Konfiguration
SERVER
< logger >
DEBUG
/ data / logs / ccm / ccm_server . log
< secret >
Server - P12
flexsecure . util . security . pkcs7 . SoftTokenSecret
FILE
< parameter >
StoreType
P12
< parameter >
P12Path

94 ANHANG C. CCM-KONFIGURATION
/ data /ccm - root / server . p12
< parameter >
SigAlgorithm
SHA1withRSA
< parameter >
SigProvider
de. flexiprovider . core . FlexiCoreProvider
Server - Card
flexsecure . util . security . pkcs7 . SmartCardSecret
CARD
< parameter >
StoreType
CARD
< parameter >
SigProvider
de . flexiprovider . core . FlexiCoreProvider
< parameter >
SigAlgorithm
SHA1withRSA
// -->
de. flexsecure . ccm . rsa . AdminRemoteSecurityAdapter
Server - P12
< parameter >
root -cert - dir
/ data /ccm - root /. certs /. root
< parameter >
certificate - directory
/ data /ccm - root /. certs /. admin
de. flexsecure . ccm . raa . FileResourceAccessAdapter
< parameter >
config - path
/ data /ccm - root / ccm_config_test . xml
< parameter >
default - profile
B
de. flexsecure . ccm . lsa . PlainLocalSecurityAdapter

C.2. BEISPIEL-KONFIGURATION 95
< application >
ImpEx
de. flexsecure . ccm . rsa . PKIRemoteSecurityAdapter
Server - P12
< parameter >
root -cert - dir
/ data /ccm - root /. certs /. root
< parameter >
client -cert - dir
/ data /ccm - root /. certs /. user / group1
de. flexsecure . ccm . rsa . PlainRemoteSecurityAdapter
< transformer >
de. flexsecure . ccm .dt. XSLTranformer
< application >
App -B
de. flexsecure . ccm . rsa . PlainRemoteSecurityAdapter
< transformer >
de. flexsecure . ccm .dt. XSLTranformer
< application >
ProductInspector
de. flexsecure . ccm . rsa . PlainRemoteSecurityAdapter
< transformer >
de. flexsecure . ccm .dt. XSLTranformer
< transformer >
// -->
< connection >
de. flexsecure . ccm . connection . SocketConnection
< parameter >
port
1701

96 ANHANG C. CCM-KONFIGURATION
< connection >
de. flexsecure . ccm . connection . SocketConnection
< parameter >
port
2001
< connection >
de. flexsecure . ccm . connection . FileConnection
< parameter >
path
/ data /ccm - root / file_conn . bin
C.2.2
Client-seitige Konfiguration
CLIENT
< logger >
DEBUG
/ data / logs / ccm / ccm_client . log
< secret >
Client - P12
flexsecure . util . security . pkcs7 . SoftTokenSecret
FILE
< parameter >
SigProvider
de. flexiprovider . core . FlexiCoreProvider
< parameter >
StoreType
P12
< parameter >
SigAlgorithm
SHA1withRSA
< parameter >
P12Path
/ data /ccm - root / tn1 . p12
de. flexsecure . ccm . rsa . AdminRemoteSecurityAdapter
Client - P12
< parameter >
root -cert - dir
/ data /ccm - root /. certs /. root
< parameter >
certificate - directory
/ data /ccm - root /. certs /. admin
de. flexsecure . ccm . raa . FileResourceAccessAdapter
< parameter >
config - path

C.2. BEISPIEL-KONFIGURATION 97
/ data /ccm - root / ccm_config_client . xml
< parameter >
root - path
/ data /ccm - root
< parameter >
default - profile
B
de. flexsecure . ccm . lsa . PlainLocalSecurityAdapter
< application >
ImpEx
de. flexsecure . ccm . rsa . PKIRemoteSecurityAdapter
Server - P12
< parameter >
root -cert - dir
/ data /ccm - root /. certs /. root
< parameter >
client -cert - dir
/ data /ccm - root /. certs /. user / group1
de. flexsecure . ccm . rsa . PlainRemoteSecurityAdapter
< transformer >
de. flexsecure . ccm .dt. XSLTranformer
< application >
App -B
de. flexsecure . ccm . rsa . PlainRemoteSecurityAdapter
< transformer >
de. flexsecure . ccm .dt. XSLTranformer
< connection >
de. flexsecure . ccm . connection . SocketConnection
< parameter >
host
localhost
< parameter >
port
1701
< parameter >
timeout
30000

98 ANHANG C. CCM-KONFIGURATION

Glossar
JAXB Java Architecture for XML Binding
Eine JAVA-basierte Architektur zum Auslesen und Modifizieren von XML-Inhalten.
CCM Centralized Configuration Management
Ein zentralisiertes System zur Verwaltung von Konfigurationsdaten.
CCMP Centralized Configuration Management Protocol
Das Protokoll des Datenaustausches von CCM.
RAA Resource Access Adapter
Eine Schnittstelle zum Zugriff auf Konfigurationsdaten.
RSA Remote Security Adapter
Eine Schnittstelle zur Sicherung der Datenübertragung.
LSA Local Security Adapter
Eine Schnittstelle zur Sicherung von Datenresourcen.
DT Data Transformer
Eine Schnittstelle zum Transformieren der Konfigurationsdaten.
PKI Public Key Infrastructure
Eine Komponenteninfrastruktur zur Unterstützung von kryptografisch sicherem
Datenaustausch sowie der Benutzerautorisierung mittels asymmetrischen Verschlüsselungsverfahren
(Public Key - Kryptografie).
99

Index
Abhängigkeit, 55, 88
CCM
CCM-Protocol, 41
CCMPath, 21, 35, 40, 41, 44, 48, 52,
56
Vererbung
EQ-Vererbung, 27, 29, 31
Ref-Vererbung, 27, 29, 82
Verteilungsstrategie
Request, 15, 16, 40, 41, 43, 67
Rollout, 14–16, 41, 43, 45, 67
XML
JAXB, 12
XMLSchema, 13
XSLT, 5, 14
100

Literaturverzeichnis
[1] Elliotte Rusty Harold, W. Scott Means, XML in a nutshell, O’Reilly, 2001
[2] Eric van der Vlist, XML Schema, O’Reilly, 2003
[3] Michael Seeboerger-Weichselbaum, Das Einsteigerseminar JAVA/XML, bhv,
2002
[4] Steve Burnett, Stephen Paine, Kryptographie - RSA Security’s Official Guide,
mitp, 2001
[5] Eric Armstrong a.a., The Java Web Services Tutorial, Sun Microsystems, 2003
[6] Java Architecture for XML Binding (JAXB), http://java.sun.com/xml/jaxb/
[7] Scott Oaks, Java Security, O’Reilly; 1998
[8] Brett McLaughlin, Java and XML, O’Reilly, 2000
[9] FlexiTRUST - Produktbeschreibung, www.flexsecure.de/produkte
[10] Installable Unit Deployment Descriptor Specification, Version 1.0,
http://www.w3.org/Submission/2004/SUBM-InstallableUnit-DD-20040712/,
W3C Member Submission 12-July-2004
[11] Installable Unit Package Format Specification, Version 1.0,
http://www.w3.org/Submission/2004/SUBM-InstallableUnit-PF-20040712/,
W3C Member Submission 12-July-2004
[12] Niklar Jakob, Sebastian Stark, Ausarbeitung der Praktikumsarbeit zum Thema:
Public Key Insfrastrukturen
101