SAFE Grobkonzept-1 1 - justiz.de · Zuletzt gedruckt 01.02.2008 Seite 2 ... 1. und 2.1 Erstellung...

S A F E G r o b k o n z e p t

Thema: Registrierungsverzeichnis für Kommunikationsdienste – Deutschland-Online Projekt „Einheitliche Kommunikationsinf-rastruktur für den elektronischen Rechtsverkehr“

Verantwortlich: Unterarbeitsgruppe SAFE der BLK Arbeitsgruppe IT-Standards in der Justiz;

Dataport

Version.Release: 1.0

Erstellt am: 25.04.2007

Zuletzt geändert am: 31.12.2007

Zustand: in Bearbeitung / vorgelegt / fertiggestellt

Anzahl der Seiten: 49

Autoren: Herr Ehrmann (Justizministerium Baden Württemberg) mailto:[email protected] Telefon: 0711 2792-142

Herr Wöhrmann (Justiz Nordrhein-Westfalen, IT-Integration) mailto:[email protected] Telefon: 0211 4971-

647

Herr Streckel (Dataport, Softwareengineering und Lö-sungsarchitekturen)mailto:[email protected] Telefon: 0431

3295-6403

Herr Krause (Dataport, Softwareengineering und Lö-sungsarchitekturen)mailto:[email protected] Telefon: 0431

3295-6856

Dateiname: SAFE Grobkonzept-1_1.doc

Zusammenfassung: Das Grobkonzept beschreibt die Anforderungen und die Rah-menarchitektur für ein Registrierungsverzeichnis für Kommu-nikationsdienste. Es dient als Grundlage für das fachliche Feinkonzept und die Realisierung. Ausgehend von den Anfor-derungen der Justiz an eine sichere Kommunikationsinfra-struktur werden unter Berücksichtigung der weiteren Nutzung des EGVP als bereits erfolgreich etablierte Kommunikations-plattform und der geplanten Einbettung des SAFE in Deutsch-land-Online bestimmte Rahmenentscheidungen und –vorgaben getroffen.

Zuletzt gedruckt 01.02.2008

Seite 2 von 49

Dateiablage: M:\Persönliche Ablage\Doc\JUM\BLK\AG IT-technische Standards in der Justiz\UAG RVKD - DOL\Grobkonzept RVKD\SAFE Grobkonzept-1_1.doc

Änderungshistorie

Änderung

Re-

lea-

se

Datum

Geänder-

te

Kapitel

Beschreibung der Änderung Autor

0.1 25.04.

2007

Erstentwurf: Inhaltliche Strukturierung Herr Ehrmann

0.2 29.04.

2007

1. und 2.1 Erstellung 1.Kapitel und neues Kapitel

2.1

Herr Wöhrmann

0.2.

1

07.05.

2007

2.4 Erstellung 2.4 Herr Coujad

0.2.

2

30.05.

2007

2.1 Erweiterte Darstellung Kapitel 2.1 Herr Wöhrmann

0.8.

5

11.06.

2007

alle Komplettüberarbeitung des gesamten

Dokumentes

Herr Streckel,

Herr Krause

0.9 25.06.

2007

alle Überarbeitung nach BLK-UAG-Sitzung

vom 13.06.2007

Herr Streckel,

Herr Krause

1.0 31.07.

2007

Überarbeitung nach 32. AG-IT vom

05.07.2007, Freigabe

Herr Ehrmann

1.1 31.12.

2007

Anpassung an die neue Namensgebung

SAFE (Secure Access to Federated e-

Justice/eGovernment anstelle RVKD

(RegistrierungsVerzeich-

nis/KommunikationsDienste)

Herr Ehrmann


Seite 3 von 49


1 VORGABEN UND ZIELE ...................................................................................... 5

2 ZUSAMMENFASSUNG......................................................................................... 8

3 RAHMENENTSCHEIDUNGEN UND RAHMENVORGABEN................................ 9

3.1 RAHMENBEDINGUNGEN FÜR DIE EGVP-INFRASTRUKTUR ......................................... 9 3.2 RAHMENBEDINGUNGEN FÜR DEUTSCHLAND-ONLINE .............................................. 11 3.3 BEZIEHUNG DER RAHMENBEDINGUNGEN ............................................................... 11 3.4 IDENTITY-MANAGEMENT IM OSCI-UMFELD ........................................................... 12 3.5 EU-DIENSTLEISTUNGSRICHTLINIE ........................................................................ 15

4 VORGEHENSWEISE .......................................................................................... 16

5 ARCHITEKTURKONZEPT SAFE........................................................................ 18

5.1 MODULARE ARCHITEKTUR ................................................................................... 18 5.2 DIE VERTRAUENSDOMÄNE ................................................................................... 18 5.3 WICHTIGE STRUKTURKOMPONENTEN INNERHALB EINER VERTRAUENSDOMÄNE ........ 19

5.3.1 Attribute Service (AS) ................................................................................. 19 5.3.2 Attribute ...................................................................................................... 21 5.3.3 Identity Provider (IP) ................................................................................... 24 5.3.4 Registrierungsprozess ................................................................................ 25 5.3.5 Fachliche Services...................................................................................... 26 5.3.6 Clients für Fachanwendungen .................................................................... 27

5.4 TRUST-DOMAIN-ÜBERGREIFENDE KONZEPTE ........................................................ 28 5.4.1 Vertrauen zwischen Trust-Domains............................................................ 28 5.4.2 Meta-Attribute-Service ................................................................................ 30 5.4.3 Granularität von Trust-Domains.................................................................. 31

6 SAFE ALS KONKRETE UMSETZUNG DES DEUTSCHLAND-ONLINE-ARCHITEKTURKONZEPTES..................................................................................... 33

6.1 KONKRETE UMSETZUNG FÜR DEN SAFE............................................................... 33 6.1.1 Basisumsetzung ......................................................................................... 34 6.1.2 Erste AusbaustufErneuerung der Benutzerregistrierung ............................ 35 6.1.3 Zweite AusbaustufAusgliederung von Teilen der Daten in neue TDs......... 37 6.1.4 Erweiterungen............................................................................................. 39

6.2 NUTZERGRUPPEN, ROLLEN UND ZUGRIFFSRECHTE FÜR DAS SAFE ........................ 40 6.2.1 Rollen ......................................................................................................... 40 6.2.2 Attribute ...................................................................................................... 40 6.2.3 Zugriffsrechte der Nutzergruppen............................................................... 41

6.3 BEZIEHUNGEN ZU DVDV ..................................................................................... 41 6.4 BEZIEHUNGEN ZU UDDI ...................................................................................... 42 6.5 VERFÜGBARKEITEN, SERVICELEVEL ..................................................................... 43 6.6 TECHNISCHE STANDARDS UND SCHNITTSTELLEN................................................... 43


Seite 4 von 49


6.7 DATENSCHUTZANFORDERUNGEN.......................................................................... 43

7 MENGENGERÜST .............................................................................................. 44

7.1 OBJEKTE DES VERZEICHNISSES ........................................................................... 44 7.2 MENGENGERÜST NUTZER UND INSTITUTIONEN ...................................................... 44

8 MIGRATION ........................................................................................................ 45

8.1 BESCHREIBUNG EGVP-INHALTE DIE ZU ÜBERNEHMEN SIND.................................... 45 8.2 BESCHREIBUNG DER EGVP-CLIENT-SCHNITTSTELLE ALS GROBE LEITLINIE ............. 45

9 FESTLEGUNGEN UND VORLÄUFIGE FESTLEGUNGEN................................ 46

10 ABKÜRZUNGSVERZEICHNIS UND GLOSSAR ................................................ 47

11 ZEITPLANUNG / ARBEITSSCHRITTE............................................................... 49


Seite 5 von 49


1 Vorgaben und Ziele

Mit in Kraft treten des EHUG zum 01.01.2007 haben die Bundesländer die elektro-nische Handelregisteranmeldung verpflichtend vorgeschrieben. Dafür wurde in al-len Ländern und dem Bund eine Kommunikationsinfrastruktur über das EGVP er-probt und aufgebaut. Die Erwartungen der Bundesländer an die Nutzerzahlen des neuen Kommunikationsweges im Rahmen des elektronischen Rechtsverkehrs wurden schon im ersten Quartal 2007 bei weitem übertroffen.

Die BLK AG IT-Standards hat die Erfahrungsberichte der Registergerichte und des Lenkungskreises EGVP, der die Weiterentwicklung betreibt, wiederholt diskutiert und aufgearbeitet. Dabei hat sich gezeigt, dass dem Registrierungsdienst für die Anmeldung zum EGVP eine besondere Bedeutung zukommt. Über diesen Dienst wird jeder Kommunikationsteilnehmer eindeutig einem Postfach zugeordnet. Damit die Adressierung von jedem einzelnen EGVP Nutzer zuverlässig erfolgen kann, wird das Adressbuch des Registrierungsdienstes regelmäßig an alle empfangsbe-reiten EGVP repliziert. Dies führt bei inzwischen ca. 20.000 eingerichteten Postfä-chern zu erheblichen Performanceproblemen, da die EGVP-Clients die gesamten Registrierungsdaten bei Anmeldung (und Abmeldung) insgesamt herunterladen (bzw. abgleichen). Eine erste Lösung dieses Problems wird bereits durch einen Change-Request des Lenkungskreises EGVP erarbeitet, der sich im Rahmen der derzeitigen zentralen Architektur des aktuellen Registrierungsdienstes bewegt.

Deshalb können die Postfächer der Verfahrensbeteiligten nur an einer Stelle (zur-zeit LDS NRW) betrieben werden, während die Postfächer der Justizeinrichtungen schon jetzt teilweise dezentral in einzelnen Bundesländern eingerichtet sind. Die Schnittstellen des zentralen Registrierungsdienstes entsprechen nicht den vorge-gebenen technischen Standards. Länder bzw. Fachapplikationen, die das EGVP nicht nutzen, haben evt. technische Probleme, die richtige Adressierung zu reali-sieren. Eine Loslösung des Registrierungsverzeichnisses vom EGVP unter Schaf-fung einer Standardschnittstelle zum EGVP kann dieses Problem beseitigen. Dar-über hinaus brächte ein solcher unabhängiger Registrierungsdienst weitere An-wendungsmöglichkeiten für zusätzliche Kommunikationswege und Webservices, die gemeinsam mit den Standesvertretungen der regelmäßigen Verfahrensbeteilig-ten der Justiz wie Bundsnotarkammer, Rechtsanwaltskammer etc. konzipiert und entwickelt werden könnten. Weiter würde ein Dienst zur Verfügung gestellt werden, der eine Brücke zwischen dem Elektronischen Rechtsverkehr und dem E-Government bildet und wäre somit eine zukunftsweisende Ergänzung zum deut-schen Verwaltungsdiensteverzeichnis (DVDV), das derzeit für das Meldewesen be-trieben wird.

Die 80. BLK hatte unter TOP 14 II beschlossen, die Integrationsfähigkeit der EGVP/ERV-D-Infrastruktur zu erhöhen und auch anderen Anwendungen eine Nut-zung des Registrierungs- und Verzeichnisdienstes über offene Schnittstellen zu


Seite 6 von 49


ermöglichen und die bisherigen produktbezogenen Registrierungsfunktionen (im EGVP) zu einem zentralen „Registrierungsverzeichniss für Kommunikationsdiens-te“ (der vorläufige Vorhabensname „Registrierungsverzeichniss für Kommunikati-onsdienste“Kürzel RVKD, wurde umbenannt in SAFE, Secure Access to Federated eJustice/eGovernment) weiterzuentwickeln. SAFE muss dadurch Nutzerzahlen zu-lassen, die um eine Größenordnung über den zu erwarteten Nutzern des EGVP- Registrierungsdienstes liegen.

Zur Herstellung der Zukunftsfähigkeit des Registrierungsdienstes hat die BLK ein Deutschland-Online-Projekt „Einheitliche Kommunikationsinfrastruktur für den e-lektronischen Rechtsverkehr“ initiiert. Der Justizbereich ist aufgrund seiner ver-gleichsweise sehr weitgehenden "Elektronifizierung" Vorreiter für andere Verwal-tungsbereiche, die ähnliche Probleme erst in Zukunft haben werden. Das Deutsch-land-Online-Projekt zielt daher auf die Entwicklung einer komplett offenen und ü-bergreifend nutzbaren Lösung, die sicherstellt, dass die technische Konzeption und Realisierung unter Berücksichtigung der eGovernment-Standards erfolgt, um so eine breite Nutzungsmöglichkeit der Ergebnisse zu gewährleisten.

Unter Ziffer 5 TOP 14 II wurde die BLK-AG „IT-Standards in der Justiz“ mit der Betreuung des Projekts beauftragt: 5. Die Bund-Länder-Kommission für Datenverarbeitung und Rationalisierung in

der Justiz beauftragt die AG-IT, das vorgeschlagene Deutschland-Online-Projekt „Einheitliche Kommunikationsinfrastruktur für den elektronischen Rechtsverkehr“ nach Verabschiedung durch die JuMiKo zu betreuen und der BLK zu berichten.

Die Justizministerkonferenz hat auf ihrer Sitzung am 30.11.2006 in Brüssel den Vorschlag für ein Deutschland-Online Projekt gebilligt und es mit Schreiben vom 21. Dezember 2006 an die Ministerpräsidentenkonferenz mit folgenden Zielen an-gemeldet:

a) Die Vereinheitlichung der Kommunikationsinfrastruktur innerhalb des Justizbe-reichs soll fortgeführt werden. Noch bestehende technische Kommunikations-hindernisse zwischen einzelnen Justizverwaltungen sollen beseitigt und histo-risch gewachsene verfahrensspezifische Sonderlösungen in eine einheitliche Kommunikationsinfrastruktur überführt werden.

b) Die sich in der Praxis herausbildende einheitliche Kommunikationsinfrastruktur für den Justizbereich soll auch für die Verwaltungsbehörden in Bund, Ländern und Kommunen geöffnet und deren spezifische Anforderungen bei der Weiter-entwicklung berücksichtigt werden.

c) In technischer Hinsicht steht die Weiterentwicklung des zentralen Registrie-rungs- und Verzeichnisdienstes im Zentrum des Projekts. Dieser soll im Rah-men des Projekts zu einer selbständigen Komponente weiterentwickelt werden, die nicht nur dem z. B. für die oben genannten elektronischen Registeranmel-dungen verwendeten Programm EGVP (Elektronisches Gerichts- und Verwal-


Seite 7 von 49


tungspostfach), sondern auch anderen Anwendungen für den elektronischen Rechtsverkehr zur Verfügung steht.

Das vorliegende Dokument beschreibt eine Infrastruktur, die in der Lage ist, die Anforderungen an ein zentrales Registrierungsverzeichnis für Kommunikations-dienste (SAFE) zu erfüllen. Es ist so offen gestaltet, dass sie zudem den Anforde-rungen des Deutschland-Online-Projektes gerecht wird. Die Konzeption kann ohne konzeptuellen Bruch zur Registrierung für beliebige E-Government-Dienste genutzt werden. Dazu wird eine hoch skalierbare Architektur vorgeschlagen. Einerseits um unterschiedlichste Nutzergruppen mit verschiedenartigen Zugriffsrechten daten-schutzkonform abzubilden, andererseits um die Anzahl möglicher Nutzer nicht zu begrenzen.

Ziel ist die Fortentwicklung dieses Grobkonzepts hin zu einem Feinkonzept als Grundlage für die Erstellung eines ersten SAFE Prototyps als Realisierungstest zur Klärung von technischen Fragen (technischer Durchstich) zur Vorbereitung der pro-totypischen Anwendung im Bereich der Justiz. (siehe Zeitplan)


Seite 8 von 49


2 Zusammenfassung

Das Grobkonzept liefert die Anforderungen und die Rahmenarchitektur für ein Re-gistrierungsverzeichnis für Kommunikationsdienste (SAFE). Ausgehend von den konkreten Anforderungen des SAFE an eine Benutzerregistrierung wird auf Basis von Standards aus dem Web-Service-basierten Identity-Management-Umfeld eine hoch skalierbare Registrierungslösung für beliebige E-Government-Kommunikationsteilnehmer konzipiert. Damit kann das vorliegende Konzept auch zur Basis für die Benutzerregistrierung im gesamten Deutschland-Online-Umfeld ausgebaut werden. Eine Einbindung von anderen Registrierungslösungen wie Bür-gerportalen ist vorgesehen.

Das Dokument gliedert sich in zwei wesentliche Teile. In einem ersten Teil wird ein Konzept für das Management von Benutzeridentitäten auf Basis von internationa-len Standards und Schnittstellenspezifikationen erarbeitet. Im zweiten Teil wird die konkrete Umsetzung dieses Konzeptes für die Anwendung SAFE beschrieben. Es werden Komponenten und Änderungen am bestehenden System beschrieben, so dass auf Basis dieser Ausarbeitung eine erste Aufwandsschätzung für die vorge-schlagene SAFE-Lösung möglich ist.

Das Dokument dient als Grundlage für die Erstellung eines fachlichen Feinkonzep-tes und der ersten technischen Machbarkeitsstudie anhand einer prototypischen Implementierung (technischer Durchstich) auf dessen Basis die 82. BLK die ent-sprechenden Entscheidungen treffen kann und auf dessen Basis dann die prototy-pische Realisierung für die Justiz erfolgen kann (s. auch Zeitplan). Es werden kon-krete Empfehlungen für Rahmenentscheidungen bezüglich der Ausgestaltung des Systems sowie unterstützten Standards ausgesprochen.


Seite 9 von 49


3 Rahmenentscheidungen und Rahmenvorgaben

3.1 Rahmenbedingungen für die EGVP-Infrastruktur

Die bereits aufgebaute EGVP Kommunikationsinfrastruktur per OSCI Protokoll für den elektronischen Rechtsverkehr mit den Bundesgerichten, den nordrhein-westfälischen Verwaltungs- und Finanzgerichten sowie bundesweit mit allen Regis-ter- und Mahngerichten muss auch mit einem neuen Registrierungsdienst weiterhin nutzbar bleiben. Das bedeutet, der Kommunikationsdiensteteilnehmer

• registriert sich nur einmal. • benötigt nur eine Clientsoftware, um mit allen angeschlossenen Institutionen

kommunizieren zu können. • muss darauf vertrauen können, dass seine datenschutzrechtlichen Belange ge-

wahrt bleiben. • bleibt unbehelligt vom Einfluss föderaler Entscheidungen. Derzeitige Architektur:

Der Postfachclient adressiert im Rahmen der OSCI Kommunikation das Postfach der empfangenden Institution über die URL des Intermediärs und das Verschlüsse-lungszertifikat des Empfängerpostfachs. Damit die absendende Institution auch für den Rückweg nur aktuelle Verschlüsselungszertifikate der Empfänger benutzt, ist eine dauerhafte und aktuelle Zuordnung der in der Regel natürlichen Personen zu ihren Zertifikaten notwendig. Dies wird durch den Registrierungsserver sicherge-stellt.

Im Gegensatz zum Registrierungsserver, der zurzeit für alle EGVP-Kommunika-tionsteilnehmer zentral an einer Stelle, dem Landesamt für Datenverarbeitung und Statistik NRW (LDS NRW), betrieben wird, sind die Postfächer empfangender Insti-tutionen schon heute unterschiedlichen Intermediären in einzelnen Bundesländern


Seite 10 von 49


zugeordnet. Die Adressinformationen der Behörden werden, konfiguriert über die aufrufende JNLP-Datei, dem entsprechenden Intermediär zugeordnet und dann zentral frei geschaltet. Erst danach kann der externe Absender seine elektronisch signierte Nachricht an die Behörde verschicken.

Dagegen kann sich der externe Kommunikationsteilnehmer ohne Freischaltung durch den zentralen Administrator registrieren und ein Postfach für die Teilnahme am elektronischen Rechtsverkehr einrichten. Dieses Postfach kann sofort genutzt werden. Da hier eine Zuordnung zu genau einer Intermediärsadresse stattfindet, werden die Postfächer der externen Kommunikationsteilnehmer auf dem Verfah-rensbeteiligten-Intermediär des LDS NRW zentral gehostet.

Von dem Konzept der Postfacheinrichtung ohne Freischaltung durch den externen Nutzer soll auch künftig nicht abgewichen werden. Deshalb müssen bei weiteren Verfahrensbeteiligten-Intermediären sämtliche Registrierungsdaten aller beteiligten Kommunikationspartner zur Verfügung stehen.


Seite 11 von 49


3.2 Rahmenbedingungen für Deutschland-Online

Die Anforderungen des Deutschland-Online-Projektes an eine Benutzerregistrie-rung gehen über die oben skizzierten, sehr konkreten Anforderungen der EGVP-Kommunikation an das SAFE deutlich hinaus. Sie sind zudem abstrakter gefasst, da es keine spezielle Anwendung gibt. Es muss eine Vielzahl möglicher Anwen-dungen berücksichtigt werden, für die eine Registrierung oder sichere Authentisie-rung eines Nutzers notwendig ist. So muss beispielsweise grundsätzlich die Anbin-dung von Bürger- oder Justizportalen genauso berücksichtigt werden, wie unter-schiedliche E-Government-Dienste, die sich vom Rechtsverkehr wesentlich unter-scheiden und andere Anforderungen an die Registrierung stellen können. Damit eine künftige Anbindung anderer Dienste jederzeit möglich ist, kann hier nur der grundsätzliche Rahmen definiert werden.

Die zentralen Anforderungen sind hier aufgeführt:

• Standardisierte Schnittstellen sowie eine strikte Anwendung international anerkannter Standards erleichtern Drittanbietern die Entwicklung interope-rabler Systemkomponenten und neuen fachlichen Diensten.

• Die Anzahl der Nutzer darf nicht auf 10.000, 100.000 oder 1.000.000 be-schränkt sein. Es ist eine erhebliche Skalierbarkeit erforderlich.

• Dezentrale Speicherung der Daten ermöglicht die Wahrung der Datenhoheit entsprechend der föderalen Struktur der Bundesrepublik. Datenschutzrechtliche Kontrolle obliegt dem Betreiber des jeweiligen Teilverzeichnisses.

• Unterschiedlichste Nutzergruppen erfordern unterschiedlich starke Authenti-sierungsverfahren je nach ihren Zugriffsrechten auf die bereitgestellten Daten oder Dienste.

• Ein detailliertes Rollenkonzept für die unterschiedlichen Nutzergruppen bildet die jeweiligen Zugriffsrechte ab. Hierbei sind Datenschutzrichtlinien strikt einzu-halten, d.h. die bereitgestellte Information muss für den Anfragezweck ange-messen sein. Die Anmeldung darf dabei nicht von der natürlichen Person ab-hängen, sondern muss in verschiedenen Rollen möglich sein.

• Trotz dieser Rahmenbedingungen muss ein schlankes Konzept entwickelt werden.

• Eine starke Modularisierung ermöglicht die Verwendung vorhandener Kom-ponenten bei der Erschließung neuer Anwendungsfelder.

• Die Integration bestehender Infrastrukturen für das Management von Identi-täten (z.B. Landesportale wie das „HamburgGateway“) muss möglich sein.

3.3 Beziehung der Rahmenbedingungen

Das SAFE stellt die konkrete Implementierung eines (wichtigen) Anwendungsfalls innerhalb dieser Deutschland-Online-Architektur dar. Damit muss er den vorgege-


Seite 12 von 49


benen Architekturkonzepten genügen und die dort beschriebenen Komponenten mindestens teilweise implementieren. Die konkreten Anforderungen an diese Imp-lementierung sind durch die Rahmenbedingungen der EGVP-Infrastruktur gege-ben.

3.4 Identity-Management im OSCI-Umfeld

In den vorangegangenen Abschnitten zu Rahmenentscheidungen und Rahmenbe-dingungen sind die funktionalen Leistungen des zu entwerfenden Systems SAFE bereits grob skizziert worden. Dies erfolgte vornehmlich mit Blick auf den existie-renden EGVP-Registrierungsserver. Der dort beschriebene primäre Zweck des Systems ist, registrierten Kommunikationsteilnehmern ein Postfach auf einem OSCI-Intermediär zuzuordnen und diese Zuordnung für eine elektronische Adres-sierung verfügbar zu machen.

Es lassen sich zur Erfüllung dieses Zwecks bereits zwei funktionale Blöcke identifi-zieren:

• Registrierung Die Registrierung umfasst Prozesse und Mechanismen, um neue Kommunika-tionspartner mit ihren identifizierenden Daten und der Postfachzuordnung ins Verzeichnis aufzunehmen. Es bestehen Anforderungen an Integrität und Au-thentizität der erfassten Daten. Das Verzeichnis vertraut dem Registrierenden, dass die angegebene Identität der tatsächlichen entspricht und die übermittel-ten Daten korrekt sind. Prozess und technische Mechanismen (Authentifizie-rung) dienen dazu, diese Vertrauensbeziehung gewährleisten zu können.

��

��

• Verzeichnisabfrage

Bei der Verzeichnisabfrage sucht ein Kommunikationspartner die Daten ande-rer Kommunikationspartner, um eine Nachricht ins Postfach senden zu können (Adressbuch). Hierbei vertraut der Anfrager dem Verzeichnis, dass die Einträge authentisch und integer sind und erwartet technische Maßnahmen, die die Kor-rektheit der gelieferten Identitäten zusichern.


Seite 13 von 49


��

��

Diese sehr unterschiedlichen Funktionsblöcke sollten – zumindest logisch - durch eigene Systeme repräsentiert werden, die aber mit denselben Daten operieren.

Die im Verzeichnis registrierten Kommunikationsteilnehmer können natürliche Per-sonen (Anwälte, Bürger) und Institutionen (Gerichte, Behörden) sein. Im Kontext EGVP traten diese Teilnehmer bislang ausschließlich in der Rolle eines EGVP-Empfängers auf, also eines Empfängers asynchroner one-way-OSCI-Transport-Nachrichten.

Ein Neuentwurf verfolgt einen generelleren Ansatz und berücksichtigt weitere Rol-len, die registrierte Teilnehmer potentiell einnehmen können::

• OSCI-Leser Das Modell von OSCI-Transport differenziert die an einer Kommunikation betei-ligten Rollen in Autor, Sender, Empfänger und Leser. Empfänger und Leser können in bestimmten OSCI-Anwendungsfällen durchaus logisch und physisch getrennt sein; auch kann ein Nachrichtenumschlag Nachrichten für mehrere Leser beinhalten. Verschlüsselungszertifikate des empfangenden Systems (z.B. EGVP-Client) müssen nicht mit denen des Lesers übereinstimmen.

• OSCI-Autor Informationen zu registrierten Teilnehmern können auch in der Rolle des Versendenden nützliche Verwendung finden. Leser einer signierten Nachricht können die Zuordnung von Signaturzertifikaten zum Autor über das Registrie-rungsverzeichnis verifizieren. Im Verzeichnis hinterlegte Attributwerte (Rollenbezeichnungen, Rechte etc.) können auf diese Weise mit dem Signaturzertifikat sicher verknüpft werden. Dieser Mechanismus ist wesentlich flexibler als ergänzende Attribute innerhalb eines X.509-Zertifikats (Attributzertifikat) und ist für viele Anwendungsfälle als Grundlage für Autorisierungsentscheidungen geeignet.

• Dienstnutzer Die Nutzung von Diensten (z.B. Registerauskünfte über synchronen OSCI-Nachrichtenaustausch) ist in der Regel nur autorisierten Personen oder Institu-tionen gestattet. Unabhängig von der Authentifizierungstechnik müssen die Nutzer registriert und verwaltet werden (z.B. zur verlässlichen Zuordnung von


Seite 14 von 49


Rollen, Rechten oder Authentifizierungszertifikaten). Nutzer von Diensten sind eine spezielle Ausprägung von Kommunikationsteilnehmern.

• Autorisierte OSCI-Sender Häufig wird das Versenden von Nachrichten in Postfächer nur bestimmten Teil-nehmergruppen eingeräumt (z.B. Meldebehörden bei XMeld). Implementierungen von OSCI-Intermediären erlauben heute, den Empfang von Nachrichten für ein bestimmtes Senderzertifikat oder dessen Root-Zertifikat einzuschränken. Die Autorisierung lässt sich aber häufig nicht einfach an ein Root-Zertifikat binden; d.h. Inhaber von Zertifikaten einer bestimmten CA und die Gruppe berechtigter Personen werden nur in Ausnahmefällen deckungs-gleich sein. OSCI 2.0 wird voraussichtlich neben X.509-Zertifikaten auch so genannte SAML-Token unterstützen, die zu Autorisierungszwecken verwendet werden können. Diese SAML-Token werden zur Zusicherung von Identität und Eigen-schaften über spezielle Dienste von Registrierungsverzeichnissen ausgestellt.

Diese Auflistung verdeutlicht, dass als Kommunikationsteilnehmer zweckmäßiger-weise nicht nur Empfänger, sondern auch Initiatoren einer Kommunikation (soge-nannte Requestor) im Registrierungsverzeichnis verwaltet werden sollten. Die re-gistrierten Teilnehmer variieren sowohl in der Rolle innerhalb einer Kommunikati-onsbeziehung (Autor, Sender, Empfänger, Leser) als auch in ihrer Existenzform (natürliche Person, Institution) – in diesem Sinne ist der abstrakte Begriff „Identität“ für die Objekte des Verzeichnisses durchaus adäquat.

Die sichere Verwaltung von Identitäten (Aufnahme, Pflege, Löschung) und die Be-reitstellung der den Identitäten zugeordneten Daten (Verzeichnisabfragen, Adress-buch) sind funktionale Leistungen, die üblicherweise „Identity-Management-Systemen“ zugerechnet werden - oder pointiert formuliert: SAFE ist Identity-Management, wenn der Ansatz nicht zu kurz greifen soll.

Mit Blick auf die technologische Entwicklung wie OSCI 2.0 oder serviceorientierte Architekturen (SOA) als auch auf die immer weiter reichende Automation umfas-sender Geschäftsprozesse mit immer mehr Beteiligten (z.B. Anwälte, Gerichte, Staatsanwaltschaften, Polizei, Strafvollzug) erscheint es dringend geboten, beim Entwurf der Modelle und Schnittstellen das SAFE als Identity-Management zu be-greifen.

Das hier vorgestellte Konzept basiert auf den WS-* Spezifikationen1, die von der OASIS als internationale Standards anerkannt sind. Insbesondere wichtig für die Ausgestaltung der Föderation im Föderierten Identity-Management sind die Stan-dards WS-Trust und WS-Federation, die gemeinsam von IBM und Microsoft entwi-ckelt wurden. Die WS-* Spezifikationen basieren wiederum auf XML-SOAP-Nachrichten und nutzen WS-Policy bzw. WS-SecurityPolicy, um die Schnittstellen

1 Definitive Festlegung, siehe Tabelle in Abschnitt �9


Seite 15 von 49


zu beschreiben. Der untere Block („Standards“) in Abbildung 1 zeigt alle Stan-dards, die hier eine Rolle spielen, sowie deren Zusammenhänge.

Ein nicht unwichtiger Aspekt ist, dass für die Implementierung der WS-* Spezifika-tionen mittlerweile eine beachtliche Zahl von Frameworks, Bibliotheken und Pro-dukten verfügbar sind – sowohl für Java als auch für .NET. Dies erleichtert Herstel-lern von Lösungen und Produkten (kooperierenden Trust-Domains, Clients wie z.B. EGVP und Applikationen/Services), sich in das Gesamtsystem zu integrieren. Zu-dem fördert die Orientierung an Standards generell die Akzeptanz bei Drittanbie-tern.

3.5 EU-Dienstleistungsrichtlinie

Für die in der Richtlinie geforderte sichere Kommunikation zwischen Behörden ist ein föderiertes Identity-Management in dieser hier beschriebenen oder ähnlichen Form praktisch unumgänglich. Durch ein solches Identity-Management wird es möglich, dass ein Bürger sich nur einmal registrieren muss (z.B. bei seinem Bür-gerbüro für ein Bürger- oder Landesportal) und damit für alle ihn betreffenden E-Government-Dienste, inklusive EGVP, autorisiert ist. Damit wird das Konzept des Single-Sign-On, also die mehrfache Nutzung von E-Government-Diensten nach ei-nem Log-In Vorgang, unterstützt.

Im Rahmen des Deutschland-Online-Projekts wird sichergestellt, dass die für SAFE getroffenen Architektur-Entscheidungen den hiermit angestrebten Zielen nicht widersprechen, sondern diese fördern.


Seite 16 von 49


4 Vorgehensweise

Um eine Implementierung des SAFE durchzuführen, muss der Implementierungs-phase eine detaillierte Planungsphase vorausgehen. Hier wird eine Auswahl und Profilierung vorhandener Standards (SOAP, WS-*) vorgenommen, um auf dieser Basis in einem Feinkonzept Schnittstellen und Komponenten der Zielarchitektur festzulegen. Erst nach diesem Schritt erfolgt die konkrete Implementierung des SAFE basierend auf der festgelegten Architektur. In Abschnitt �11 werden die Ein-zelschritte in eine grobe Zeitplanung eingeordnet, Abbildung 1 verdeutlicht die Zu-sammenhänge:

• Auf Basis von bestehenden Standards muss zunächst ein Architekturkonzept für die Deutschland-Online Anforderungen entwickelt werden (1). In einer Spe-zifikation werden Komponenten und Schnittstellen beschrieben. Dazu werden bereits existierende Standards profiliert und erweitert. Alle Schnittstellen wer-den streng standardkonform entwickelt. In dieser Phase wird das Konzept be-reits durch Prototypen und Lastsimulation getestet und untermauert.

• Auf dieser Schnittstellen-Profilierung aufbauend wird dann im Rahmen dieses Architekturkonzeptes das SAFE als eine konkrete Anwendung entworfen und entwickelt (2 und 3). In diesem Schritt entstehen bereits wichtige und standard-konforme Softwarekomponenten, die aufgrund der modularen Architektur für spätere konkrete Projekte sehr gut wiederverwendbar aber auch einzeln aus-tauschbar sind.


Seite 17 von 49


Abbildung 1: Modulare Vorgehensweise bei der SAFE-Entwicklung

Messaging: SOAP, WS-Addressing, MTOM

XML

WS-Security

WS-SecurityPolicy

WS-Trust

WS-Federation WS-SecureConversation Metadata: WS-Policy

Spezifikation für Föderiertes Identity Management (FIM) Spezifikation

FIM Infrastruktur

Open Source / Java

FIM Infrastruktur .NET

Interope-rabilitäts- Nachweis

Infrastruktur

…

Registrierungslösung

EGVP (SAFESAFESAFE)

Registrierung im

GovernmentGateway für VPS (z.B Elba) Lösung

…

Profilierung

Implemen-tierung

Implemen-tierung

Realisier- ung

Realisier- ung

Implemen-tierung

Realisier- ung

3

2

1

Standards


Seite 18 von 49


5 Architekturkonzept SAFE

5.1 Modulare Architektur 2

Im Rahmen von Deutschland-Online ist davon auszugehen, dass das zu entwer-fende System von unterschiedlichsten Nutzergruppen verwendet wird.

Aus dieser Diversifizierung von Benutzern und Benutzerdatenhoheiten ist ersicht-lich, dass ein Adressbuch für Deutschland-Online nicht an einer Stelle zentral ab-gelegt werden kann. Es ist also erforderlich, die Nutzer nach Benutzergruppen auf-zuteilen und verteilte Verzeichnisdienste aufzubauen, die aber über einheitliche Schnittstellen ansprechbar sind.

Die Daten der Verzeichnisse sind disjunkt. Das bedeutet: es ist keine Replikation vorgesehen. Daher muss ein übergeordneter Dienst entwickelt werden, der eine Zusammenführung unterschiedlicher Verzeichnisse ermöglicht und Adressabfra-gen über die Einzelverzeichnisse vereinheitlicht.

5.2 Die Vertrauensdomäne

Die Vertrauensdomäne oder Trust-Domain (TD) ist das zentrale strukturierende E-lement in diesem Konzept. Sie besteht aus einer Menge von Diensten und Dienst-nutzern, die in einer gegenseitigen Vertrauensbeziehung stehen. In Abbildung 2 sind die Elemente einer solchen Vertrauensdomäne schematisch dargestellt.



Seite 19 von 49


Abbildung 2 : Komponenten einer Trust-Domain (TD).

Insbesondere enthält jede Vertrauensdomäne einen Attribute Service (AS), also einen Verzeichnisdienst, der auf Anfrage Adressdaten übermitteln kann. Der AS einer Domäne stellt immer die Daten für eine einheitliche Nutzergruppe oder An-wendung bereit. Die Aufteilung nach Nutzergruppen oder Anwendungen ist dabei beliebig. Beispiele für einzelne AS wären: Notare, Gerichte und Justizbehörden, Bürger SH, Bürger NRW. Die Einteilung in Nutzergruppen kann je nach Zuständig-keit oder Datenhoheit beliebig erfolgen.

Über den Identity Provider (IP) werden die Zugriffe und Berechtigungen auf alle Services innerhalb der Vertrauensdomäne gesteuert. Alle Zugriffe auf Domänen-services von außen, sei es durch eine Clientanwendung, eine Benutzerregistrie-rung oder aus einer fremden Vertrauensdomäne werden vom IP authentifiziert und autorisiert. Der IP ist der zentrale Dienst zur Verwaltung von Benutzerrechten und zur Herstellung eines domänenübergreifenden Sicherheitskonzeptes.

Die Abgrenzung zum DVDV bzw. dessen Einbindung wird weiter unten beschrie-ben.

5.3 Wichtige Strukturkomponenten innerhalb einer Vertrauensdomäne

Innerhalb einer Vertrauensdomäne sind AS und IP die zentralen, obligatorischen Dienste3, die in jedem Fall zu implementieren sind. Hinzu kommen fachliche Diens-te, die aus einer konkreten Fachanwendung resultieren, sowie Registrierungsver-fahren mit denen Nutzer in eine TD aufgenommen werden können. Neben der in-ternen TD-Kommunikation muss auch die Kommunikation zwischen TDs und die Methode, mit der sich fachliche Dienste beim IP anmelden, spezifiziert werden.

5.3.1 Attribute Service (AS)

Das vorliegende Grobkonzept folgt einem Modell, das in seinem Kern durch die Webservice-Spezifikation „WS-Federation“ und der abhängigen Spezifikationsfami-lie definiert ist (siehe Abschnitte �3.4 und �4). WS-Federation definiert einen Service, der Informationen zu Identitäten der Vertrauensdomäne (TD) in Form von Attribu-ten liefern kann – den Attribut-Service. Als Service der TD erfolgt Authentifizierung und Autorisierung über den Identity-Provider (IP). Der IP weist dem anfragenden Nutzer eine Rolle zu (eingebettet in einem Sicherheits-Token), die dem AS über-mittelt wird. Der AS entscheidet dann auf Basis der übermittelten Rolle, welche Att-ribute und Datensätze für den Benutzer sichtbar sind.



Seite 20 von 49


Die WS-Federation-Spezifikation beschreibt lediglich das konzeptuelle Modell des AS und überlässt Festlegungen auf konkrete Schnittstellen der Implementierung. Schnittstellen des AS sollen daher WS-Security/WS-Trust (und OSCI 2.0) konform ausgelegt sein. Dieses Konzept sieht als Nachrichtenformat für den AS die Service Provisioning Markup Language (SPML) in der Version 2.0 vor4. SPML ist ein von OASIS entwickeltes, XML-basiertes Framework für den Austausch von Benutzer- und Ressource-Informationen zwischen kooperierenden Organisationen.

SPML bietet Operationen für Anfragen (lookup und search) und Änderungen (add, modify, delete). Die Anfrage-Operationen sind sehr gut geeignet, die konkrete Schnittstelle des AS zu definieren und bieten interessante Merkmale wie z.B. die Iteration übers Netzwerk bei großen Datenmengen. SPML hat eine große Akzep-tanz bei Herstellern von Identity-Management-Produkten erworben.

SPML 2.0 unterstützt gegenwärtig zwei Profile zur Definition der eigentlichen Daten zu Identitäten (Attribute). Ein Profil basiert auf Directory Service Markup Language (DSML) Version 2.0. DSML ist eine direkte Abbildung von LDAP auf XML. Das DSML-Profil ist aber nur aus Gründen der Abwärtskompatibilität zu SPML 2.0 ent-halten. Das zweite, empfohlene Profil basiert auf XML-Schema oder XSD (SPMLv2 XSD Profile) und ermöglicht daher auch strukturierte Attributwerte. Die Anfrage-sprache innerhalb der search-Operation ist XPath, daher sind prinzipiell auch kom-plexe Anfragen, die auf Subelemente von strukturierten Attributen filtern, möglich.

Es wird daher SPML 2.0 verwendet.

XSD als Datenbeschreibungssprache für die Attribute einer Identität bietet die Möglichkeit, durch Schemaerweiterungen (ergänzende Schemata) - gerade in fö-derierten Szenarien – ein Schalenmodell umzusetzen (siehe Abschnitt 4.3.2). Das XSD Schema lässt sich in einer konkreten Implementierung leicht in ein tatsächli-ches Datenbankschema umwandeln. Ob die Datenbankimplementierung dabei als LDAP oder relationale Datenbank erfolgt, wird in diesem Architekturkonzept be-wusst offen gelassen. Für bestimmte Anwendungen kann es z.B. auch sinnvoll sein, wenn der AS seine Daten aus einem Active Directory bezieht.

Es wird daher XSD verwendet.

4 Vorläufige Festlegung, siehe Tabelle in Abschnitt �9


Seite 21 von 49


Der Attribute Service ist lediglich die Schnittstelle für die lesenden Zugriffe auf die Attribute der in der Trust-Domain verwalteten Identitäten (im Identity Store). Das SPML-Konzept sieht prinzipiell die Möglichkeit vor, durch einen SPML-Service mehrere Identity-Stores zu verwalten (Targets). Ein spezieller Target kann z.B. auch eine virtuelle Zusammenfassung von Attribute Services sein (siehe auch Ab-schnitt �5.4.2).

Der Attribute Service wirkt als Adapter, der die SPML-Anfragen in die konkrete DB-Anfragesprache umsetzt (z.B. SQL oder LDAP) und die resultierenden Daten als SOAP-Nachricht über einen sicheren Kommunikationskanal weiter leitet. Dies wird in Abbildung 3 anschaulich verdeutlicht.

Abbildung 3 : Der Attribute Service (AS).

5.3.2 Attribute

Attribute sind Eigenschaften eines Nutzers (Identität) wie Name, E-Mail-Adresse und Zertifikate aber auch Rollenbezeichnungen, Gruppenzugehörigkeit und Rech-te. Diese Attribute sind im Identity Store der TD gespeichert und können von des-sen Identity Provider attestiert werden (siehe Abschnitt �5.3.3). Welche Attribute zu einem Nutzer im Identity Store gespeichert werden und welche vom Attribute Ser-vice an anfragende Dritte herausgegeben werden, hängt von der konkreten An-wendung ab.

Wie im Abschnitt zum Attribute Service bereits beschrieben, werden die Attribute als XML-Schemata (XSD) festgelegt. Die Attribute einer TD werden durch mehrstu-fige XSD-Dateien beschrieben5 - dies kann auch als Schalenmodell aufgefasst werden, wie in Abbildung 4 dargestellt.



Seite 22 von 49


Gerade um die Entstehung föderierter Szenarien zu begünstigen, sind mehrstufige Schemafestlegungen zu empfehlen. Ein Kern-Schema (XSD-Datei) sollte sehr all-gemein gehalten sein und bildet so mit seinen Generellen Attributen die innerste Schale, die der AS jeder TD unterstützen muss. Damit wird eine minimale gemein-same Schnittstelle für die Daten aller AS bereitgestellt.

Die Erweiterten Attribute der nächsten Schale sind für eine Gruppe von TDs not-wendig, die eine konkrete Fachlichkeit oder Nutzergruppe repräsentieren (z.B. „e-lektronischer Rechtsverkehr“). Für die Realisierung des SAFE müssen z.B. alle Att-ribute festgelegt sein, die der EGVP-Client fordert und die im aktuellen Registrie-rungsserver gespeichert sind.

Außen auf dem Schalenmodell finden sich die Speziellen Attribute. Diese sind nur für eine einzige TD relevant, so könnte für einen Rechtsanwalt zusätzlich der Fachanwaltstitel oder das Rechtsgebiet gespeichert werden.

Abbildung 4 : Beispiel für das Schalenmodell der Attribute.

Die genaue Festlegung der Attribute sowie ihrer Gliederung in Schalen ist eine fachliche und nicht-technische Entscheidung. Der Gesamtumfang der Attribute fürs SAFE ist durch die Inhalte des aktuellen Registrierungsservers gegeben. Diese In-halte müssen dann auf die einzelnen Schalen abgebildet werden. Das Format bzw. XML-Schema zur generellen Abbildung von Attributen und ihren Werten kann aber bereits definiert werden. Dies sollte in enger Abstimmung mit dem XÖV-Kerndaten-satz erfolgen.


Seite 23 von 49


Ein für diesen Zweck geeignetes, generisches XML-Schema stellt die Definition zu SAML-Assertions6 dar (aus OASIS-Standard zu SAML 2.0). SAML-Assertions als XML-basiertes Format für Attribute bietet folgende Vorteile:

• Generisches, aber formales Konzept zur Abbildung der kennzeichnenden Iden-titätsbezeichner, das auf einer Reihe unterschiedlicher Identitätskonzepte ba-sieren kann (z.B. X.509, Windows-Domäne oder E-Mail).

• Schemaelemente der Attribute selbst beinhalten sowohl sprechende Namen als auch URI-bezogene Identifikatoren. URI-Bezogenheit ist wichtig für die Federa-tion-Metadata von WS-Federation.

• Dasselbe Schema wird verwendet für die SAML-Token, die durch WS-Security beschrieben und vom Identity Provider herausgegeben werden (siehe Abschnitt �5.3.3). Somit wäre ein einheitliches Schema für Attribut-Anfrageergebnisse und Security-Token gegeben.

• SAML-Assertions sind perfekt integrierbar mit XACML, einer OASIS-spezifizierten Sprache, mit deren Hilfe die Zugriffsberechtigung auf die Attribute ausgedrückt werden kann.

Ein Beispiel für einen (unvollständigen) Datensatz für Attribute zu einem Nutzer gemäß SAML-Assertions in Version 2.0 ist im Folgenden dargestellt.

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

ID="_33776a319493ad607b7ab3e689482e45"

Version="2.0"

IssueInstant="2007-06-07T20:31:41Z">

<saml:Issuer>http://wwww.SAFE.de/AttributeService</saml:Issuer>

<saml:Subject>

<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">3f7b3dcf-1674-4ecd-92c8-1544f346baf8</ saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>

</saml:Subject>

<saml:AttributeStatement>

<saml:Attribute FriendlyName="Name">

<saml:AttributeValue xsi:type="xs:string">Krause</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute FriendlyName ="ChristianName">

<saml:AttributeValue xsi:type="xs:string">Harald</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute FriendlyName ="City">



Seite 24 von 49


<saml:AttributeValue xsi:type="xs:string">Altenholz</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute FriendlyName ="ZipCode">

<saml:AttributeValue xsi:type="xs:string">24161</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute FriendlyName ="Street">

<saml:AttributeValue xsi:type="xs:string">Altenholzer Straße

</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

5.3.3 Identity Provider (IP)

Das Vertrauenskonzept innerhalb einer Vertrauensdomäne basiert auf dem inter-nationalen Standard WS-Trust. Nach WS-Trust ist der IP das zentrale Element in einer Vertrauensdomäne, um vertraulichen Nachrichtenaustausch zu ermöglichen, und repräsentiert damit die Domäne. In WS-Trust ist festgelegt, welche Nachrich-ten ein IP verschickt und über welche Methoden die Services einer TD sich gegen-seitig authentisieren. Dazu werden nach WS-Trust standardisierte SOAP-Nachrichten (RequestSecurityToken, RequestSecurityTokenResponse) zwischen IP und anderen Services und Clientanwendungen ausgetauscht.

Nach den WS-* Spezifikationen basiert die Sicherheit innerhalb der vorgestellten Architektur auf Sicherheits-Token. Dies sind verschlüsselte und signierte Datenblö-cke, die Claims enthalten können. Claims treffen Aussagen über den angemelde-ten Benutzer wie beispielsweise Name, Zertifikat-Herausgeber, Rolle oder E-Mail-Adresse. Sie entsprechen z.B. den vom AS zu einer Identität veröffentlichten Attri-buten. Die Claims können aus dem Active Directory, einem anderen Identity-Store oder auch aus einem eingehenden Token (claim mapping) bezogen werden.

Der Identity Provider hat innerhalb der TD folgende zentrale Rollen, die auch in Abbildung 5 verdeutlicht werden:

1. Token Verification Verifikation von den Sicherheitstoken, die von der OASIS für den WS-Security Standard profiliert sind. Dies sind SAML-, X509-, Kerberos- und Username-Token. Welche Token konkret zu unterstützen sind, hängt von den jeweiligen Erfordernissen der Anwendung ab. So könnte beispielsweise das CardSpace-Token in einigen Szenarien eine Alternative zu Benutzername/Passwort sein.

2. Claim Mapping Über das Mapping (Umsetzen) von Claims kann der IP einem Nutzer z.B. auf Basis seines Login-Namens oder seines Zertifikat-Herausgebers eine Rolle zu-weisen und seine E-Mail-Adresse nachschlagen. Diese Informationen werden dann in einem neuen Token als Claim zurückgesendet. Es findet also ein Aus-


Seite 25 von 49


tausch des „Login-Claims“ gegen das „Role-Claim“ und das „E-Mail-Claim“ statt. Dazu hat der IP die Möglichkeit, beim Identity-Store Informationen über den sich anmeldenden Nutzer abzufragen.

3. Token Exchange Verifikation eines eingehenden Token und Ausgabe eines neu erstellten SAML-Tokens mit entsprechenden Claims.

Abbildung 5 : Der Identity Provider (IP).

5.3.4 Registrierungsprozess

Um als Identität in einer TD aufgenommen zu werden, muss sich ein Nutzer bei der TD registrieren lassen. Wie eine solche Aufnahme vorgenommen wird, beschreibt der Registrierungsprozess.

Differenzierte Stufen einer sicheren Online-Identifizierung sind wie folgt geplant: (o-rientiert am E-Government-Plattformen wie dem „HamburgGateway“):,

• Online-Registrierung unter Angabe des vollen Namens und der postalischen Anschrift sowie einer E-Mail-Adresse (Stufe 1). Abschluss der Registrierung über einen per E-Mail zugesandten Link.


Seite 26 von 49


• Online-Registrierung wie in Stufe 1 sowie zusätzlich Angabe des Geburtsda-tums und Abgleich der Daten mit Bundespersonalausweis in einem Kunden-zentrum (Stufe 2)

• Online-Registrierung wie in Stufe 2 sowie Besitz einer qualifizierten elektroni-schen Signatur (Stufe 3, noch nicht realisiert)

Neben der Registrierung von Privatpersonen besteht ein besonderes mehrstufiges Verfahren für Behörden, Standesorganisationen, Interessenvertretungen und Fir-men, in dem insbesondere ein „Masteruser“ legitimiert wird, Beschäftigte seines Unternehmens selektiv für bestimmte und u.U. kostenpflichtige Dienste frei zu schalten oder Mitglieder einer Standesorganisation rollengemäß für bestimmte Dienste zuzulassen.

Neben diesen konkreten Möglichkeiten sind aber auch beliebige weitere Registrie-rungsprozesse mit unterschiedlichen Sicherheitsstufen denkbar, beispielsweise:

• Online-Registrierung ohne Identitätsnachweis (sehr unsicher).

• Online-Registrierung mit Freischaltung nach telefonischer Bestätigung (unsi-cher).

• Online-Registrierung mit Freischaltung nach Faxen eines Identitätsnachweises (unsicher).

• Registrierung von Nutzern innerhalb einer Windows-Domäne ohne erneute Ü-berprüfung des Windows–Login (sicher).

• Persönliche Anwesenheit und Identitätsnachweis zum Erhalt einer Chipkarte mit persönlichem Zertifikat, das zusammen mit einer PIN zur Authentisierung genutzt werden muss (sehr sicher).

Da über die unterschiedlichen Registrierungsprozesse unterschiedliche Sicher-heitslevel erzielt werden können, sollte sich die Rolle des Benutzers an der Sicher-heit der Registrierung orientieren. Diese Rolle entscheidet später über die Zugriffs-rechte des Nutzers auf bestimmte Services und Daten. Wer für wen und unter wel-chen Bedingungen welche Rollen festlegen darf, muss organisatorisch in Betrei-bermodellen für IP festgelegt werden.

5.3.5 Fachliche Services

Innerhalb einer TD werden im Allgemeinen auch fachliche Services angeboten, die mit dem IP der TD eine Vertrauensbeziehung unterhalten. Fachliche Services er-warten bzw. fordern ein Sicherheits-Token, das von ihrem IP herausgegeben wur-de und daher vertrauenswürdig ist. Anhand der im Token zugesicherten Attribute des Dienstnutzers kann die Service-Implementierung den Zugriff autorisieren.

Ein Beispiel für einen fachlichen Service im SAFE-Umfeld wird künftig der OSCI 2.0-Intermediär bzw. das OSCI 2.0-Postfach sein. Mit dem OSCI 2.0-Intermediär wird es voraussichtlich möglich sein, für eine Auswahl von Empfängerpostfächern


Seite 27 von 49


nur bestimmter Sender (z.B. Mitglieder bestimmter TDs oder Inhaber einer be-stimmten Rolle) zuzulassen.

Der OSCI 1.2-Intermediär wird aber ebenso integriert werden. Hierfür wird wie bis-her ein OSCI-Empfänger-Zertifikat vom AS bezogen.

Abbildung 6 : Postfächer, die nur Post von Meldebehörden empfangen.

5.3.6 Clients für Fachanwendungen

Clients für Fachanwendungen sind direkt einer TD zugeordnet. Ein Client kann auch mit mehreren TDs kooperieren, dann muss aber bei der Benutzeranmeldung eindeutig entschieden werden, an welcher TD sich der Nutzer authentisiert. Mit der Authentisierung beim IP dieser TD wird eine Vertrauensbeziehung zwischen Client und IP hergestellt.

Im Registrierungsprozess wird festgelegt, wie sich ein Nutzer am Client und damit an seinem IP authentisieren kann. Bei der Registrierung ausgegebene oder festge-legte Zertifikate oder PINs werden nun zur Anmeldung verwendet. So sind, wie o-ben beschrieben, verschiedene Anmeldeverfahren wie Benutzername/Passwort, mit X.509-Zertifikat oder ohne erneute Anmeldung via Kerberos möglich. Ein Bei-spiel für eine Clientanwendung ist der EGVP-Client. Dieser muss aus seiner Konfi-guration erkennen, welcher TD der Nutzer zugeordnet ist sowie die URL deren IP. Die Anmeldung beim AS erfolgt dann über diesen IP.

Um diese Funktionalität unter Beibehaltung der bereits bestehenden EGVP-Anmeldung zu unterstützen, ist lediglich die Schnittstelle des EGVP-Clients zum Attribute-Service neu zu realisieren. Eine Anpassung der Benutzerregistrierung, die verschiedene Sicherheitsstufen unterstützt, sollte in einem zweiten Schritt aber e-benfalls vorgenommen werden.


Seite 28 von 49


5.4 Trust-Domain-übergreifende Konzepte

Die Implementierung des SAFE erfordert evt. bei weiter steigenden Nutzerzahlen den Einsatz mehrerer TDs, so dass dann eine TD übergreifende Kommunikation stattfin-den müsste.

Durch Föderation werden mehrere TDs zu einem „Circle Of Trust“ zusammenge-schlossen. Die IPs der TDs unterhalten in diesem „Circle Of Trust“ gegenseitige Ver-trauensbeziehungen und ermöglichen so Single-Sign-On (SSO). Ein Benutzer muss sich dann nur ein einziges Mal am System anmelden, um fachliche Services aus be-liebigen TDs innerhalb des „Circle Of Trust“ zu nutzen.

5.4.1 Vertrauen zwischen Trust-Domains

Per Definition vertrauen alle Services, die zu einer Trust-Domain gehören, deren IP (bzw. dem Token-Herausgeber). Eine Vertrauensbeziehung zwischen den TDs ist darüber hinaus nötig, damit ein Client aus einer TD einen Service einer fremden TD nutzen kann. Diese Vertrauensbeziehung wird über den Standard WS-Federation hergestellt. Zentrales Element einer Federation Architektur ist das Fe-deration-Metadata-Dokument, hier werden die technischen Feinheiten des domä-nenübergreifenden Vertrauenskonzeptes festgelegt.

Im vorliegenden Konzept wird für jede TD ein Federation-Metadata-Dokument er-stellt. Dieses wird vom IP der TD bereitgestellt und enthält Informationen zu allen Services der TD. In diesem Dokument werden für jeden Service der TD die folgen-den Festlegungen getroffen:

• Welche Token-Herausgeber werden von einem Service akzeptiert und wie sind die Vetrauensbeziehungen?

• Wie müssen Sicherheitstoken für diesen Service signiert sein?

• Wie sind die URLs der Services, insbesondere von IP und AS?

• Welche Claims sind in der Föderation bekannt?

• Welche Token-Arten werden von Services der Föderation akzeptiert?

• Wo können die WSDL-Metainformationen für die Services abgerufen werden?

Zentral ist dabei die Frage, welche Token-Herausgeber (Issuer) ein Service akzep-tiert und welchen er vertraut. Da die bekannten Token-Herausgeber auch IPs einer anderen TD sein können, wird eine domänenübergreifende Vertrauensbeziehung im Allgemeinen über IPs aufgebaut. Damit können transitive Vertrauensbrücken über mehrere Partner geschaffen werden, wie in Abbildung 7 dargestellt wird.


Seite 29 von 49


Abbildung 7 : Domänenübergreifende Vertrauensbeziehungen.

Zur domänenübergreifenden Kommunikation zwischen IPs werden SAML-Token genutzt, die vom IP der Senderdomäne signiert werden. Der IP fügt dem Token ein sogenanntes Proof-Token hinzu, das so verschlüsselt wird, dass nur der IP der Empfängerdomäne sie entschlüsseln und lesen kann, und dem Client als Nach-weis des rechtmäßigen Besitzes des Tokens dient.

Zur Ausgabe solcher SAML-Token ist eine Vertrauensbeziehung zwischen den IPs der einzelnen Domänen notwendig.

Der Aufbau dieser Vertrauensbeziehungen wird über X509-Zertifikate realisiert. Für jeden IP muss also ein eigenes X509-Zertifikat von einer vertrauenswürdigen PKI herausgegeben werden.

Durch Vermittlung der IPs werden eine Vertrauensbeziehung und ein Sicherheits-kontext zwischen Client und fachlichem Service aufgebaut. Über diesen Sicher-heitskontext können die Partner direkt miteinander kommunizieren, ohne Umweg über die IPs; dies ist im Standard WS-SecureConversation beschrieben. Zur direk-ten Kommunikation benutzen sie einen symmetrischen Schlüssel der über die IPs ausgehandelt wurde. In Abbildung 8 wird die Federation-Beziehung zwischen zwei TDs und die Kommunikationsschritte zum Aufbau einer sicheren Kommunikation anschaulich dargestellt.


Seite 30 von 49


Abbildung 8 : Identity Federation – Vertrauen zwischen Trust Domains.

5.4.2 Meta-Attribute-Service

Die beschriebene Architektur sieht eine Verteilung der Daten auf Identity-Stores verschiedene TDs vor und keine Replikation oder Datenredundanz. Um einen „Circle of Trust“ einem anfragenden Client als ein logisches Gebilde präsentieren zu können, ist ein übergreifender Attribut Service erforderlich, der eine Attributan-frage an mehrere oder alle Attribute-Services beliebiger TDs verteilt und die Ant-worten zusammenfasst und sortiert – der Meta-Attribute-Service. Alternativ kann ein Client auch gezielt Anfragen an die Attribute-Services der einzelnen TDs rich-ten.

Entscheidendes Merkmal ist, dass die Schnittstelle des Meta-Attribut-Services i-dentisch ist zu der des einfachen Attribut-Services7 (SPML-Standard). Für einen anfragenden Client ist es transparent, ob es sich um einen Meta- oder einfachen

7 Definitive Festelegung, siehe Tabelle in Abschnitt �9


Seite 31 von 49


Attribut-Service handelt. Tatsächlich kann der Meta-Attribute-Service durch diesel-be SPML-Service-Instanz (SPML-Provider) bedient werden, die auch den realen, einfachen Attribut-Service stellt. Lediglich das Target in der Anfrage gibt an, dass statt des einfachen, realen der virtuelle und verteilte Meta-Attribute-Services ad-ressiert wird. Das Konzept ist vergleichbar mit dem der „Virtual Directories“; es ent-steht aber eine Vereinfachung durch die Beschränkung auf genau eine Schnittstel-lenimplementierung.

Die Identität des ursprünglichen Anfragers zum Zwecke der Autorisierung bleibt bei der Weiterleitung der Anfrage erhalten („sender-vouches Methode“ von WS-Security). In Abbildung 9 wird der Meta-Attribute-Service anschaulich dargestellt. Um die Abbildung zu vereinfachen, wurde auf Darstellung der IPs verzichtet. Den-noch muss auch der Meta-Attribute-Service sich beim Zugriff auf die Attribut Servi-ces der unterschiedlichen TDs über den jeweiligen IP autorisieren.

Abbildung 9 : Der Meta-Attribute-Service als übergeordneter Attribute Service.

5.4.3 Granularität von Trust-Domains

Trust-Domains repräsentieren Einrichtungen, die organisatorische, rechtliche und technische Regelungen verantworten. Unterschiedliche Motive können die Bildung einer Trust-Domain nahelegen. Benutzergruppen, die durch Verbände, Kammern und Vertretungen oder durch hoheitliche und verwaltungsspezifische Aufgaben und Ver-antwortlichkeiten ausgezeichnet sind, können den Betrieb einer autonomen Trust-Domain sinnvoll oder erforderlich machen. Auf der anderen Seite können betriebwirt-schaftliche Gründe zu einer umfassenderen Nutzung gemeinsamer Infrastruktur auch mit einer höheren Anzahl von Nutzern sprechen.


Seite 32 von 49


Die Bildung von Trust-Domains wird sich letztendlich durch Kompromisse zu den kon-kurrierenden Gesichtspunkten Wirtschaftlichkeit und Autonomie entwickeln. Die Form, in der dies geschehen wird, ist heute nur schwer vorherzusagen. Im Interesse einer guten Funktionstüchtigkeit von verteilten Gesamtsystemen („Circle of Trust“) ist eine zu feine Granularität von Trust-Domains, in der z.B. jedes Gericht eine eigene Domain bildet, sicher nicht vorteilhaft. Das Management der Vertrauens-beziehungen bei einer hohen Anzahl kleiner Domains wird komplexer; auch sind stark verteilte Anfragen über den Meta-Attribute-Service ressourcen-intensiver. Auf der anderen Seite kann die Infrastruktur zu großer Trust-Domains vor Last- und Performance-Probleme gestellt werden. Auch kann die unspezifische Zusammenfas-sung großer Benutzergruppen innerhalb einer Trust-Domain, die dann durch deren Attribute-Service als ein globales „Adressbuch“ präsentiert werden, vom Anwender als wenig komfortabel empfunden werden. Eine günstige Granularität von Trust-Domains wird durch die jeweiligen Geschäftpro-zesse und den damit verbundenen Kommunikationsverhaltensweisen bestimmt. Als grobe Orientierung sollte aus heutiger Sicht die Anzahl der von einer Trust-Domain verwalteten Identitäten zwischen 1.000 und 100.000 liegen.


Seite 33 von 49


6 SAFE als konkrete Umsetzung des Deutschland-Online-

Architekturkonzeptes

Während in Abschnitt 4 die Architektur für eine Deutschland-Online Registrierung skizziert wurde, soll in diesem Abschnitt die konkrete Ausgestaltung dieses Archi-tekturkonzeptes für das SAFE beschrieben werden. Folgende Fragen sollen hier beantwortet werden:

• Wie wird das Deutschland-Online-Konzept im SAFE umgesetzt?

• In welchen Schritten kann die Umsetzung erfolgen?

• Wie wird eine Aufteilung in mehrere TDs realisiert?

• Welche Komponenten sind in den TDs für das SAFE umzusetzen?

• Welche Beziehungen bestehen zwischen den einzelnen Systemkomponenten?

• Wie registrieren sich die unterschiedlichen Benutzergruppen bei ihrer TD?

• Was sind die fachlichen Anforderungen?

• Wie wird die Migration erfolgen?

6.1 Konkrete Umsetzung für den SAFE

Für eine Umsetzung des EGVP-Registrierungsservers (LDS) auf das neue System ist folgendes Vorgehen geplant, das je nach aktueller Anforderung in einer Basis-umsetzung und zwei Ausbaustufen realisiert werden kann. Die Ausbaustufen sind voneinander unabhängig und können je nach Anforderung in beliebiger Reihenfol-ge erfolgen.

Im Vergleich zum bisherigen System wird in der letzten Ausbaustufe ein Konzept umgesetzt sein, dass sich folgendermaßen ins OSCI-Umfeld einfügt:

• Betrieb eines Intermediärs pro TD, wobei die Nutzer einer TD diesem Interme-diär fest zugeordnet sind und ihre Postfächer dort betreiben. Einzelne Nutzer können auch ihren eigenen Heim-Intermediär betreiben, falls dies notwendig ist. Dann sind sie diesem Heim-Intermediär ebenfalls fest zugeordnet. Es ist auch möglich innerhalb einer TD mehrere Intermediäre zu betreiben, eine feste Zu-ordnung der Nutzer bleibt aber bestehen.

• Betrieb eines Attribut Services und damit eines Datenspeichers pro TD. Die Nutzer der TD sind auch dem AS fest zugeordnet. Ihre Daten liegen damit in genau dieser einen Datenbank. Eine Replikation der Daten zwischen verschie-denen TDs findet nicht statt.


Seite 34 von 49


6.1.1 Basisumsetzung

Die Basisumsetzung ist sehr schlank gehalten. Zunächst sollte nur eine einzige Trust Domain entwickelt werden, die zentral beim LDS betrieben wird. Die zu imp-lementierenden Komponenten sind Attribute Service (AS) und Identity Provider (IP). Des Weiteren muss beim LDS ein OSCI1.2-Intermediär betrieben werden, der Postfächer für Nutzer ohne eigenen Home-Intermediär bereitstellt. Registrierungs-prozesse werden wie bisher vom EGVP-Client abgewickelt, so dass hier keine Än-derung nötig ist. Der Leistungsumfang dieser Ausbaustufe ist fast identisch mit der des aktuellen Registrierungsservers. Zusätzlich ist es aber möglich, durch Rollen-vergabe die Datenzugriffsrechte verschiedener Nutzgruppen detaillierter als bisher anzupassen. Die Basisumsetzung ist schematisch in Abbildung 10 dargestellt.

Abbildung 10 : Basisumsetzung des SAFE.

Zur Umsetzung dieser Ausbaustufe fallen die folgenden Arbeiten an:

• Entwicklung eines Identity Providers Dieser wird nach dem WS-Trust-Standard entwickelt. Er ist in der Lage, Nutzer zu authentifizieren, die über einen EGVP-Client eine Anfrage stellen und weist ihnen eine Rolle zu. Der Identity Provider besteht aus dem Token-Herausgeber (Security Token Service, STS) und dem Identity-Store (Datenbank).


Seite 35 von 49


Für die konkrete Umsetzung des SAFE empfiehlt dieses Konzept ein relationa-les Datenbanksystem für die Datenspeicherung8 (Identity-Store) zu verwenden. Das hat gegenüber LDAP die folgenden Vorteile:

1. Relationale Datenbanksysteme können die Einhaltung der referentiellen Integrität selbsttätig garantieren.

2. Änderungen an den Daten lassen sich transaktional durchführen. Da-durch wird bei Fehlern im Änderungsprozess ein Rollback möglich.

3. Die Recovery-Funktionalität ist bei relationalen Datenbanken fortschrittli-cher. Nach Systemcrashes können relationale Datenbanken einen kon-sistenten Systemzustand wieder herstellen.

4. Als Zukunftsoption für die Nutzung strukturierter Attribute sollten die ein-gesetzten Datenbanksysteme XML-fähig sein. Solche Datenbanksyste-me unterstützen das Konzept, Attribute über XML-Schemata festzule-gen. Selektive (XPath-)Anfragen können somit auf strukturierten Attribu-ten filtern.

5. Die Schnittstelle des Attribut-Service ist als SPML über SOAP/http vor-gesehen - LDAP als Zugriffsprotokoll durch die Clients ist daher ohnehin nicht vorgesehen. Das LDAP-Protokoll ist auch nur bedingt Internet- bzw. Firewall-fähig, da der LDAP-Port in der Regel für den Zugang ins Internet nicht freigeschaltet ist.

• Entwicklung eines Attribute Service Der Attribut Service stellt die Schnittstelle für die Verzeichnisabfragen dar. Er wird als Implementierung eines SPML-Providers für lesende Operationen (loo-kup, search, listTargets) auf die Datensätze der Trust-Domain umgesetzt. Für den Zugriff auf den AS muss eine Authentisierung beim IP stattfinden. Durch die vom IP vergebene Rolle wird der Benutzer dann für den Zugriff auf be-stimmte Adressdatensätze und Attribute autorisiert.

• Anpassung des EGVP-Clients Am EGVP-Client muss die Schnittstelle für die Benutzerregistrierung und die Adressbuchabfrage angepasst werden. Die Kommunikation erfolgt nach WS-Trust über den IP.

6.1.2 Erste AusbaustufErneuerung der Benutzerregistrierung

Für die Vertrauenswürdigkeit einer Trust-Domain ist die Qualität des Registrie-rungsprozesses von entscheidender Bedeutung. Möglich ist, dass unterschiedlich starke Prozesse und Mechanismen für die Nutzerregistrierung innerhalb einer TD zum Einsatz kommen, sofern die Nutzer unterschiedlichen Rollen zugeordnet wer-



Seite 36 von 49


den. Ziel eines jeden Registrierungsprozesses ist es, die Identität der zu registrie-renden Person oder Institution verifizieren zu können.

Beispiele für Verfahren sind:

• Verifikation der angegebenen E-Mail-Adresse durch Zustellung einer E-Mail mit vom Registrierungsprozess generierten URL-Erweiterung („Geheimnis“). Der Nutzer weist im folgenden Prozessschritt die Kenntnis der URL-Erweiterung nach (i.d.R. durch Aufruf der URL).

• Bestätigung der Identität durch elektronische Signatur des Registrierungs-Requests mit Zertifikaten von vertrauten Herausgebern.

• Überprüfung der Identität durch persönliches Erscheinen und Vorlage des Per-sonalausweises bei einer autorisierten Instanz (z.B. Bürgerbüro).

Sofern für die Registrierung qualifizierte elektronische Signaturen verwendet wer-den, kann der Registrierungsprozess optional die Zugangseröffnung für die rechts-verbindliche elektronische Kommunikation nach VwVfG integrieren. Eine erklärte und verifizierte Zugangseröffnung sollte dann durch ein Attribut gekennzeichnet werden.

Eine Erneuerung des Registrierungsprozesses ermöglicht auch, die differenzierte und verfeinerte Zuordnung von Rollen oder Rechten (z.B. Differenzierung von „Rechtsanwalt“ und „Notar“). Da diese Attribute auch in den Security-Token (SAML-Token) eingebettet werden können, ermöglicht dies fachlichen Services ei-ne erweiterte Kontrolle über den Datenzugriff.

Implementierungen für Registrierungsprozesse sollten als austauschbare System-erweiterungen ausgelegt sein („pluggable“). Alle Prozessimplementierungen (z.B. in Form von Workflows) sollten daher eine einheitliche, interne Schnittstelle für das Einstellen neuer Registereinträge bedienen (z.B. die add-Operation einer SPML-Schnittstelle).

Für eine Umsetzung ist eine Anpassung des EGVP-Clients nötig. Dabei ist es unerheblich, ob die Registrierung im EGVP-Client verbleibt, oder ob sie getrennt davon stattfindet. Eine Ausgliederung der Registrierung ist schematisch in Abbil-dung 11 dargestellt.


Seite 37 von 49


Abbildung 11 : Umsetzung des SAFE, 1. Ausbaustufe.

Sollte die Registrierung aus dem EGVP-Client entfernt werden, ist die Entwick-lung einer eigenständigen Registrierungsanwendung notwendig.

6.1.3 Zweite AusbaustufAusgliederung von Teilen der Daten in neue TDs

Diese Ausbaustufe beschreibt die anspruchsvolleren und aufwändigeren Schritte. Sie ermöglicht eine flexible Skalierung des Systems, da bei steigendem Datenvo-lumen Teildatenbestände ausgegliedert und auf andere Betreiber zu übertragen wären. Hier kommt die Pragmatik und Flexibilität des Konzeptes zum Tragen.

Ein Beispiel wäre, Notare in eine eigene TD auszugliedern und den Betrieb bei der Bundesnotarkammer aufzusetzen. Dieses Beispiel soll im Folgenden die entste-hende Architektur verdeutlichen. Abbildung 12 zeigt die Komponenten und Bezie-hungen dieser dritten Ausbaustufe bei Ausgliederung der Notardatensätze.

Ein anderes Beispiel wäre der Ausbau von Bürger-Portalen zu eigenen TDs. Damit wäre es nach entsprechender Vergabe von Benutzerrollen möglich, sich über Bür-ger-Portale für EGVP zu registrieren, zu authentisieren und zu autorisieren.


Seite 38 von 49


Abbildung 12 : Umsetzung des SAFE, 3. Ausbaustufe; Ausgliederung der Notare.

Zur Umsetzung dieser Ausbaustufe fallen die folgenden Arbeiten an:

• Verteilung des Datenbestandes Der Datenbestand muss möglichst unterbrechungsfrei auf zwei Attribut-Services verteilt werden. Dabei ist kurzfristig eine doppelte Datenhaltung mög-lich, bis alle Clientanwendungen umkonfiguriert sind. Ein detailliertes Migrati-onskonzept muss hier ausgearbeitet und getestet werden. Zum Beispiel wäre die Vergabe eines „Migrations-Tokens“ möglich, womit der Client selbst die Mig-ration seiner Daten auf die andere TD vornimmt. Bei mehreren Client-Anwendungen (Anwalts-Fach-Software zum Senden bestimmter Vorgänge, EGVP zum Empfang von Nachrichten) müssen alle Anwendungen entspre-chend umkonfiguriert werden. Nach der Aufteilung der Daten hat jeder Nutzer seine Heim-TD9, bei der er sich authentisiert. Der Notar meldet sich dann also bei der Notarkammer-TD an, alle anderen Nutzer weiterhin beim LDS.

• Erweiterung der Domänenarchitektur auf WS-Federation Für den Schritt von einer zu mehreren TDs ist es nötig, die Architektur um die WS-Federation-Spezifikation zu erweitern. Dadurch wird es möglich, Vertrau-ensbeziehungen zwischen den Domänen aufzubauen. Wie in Abbildung 7 ge-zeigt, besteht die Vertrauensbeziehung dabei immer zwischen den IPs der Do-mänen. Diese können die Nutzung von Services aus anderen TD erlauben. Wie



Seite 39 von 49


bereits in Abschnitt �5.4.1 dargestellt, sind dazu einige Änderungen an den Ba-siskomponenten nötig:

o Der IP muss ein Federation Metadata Dokument bereitstellen10, in dem domänenübergreifende Vertrauensbeziehungen beschrieben sind. Wei-tere Anpassungen am IP sind erforderlich, um domänenübergreifend Kommunikationskanäle nach WS-SecureCommunication aufzubauen.

o Für Services, die domänenübergreifend kommunizieren sollen, müssen neue Schnittstellen entwickelt werden, die diese Federation-Metadaten nutzen.

• Entwicklung eines Meta Attribute Service Der Meta Attribute Service nimmt Adressanfragen entgegen und verteilt diese auf die eigentlichen Attribute Services, danach bündelt er die Antworten und sendet sie an den Client. Es wird nur ein zentraler Meta-Attribute-Service beim LDS in der LDS-TD aufgesetzt.

• Anpassung des EGVP-Clients Am EGVP-Client müssen - in Abstimmung mit dem LK EGVP - die Schnittstel-len angepasst werden, es muss konfigurierbar sein, bei welcher TD sich der Nutzer anmeldet. Diese sollte fest eingestellt sein als Heim-TD des Benutzers. Auch der fest zugeordnete Intermediär muss entsprechend der Benutzer-TD in der Clientanwendung umgestellt werden.

• Anpassung der Registrierung Das Registrierungsverfahren muss entscheiden, an welcher TD sich ein Nutzer anmeldet und in welchem Identity-Store seine Daten abgelegt werden. Es er-scheint sinnvoll, für jede TD ein eigenes Registrierungsverfahren festzulegen und zu entwickeln, dessen Sicherheit und Ablauf auf die speziellen Bedürfnisse der zugrundeliegenden Personengruppe abgestimmt ist.

Die zweite Ausbaustufe baut zumindest insofern auf der ersten auf, dass die Re-gistrierung angepasst werden muss.

6.1.4 Erweiterungen

Zusätzlich zu den Ausbaustufen sind noch Erweiterungen des EGVP-Client Funkti-onsumfangs denkbar wie z.B. eine Favoritenliste von lokal gehaltenen Adressen. Sie könnte die aufwendige Replizierung des gesamten Adressbestandes ablösen. Diese Funktionalität müsste im EGVP-Client separat erstellt werden und wird hier nicht betrachtet. Sie ist aber mit dem beschriebenen Konzept leicht umsetzbar.

10 Vorläufig Festlegung, siehe Tabelle in Abschnitt �9


Seite 40 von 49


6.2 Nutzergruppen, Rollen und Zugriffsrechte für das SAFE

Da zunächst alle SAFE-Nutzer beim LDS in einer zentralen TD verbleiben, wird ei-ne Unterteilung von Nutzergruppen in TDs zunächst offen gelassen. Diese Unter-teilung wird sich später im Betrieb aus konkreten Erfordernissen ergeben. Dies wä-re beispielsweise der Fall, wenn weitere Nutzerverzeichnisse von Bürger-Portalen eingebunden werden und einzelne Nutzer über die Portalsregistrierung EGVP-Dienste benutzen möchten. Ein denkbarer Fall ist auch, dass ein Bundesland eine eigene TD zur Registrierung seiner Bürger aufbaut, um die zentrale Registrierung beim LDS zu entlasten. Dazu wäre dann eine Aufteilung des Datenbestandes not-wendig.

6.2.1 Rollen

Die konkrete fachliche Rolleneinteilung erfolgt in einem späteren Schritt. Die hier vorgeschlagene Rolleneinteilung soll eher eine Möglichkeit als ein fertiges Konzept aufzeigen. Mögliche Rollen sind:

• Gerichte

• Behörden

• Bürger

• Unternehmen / Organisationen

• Rechtsanwälte

• Notare

6.2.2 Attribute

Die Attribute sollten sich auch im Hinblick auf eine Migration der Daten an den Att-ributen orientieren die im SAFE-Registrierungsserver gespeichert sind. Benötigt werden:

• Benutzer-ID

• Visitenkarte (mit persönlichen Informationen wiName, Adresse, E-Mail, …)

• Verschlüsselungszertifikat des OSCI-Empfänger-Postfaches

• Rolle des Benutzers

• Domänenname des Benutzers

• URL des OSCI-Intermediärs

• X-Justiz.ID z.B.. für Handelsregister und Mahnsachen

Wie diese Attribute auf das in Abschnitt �5.3.2 beschriebene Schichtenmodell ab-gebildet werden, muss im Feinkonzept erarbeitet und spezifiziert werden.


Seite 41 von 49


6.2.3 Zugriffsrechte der Nutzergruppen

Über die Rolle können Einschränkungen definiert werden hinsichtlich der Sichtbar-keit von Adressdatensätzen und Attributen. Es kann auch die Nutzung verschiede-ner Services eingeschränkt werden.

Damit ist es möglich, eine Rolle für Nutzer zu schaffen, die nur Nachrichten an be-stimmte Postfächer senden dürfen. Die konkrete Zuteilung von Rechten auf die Rollen erfolgt in einem späteren Schritt. Auch Änderungsrechte an den Daten kön-nen über die Rollen abgebildet werden.

Mögliche Beispiele für eine Zugriffsbeschränkung sind:

• Bürger sehen nur Datensätze von Gerichten und zwar nur die Felder in denen Adressdaten und E-Mail-Adresse gespeichert sind. Weitere Felder wie z.B. Te-lefonnummern oder Namen der Ansprechpartner bleiben verborgen. Ebenso die Adressen anderer Bürger, Rechtsanwälte und Notare.

• Ein Administrator hat vollen Zugriff auf die Daten und kann alle Attribute und Datensätze lesen, schreiben, ändern und löschen.

• Ein Bürgerbüro hat die Möglichkeit, neue Datensätze mit der Rolle „Bürger“ an-zulegen. Ebenso hat es lesenden Zugriff auf alle Datensätze von Bürgern, aber nicht auf die von Notaren oder Rechtsanwälten.

6.3 Beziehungen zu DVDV

Zu dem Deutschen Verwaltungsdiensteverzeichnis (DVDV) bestehen Gemeinsam-keiten bei Ziel, Dateninhalten und Funktionalität zum hier beschrieben System. Dennoch unterscheiden sich die Systeme in ihrem primären Zweck; beide besitzen eine Existenzberechtigung.

Das DVDV ist ein Service Registry, das fachliche Dienste nach fachlichen Kriterien auffindbar macht und Daten zu deren Nutzung bereitstellt. Dienste (Services) in diesem Sinn sind wohl definierte Interaktionsstellen für Software-Systeme im Rah-men der Abarbeitung strukturierter Geschäftsprozesse (vgl. serviceorientierte Ar-chitektur, SOA).

Bei dem in diesem Papier skizzierten Verzeichnis handelt es sich dagegen um ein Identity Registry, indem Identitäten (natürliche Personen und auch Organisationen) verzeichnet sind. Diesen Identitäten sind Eigenschaften, Rollen und Rechte (Attri-bute) zugeordnet, die sie vornehmlich als Nutzer (von Diensten) beschreiben. Be-stimmte Attribute geben auch die Erreichbarkeit der Identität über Telefon, E-Mail oder OSCI-Postfächer an. Der eher unstrukturierte Empfang von E-Mail oder Nach-richten ins OSCI-Postfach stellt aber keinen Dienst im Sinne einer SOA dar.

Dennoch existieren Überschneidungen bei den Dateninhalten: Einträge zu Behör-den können in beiden Verzeichnissen auftreten, wenn sie Anbieter von (SOA-


Seite 42 von 49


artigen) Software-Diensten sind – allerdings mit unterschiedlichem Fokus und Zweck. Im Service-Registry DVDV treten Behörden als Wurzel für konkrete Dienst-implementierungen auf, um Schlüssel und Kategorien für die Auffindbarkeit der Dienste zu binden. Im Identity-Regsitry existieren sie mit ihren (und wegen ihrer) beschreibenden Daten wie Postanschrift, elektronische Postfächer, Rollen, Katego-rien usw..

Mittelfristig sind Beziehungen zwischen dem zentralen DVDV und dem SAFE so-wie anderen föderierten TDs sinnvoll. Die Methode verifyCategory des DVDV zur Überprüfung der Behördenkategorie könnte z.B. mittelfristig durch eine Anfrage am Attribut-Service der Behörde abgelöst werden, da die Methode nicht Services son-dern die Behörde in der Rolle Dienstnutzer betrifft.

Eine weitere mittel- bis langfristige Änderung könnte die automatisierte Übernahme von in TDs neu aufgenommenen Behörden nach DVDV sein (SchnittstellSPML), wenn die Behörden - zumindest potentiell - auch Anbieter von Diensten sind. Zu übertragen wären lediglich die Rumpfdaten (eindeutiger Identifizierer, Schlüssel und Kategorien), die im DVDV zur Erfüllung der Dienstsuche erforderlich sind. Die Autorisierung der DVDV-Pflege stützte sich dann auf den Identity-Provider der Heimat-TD der entsprechenden Behörde.

6.4 Beziehungen zu UDDI

UDDI (Universal Description, Discovery ans Integration) ist eine Spezifikation für einen Verzeichnisdienst zum Auffinden von Web-Services. Es handelt sich daher um eine Service-Registry-Technologie und keinen Ansatz für einen generellen Ver-zeichnisdienst.

Zwar beinhaltet UDDI ein Datenmodell zur Abbildung eines Verzeichnisses für In-stitutionen (businessEntity), das die Kontaktinformationen Name, Telefon, E-Mail und Postanschrift enthalten kann.

Es ist aber für die Belange von SAFE ungeeignet11, da die Kontaktattribute be-schränkt sind, Institutionen nur in der Rolle des Dienstanbieters betrachtet werden und keine Ansätze zur Föderation enthalten sind.

Tatsächlich enthielt die Version 1.0 der Spezifikation zu WS-Federation von 2003 eine nicht-normative Beschreibung zur Umsetzung des Attribute-Services mit UDDI. Dieser Umsetzungsansatz nutzte die generische Erweiterung von UDDI mit-tels tModel, indem jeder Identität ein eigener tModelKey zugeordnet werden sollte. In der aktuellen Version 1.1 zu WS-Federation von 2006 ist aber ausdrücklich von einer UDDI-Umsetzung des Attribut-Services wieder abgesehen worden. Die füh-renden Verfasser der Spezifikation bezeichneten die Verwendung von UDDI für diesen Zweck als Missbrauch.



Seite 43 von 49


6.5 Verfügbarkeiten, ServiceLevel

So lange alle Daten in einem einzigen AS beim LDS abgelegt sind, entscheidet die Verfügbarkeit der LDS-IP und des LDS-AS Services über die Verfügbarkeit des Systems. Bei einer Aufteilung des Datenbestandes auf mehrere TDs ist es mög-lich, die Ausfallsicherheit differenzierter zu steuern.

Für unterschiedliche Anwendungsszenarien sind unterschiedliche Anforderungen an die Ausfallsicherheit gegeben. Eine erhöhte Verfügbarkeit ist i. A. mit höheren Kosten verbunden, z.B. durch die Bereitstellung von Ersatzservern (hot standby) oder Clustersystemen. Durch die Aufteilung der Benutzergruppen in separate TDs ist es möglich, die Ausfallsicherheit für jede Gruppe gezielt festzulegen. Hohe Ver-fügbarkeit muss nur für die Prozesse bezahlt werden, für die sie notwendig ist. Die konkreten SLAs sind - im Lichte der derzeitigen Erfahrungen - noch auszuarbeiten.

6.6 Technische Standards und Schnittstellen

Da sich das SAFE an der Deutschland-Online-Architektur orientiert, sind die Stan-dards und Schnittstellen dort bereits vorgegeben und sollten wie oben beschrieben umgesetzt werden.

6.7 Datenschutzanforderungen

Dieser Abschnitt ist nicht abschließend ausgearbeitet.

(StichwortMitprüfung BSI)


Seite 44 von 49


7 Mengengerüst


7.1 Objekte des Verzeichnisses

Die im Juni 2007 registrierte Benutzer setzen sich folgendermaßen zusammen. Registriert sind:

Bürger: ca. 19.000

Slaves: ca. 900

Behörden: ca. 200

(StichwortAusgehend vom EGVP, Berücksichtigung Anforderungen DOL à Mit-prüfung durch BMI)

7.2 Mengengerüst Nutzer und Institutionen

(StichwortJustizzahlen ggf. mit Hinweis auf langfristige Zahlen im eGov/DOL à Mit-prüfung durch BMI)


Seite 45 von 49


8 Migration


8.1 Beschreibung EGVP-Inhalte die zu übernehmen sind

• Aufbau der TD Infrastruktur.

• Migration des Datenbestandes auf den Attribute Service

• Implementierung neuer Schnittstellen am EGVP-Client.

• Meta-Attribut-Service im LDS

• Schaffung weiterer TDs durch Ausgliederung eines Teils des Datenbestandes.

8.2 Beschreibung der EGVP-Client-Schnittstelle als grobe Leitlinie


Seite 46 von 49


9 Festlegungen und vorläufige Festlegungen

Vorläufige Festelegungen sind im Rahmen eines Feinkonzeptes ggf. durch proto-typische Implementierungen zu verifizieren. Definitive Festlegungen werden in die-sem Konzept als gesichert angesehen.

Nr. Klasse Abschnitt Festlegung

1 definitiv �3.4 Die Kernarchitektur basiert auf den WS-* Spezifikationen, insb. WS-Trust und WS-Federation.

2 definitiv �5.1 Das Konzept sieht eine zumindest potentielle Verteilung der Nutzerdaten auf mehrere Verzeichnisdienste vor. Die Daten der Verzeichnisse sind disjunkt, d.h. es ist keine Replikation vorgesehen.

3 definitiv �5.3 Die obligatorischen Dienste einer TD sind Identity-Provider und Attribut-Service.

4 vorläufig �5.3.1 Als Schnittstelle für die Verzeichnisanfrage wird SPML V.2 gewählt.

5 definitiv �5.3.2 Die Attribute einer TD werden durch mehrstufige XSD-Dateien beschrieben.

6 vorläufig �5.3.2 Als XML-Schema für die Definition der Attribute wird SAML-Assertions V. 2.0 verwendet.

7 definitiv �5.4.2 Die Schnittstellen von Attribut-Service und Meta-Attribut-Service sind identisch.

8 vorläufig �6.1.1 Als Identity-Store des SAFE wird ein relationales Daten-bankmanagementsystem vorgesehen.

9 definitiv �6.1.3 Jede Identität ist genau einer TD zugeordnet.

10 vorläufig �6.1.3 Zur präzisen Ausgestaltung der Föderation wird vom IP ein Federation-Metadata-Dokument veröffentlicht.

11 definitiv �6.4 UDDI ist als Attribut-Service-Schnittstelle ungeeignet.


Seite 47 von 49


10 Abkürzungsverzeichnis und Glossar

Abkürzung Erklärung Active Directory Verzeichnisdienst zur zentralen Verwaltung aller im Netzwerk

relevanten Ressourcen. AS Attribute Service – Schnittstelle zu Daten von Identitäten ei-

ner IP Claim Aussage, die über einen Nutzer getroffen wird, meist ein Att-

ribut des Nutzers. EGVP Elektronisches Gerichts- und Verwaltungspostfach. Identität Informationsabbild eines Individuums Identity Provider Service, der Aussagen zu Identitäten in Form von Token bes-

tätigt. Identity Store Persistierung der Informationen zu Identitäten (insb. Attribu-

te), z.B. LDAP-Verzeichnis, rel. DB oder Active Directory ID-WSF Identity Web Services Framework, Federation Spezifikation

von Liberty Alliance DVDV Deutsches Verwaltungsdiensteverzeichnis DSML Directory Service Markup Language FIM Federated Identity-Management IP Identity Provider, auch IdP JNLP Java Network Launching Protocol – Konfigurationsdateien im

XML-Format, die festlegen, wie Java-Anwendungen per Java Web Start aufgerufen werden

Kerberos Methode für die sichere Identitätsprüfung einer Anfrage LDAP Light Weight Directory Access Protocol - Protokollstandard

für Directory-Zugriffe (Untermenge der X.500-Funktionalität) OASIS Organization for the Advancement of Structured Information

Standards OSCI Online Services Computer Interface PKI Public Key Infrastructure, Ausgabe von Zertifikaten SAML Security Assertion Markup Language – SAML ist eine XML-

basierte Markup-Sprache für den sicheren Austausch von Authentifizierungsinformationen zwischen Netzwerkdiensten

SLA Service Level Agreement - Dienstleistungsvereinbarung SOA Serviceorientierte Architektur SOAP Simple Object Access Protocol - Protokoll zum Austausch

XML-basierter Nachrichten SOAP: MTOM SOAP Message Transmission Optimization Mechanism - Op-

timierungen für den SOAP Nachrichtenaustausch SPML Service Provisioning Markup Language SSO Single Sign On - Verteilte Dienste können mit gemeinsamer


Seite 48 von 49


Anmeldung genutzt werden. TD Trust-Domain oder Vertrauensdomäne. Server- Clientstruktur

in der zwischen den Einzelkomponenten eine Vertrauensstel-lung hinsichtlich der Identität und deren Nachweis geschaffen wurde.

UDDI Universal, Description, Discovery und Integration - Web-Service basiertes Registry für Services und andere strukturi-erte Informationen

WS-Federation WS-* Standard zur Verteilung von Identitäten WS-Trust WS-* Standard zur Implementierung eines IP (in WS-Trust =

STS) X.509 X.509 ist ein Standard für digitale Zertifikate XACML XML-basierte Access Control Markup Language – XML-

Beschreibung für die Definition von Zugriffsrechten XSD XML-Schemadatei


Seite 49 von 49


11 Zeitplanung / Arbeitsschritte

.

Arbeitsschritt bis

Entscheidung der BLK zu den Rah-menentscheidungen (Ziff 2)

81. BLK

10. Mai 2007

Grobkonzept (dieses Dokument) und Aufwandschätzung in UAG unter Mitwirkung Dataport/LDS überarbei-ten und

Versand an AG-IT zur Vorbereitung 32. AG-IT

bis 2.7.2007

Abstimmung AG-IT 32. AG-IT

am 5. Juli 2007 in Stuttgart

Übermittlung zur DOL-Technologie-Prüfung durch BMI/BSI

bis 31. Juli 2007

Erstellung Feinkonzept für ersten Prototypen (technischer Durchstich) unter Berücksichtigung DOL-Stellungnahme

Bis 15. Septem-ber 2007

Erste Realiserung des technischen Durchstichs

8. Oktober 2007

Abstimmung AG-IT, Vorbereitung BLK-Entscheidung

33. AG-IT

am 10. und 11. Oktober 2007 in Kassel

Abstimmung BLK

(Zeitplan, Kosten, liegen aufgrund ersten Durchstichs vor, Klärung Aus-schreibung)

82. BLK

8. Nov 2007

SAFE-Kern und Anpassung EGVP-Client

QII/2008

Klärung der Betriebsfragen für die Startphase SAFE-Kern

83. BLK

ggf. Mai 2008

Übergabe an DOL

SAFE Grobkonzept-1 1 - justiz.de · Zuletzt gedruckt 01.02.2008 Seite 2 ... 1. und 2.1 Erstellung...

Documents

Transcript of SAFE Grobkonzept-1 1 - justiz.de · Zuletzt gedruckt 01.02.2008 Seite 2 ... 1. und 2.1 Erstellung...