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

Transkript

1 S A F E G r o b k o n z e p t Thema: Registrierungsverzeichnis für Kommunikationsdienste Deutschland-Online Projekt Einheitliche Kommunikationsinfrastruktur für den elektronischen Rechtsverkehr Verantwortlich: Unterarbeitsgruppe SAFE der BLK Arbeitsgruppe IT- Standards in der Justiz; Version.Release: 1.0 Dataport Erstellt am: Zuletzt geändert am: Zustand: in Bearbeitung / vorgelegt / fertiggestellt Anzahl der Seiten: 49 Autoren: Herr Ehrmann (Justizministerium Baden Württemberg) mailto:ehrmann@jum.bwl.de Telefon: Herr Wöhrmann (Justiz Nordrhein-Westfalen, IT- Integration) mailto:meinhard.woehrmann@olg-duesseldorf.nrw.de Telefon: Herr Streckel (Dataport, Softwareengineering und Lösungsarchitekturen)mailto:birger.streckel@dataport.de Telefon: Herr Krause (Dataport, Softwareengineering und Lösungsarchitekturen)mailto:harald.krause@dataport.de Telefon: Dateiname: SAFE Zusammenfassung: Das Grobkonzept beschreibt die Anforderungen und die Rahmenarchitektur für ein Registrierungsverzeichnis für Kommunikationsdienste. Es dient als Grundlage für das fachliche Feinkonzept und die Realisierung. Ausgehend von den Anforderungen der Justiz an eine sichere Kommunikationsinfrastruktur werden unter Berücksichtigung der weiteren Nutzung des EGVP als bereits erfolgreich etablierte Kommunikationsplattform und der geplanten Einbettung des SAFE in Deutschland-Online bestimmte Rahmenentscheidungen und vorgaben getroffen.

2 Seite 2 von 49 Änderungshistorie Änderung Geänder- Beschreibung der Änderung Autor Relea- Datum te Kapitel se Erstentwurf: Inhaltliche Strukturierung Herr Ehrmann und 2.1 Erstellung 1.Kapitel und neues Kapitel 2.1 Herr Wöhrmann Erstellung 2.4 Herr Coujad 2.1 Erweiterte Darstellung Kapitel 2.1 Herr Wöhrmann alle Komplettüberarbeitung des gesamten Herr Streckel, Dokumentes Herr Krause alle Überarbeitung nach BLK-UAG-Sitzung Herr Streckel, 2007 vom Herr Krause Überarbeitung nach 32. AG-IT vom Herr Ehrmann , Freigabe Anpassung an die neue Namensgebung Herr Ehrmann 2007 SAFE (Secure Access to Federated e- Justice/eGovernment anstelle RVKD (RegistrierungsVerzeichnis/KommunikationsDienste)

3 Seite 3 von 49 1 VORGABEN UND ZIELE ZUSAMMENFASSUNG RAHMENENTSCHEIDUNGEN UND RAHMENVORGABEN RAHMENBEDINGUNGEN FÜR DIE EGVP-INFRASTRUKTUR RAHMENBEDINGUNGEN FÜR DEUTSCHLAND-ONLINE BEZIEHUNG DER RAHMENBEDINGUNGEN IDENTITY-MANAGEMENT IM OSCI-UMFELD EU-DIENSTLEISTUNGSRICHTLINIE VORGEHENSWEISE ARCHITEKTURKONZEPT SAFE MODULARE ARCHITEKTUR DIE VERTRAUENSDOMÄNE WICHTIGE STRUKTURKOMPONENTEN INNERHALB EINER VERTRAUENSDOMÄNE Attribute Service (AS) Attribute Identity Provider (IP) Registrierungsprozess Fachliche Services Clients für Fachanwendungen TRUST-DOMAIN-ÜBERGREIFENDE KONZEPTE Vertrauen zwischen Trust-Domains Meta-Attribute-Service Granularität von Trust-Domains SAFE ALS KONKRETE UMSETZUNG DES DEUTSCHLAND-ONLINE- ARCHITEKTURKONZEPTES KONKRETE UMSETZUNG FÜR DEN SAFE Basisumsetzung Erste AusbaustufErneuerung der Benutzerregistrierung Zweite AusbaustufAusgliederung von Teilen der Daten in neue TDs Erweiterungen NUTZERGRUPPEN, ROLLEN UND ZUGRIFFSRECHTE FÜR DAS SAFE Rollen Attribute Zugriffsrechte der Nutzergruppen BEZIEHUNGEN ZU DVDV BEZIEHUNGEN ZU UDDI VERFÜGBARKEITEN, SERVICELEVEL TECHNISCHE STANDARDS UND SCHNITTSTELLEN... 43

4 Seite 4 von DATENSCHUTZANFORDERUNGEN MENGENGERÜST OBJEKTE DES VERZEICHNISSES MENGENGERÜST NUTZER UND INSTITUTIONEN MIGRATION BESCHREIBUNG EGVP-INHALTE DIE ZU ÜBERNEHMEN SIND BESCHREIBUNG DER EGVP-CLIENT-SCHNITTSTELLE ALS GROBE LEITLINIE FESTLEGUNGEN UND VORLÄUFIGE FESTLEGUNGEN ABKÜRZUNGSVERZEICHNIS UND GLOSSAR ZEITPLANUNG / ARBEITSSCHRITTE... 49

5 Seite 5 von 49 1 Vorgaben und Ziele Mit in Kraft treten des EHUG zum haben die Bundesländer die elektronische Handelregisteranmeldung verpflichtend vorgeschrieben. Dafür wurde in allen Ländern und dem Bund eine Kommunikationsinfrastruktur über das EGVP erprobt 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 empfangsbereiten EGVP repliziert. Dies führt bei inzwischen ca 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 (zurzeit 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 vorgegebenen technischen Standards. Länder bzw. Fachapplikationen, die das EGVP nicht nutzen, haben evt. technische Probleme, die richtige Adressierung zu realisieren. Eine Loslösung des Registrierungsverzeichnisses vom EGVP unter Schaffung einer Standardschnittstelle zum EGVP kann dieses Problem beseitigen. Darüber hinaus brächte ein solcher unabhängiger Registrierungsdienst weitere Anwendungsmöglichkeiten für zusätzliche Kommunikationswege und Webservices, die gemeinsam mit den Standesvertretungen der regelmäßigen Verfahrensbeteiligten 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 deutschen Verwaltungsdiensteverzeichnis (DVDV), das derzeit für das Meldewesen betrieben 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 Nutzung des Registrierungs- und Verzeichnisdienstes über offene Schnittstellen zu

6 Seite 6 von 49 ermöglichen und die bisherigen produktbezogenen Registrierungsfunktionen (im EGVP) zu einem zentralen Registrierungsverzeichniss für Kommunikationsdienste (der vorläufige Vorhabensname Registrierungsverzeichniss für Kommunikationsdienste Kürzel RVKD, wurde umbenannt in SAFE, Secure Access to Federated ejustice/egovernment) weiterzuentwickeln. SAFE muss dadurch Nutzerzahlen zulassen, 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 vergleichsweise sehr weitgehenden "Elektronifizierung" Vorreiter für andere Verwaltungsbereiche, die ähnliche Probleme erst in Zukunft haben werden. Das Deutschland-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 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 angemeldet: a) Die Vereinheitlichung der Kommunikationsinfrastruktur innerhalb des Justizbereichs soll fortgeführt werden. Noch bestehende technische Kommunikationshindernisse zwischen einzelnen Justizverwaltungen sollen beseitigt und historisch 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 Weiterentwicklung berücksichtigt werden. c) In technischer Hinsicht steht die Weiterentwicklung des zentralen Registrierungs- und Verzeichnisdienstes im Zentrum des Projekts. Dieser soll im Rahmen des Projekts zu einer selbständigen Komponente weiterentwickelt werden, die nicht nur dem z. B. für die oben genannten elektronischen Registeranmeldungen verwendeten Programm EGVP (Elektronisches Gerichts- und Verwal-

7 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 Kommunikationsdienste (SAFE) zu erfüllen. Es ist so offen gestaltet, dass sie zudem den Anforderungen 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 datenschutzkonform 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 prototypischen Anwendung im Bereich der Justiz. (siehe Zeitplan)

8 Seite 8 von 49 2 Zusammenfassung Das Grobkonzept liefert die Anforderungen und die Rahmenarchitektur für ein Registrierungsverzeichnis 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ürgerportalen 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 internationalen 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 vorgeschlagene SAFE-Lösung möglich ist. Das Dokument dient als Grundlage für die Erstellung eines fachlichen Feinkonzeptes und der ersten technischen Machbarkeitsstudie anhand einer prototypischen Implementierung (technischer Durchstich) auf dessen Basis die 82. BLK die entsprechenden Entscheidungen treffen kann und auf dessen Basis dann die prototypische Realisierung für die Justiz erfolgen kann (s. auch Zeitplan). Es werden konkrete Empfehlungen für Rahmenentscheidungen bezüglich der Ausgestaltung des Systems sowie unterstützten Standards ausgesprochen.

9 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 nordrheinwestfälischen Verwaltungs- und Finanzgerichten sowie bundesweit mit allen Register- 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 gewahrt 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üsselungszertifikat 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 sichergestellt. Im Gegensatz zum Registrierungsserver, der zurzeit für alle EGVP-Kommunikationsteilnehmer zentral an einer Stelle, dem Landesamt für Datenverarbeitung und Statistik NRW (LDS NRW), betrieben wird, sind die Postfächer empfangender Institutionen schon heute unterschiedlichen Intermediären in einzelnen Bundesländern

10 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 Verfahrensbeteiligten-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.

11 Seite 11 von Rahmenbedingungen für Deutschland-Online Die Anforderungen des Deutschland-Online-Projektes an eine Benutzerregistrierung 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 Anwendungen berücksichtigt werden, für die eine Registrierung oder sichere Authentisierung eines Nutzers notwendig ist. So muss beispielsweise grundsätzlich die Anbindung von Bürger- oder Justizportalen genauso berücksichtigt werden, wie unterschiedliche E-Government-Dienste, die sich vom Rechtsverkehr wesentlich unterscheiden 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 interoperabler Systemkomponenten und neuen fachlichen Diensten. Die Anzahl der Nutzer darf nicht auf , oder beschrä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 Authentisierungsverfahren 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 einzuhalten, d.h. die bereitgestellte Information muss für den Anfragezweck angemessen sein. Die Anmeldung darf dabei nicht von der natürlichen Person abhä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 Komponenten bei der Erschließung neuer Anwendungsfelder. Die Integration bestehender Infrastrukturen für das Management von Identitä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-

12 Seite 12 von 49 benen Architekturkonzepten genügen und die dort beschriebenen Komponenten mindestens teilweise implementieren. Die konkreten Anforderungen an diese Implementierung sind durch die Rahmenbedingungen der EGVP-Infrastruktur gegeben. 3.4 Identity-Management im OSCI-Umfeld In den vorangegangenen Abschnitten zu Rahmenentscheidungen und Rahmenbedingungen sind die funktionalen Leistungen des zu entwerfenden Systems SAFE bereits grob skizziert worden. Dies erfolgte vornehmlich mit Blick auf den existierenden 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 Adressierung verfügbar zu machen. Es lassen sich zur Erfüllung dieses Zwecks bereits zwei funktionale Blöcke identifizieren: Registrierung Die Registrierung umfasst Prozesse und Mechanismen, um neue Kommunikationspartner mit ihren identifizierenden Daten und der Postfachzuordnung ins Verzeichnis aufzunehmen. Es bestehen Anforderungen an Integrität und Authentizität der erfassten Daten. Das Verzeichnis vertraut dem Registrierenden, dass die angegebene Identität der tatsächlichen entspricht und die übermittelten Daten korrekt sind. Prozess und technische Mechanismen (Authentifizierung) dienen dazu, diese Vertrauensbeziehung gewährleisten zu können. Verzeichnisabfrage Bei der Verzeichnisabfrage sucht ein Kommunikationspartner die Daten anderer 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 Korrektheit der gelieferten Identitäten zusichern.

13 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 Personen (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 Rollen, die registrierte Teilnehmer potentiell einnehmen können:: OSCI-Leser Das Modell von OSCI-Transport differenziert die an einer Kommunikation beteiligten 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 Registrierungsverzeichnis 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 Institutionen gestattet. Unabhängig von der Authentifizierungstechnik müssen die Nutzer registriert und verwaltet werden (z.b. zur verlässlichen Zuordnung von

14 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 Teilnehmergruppen 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 deckungsgleich 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 Eigenschaften über spezielle Dienste von Registrierungsverzeichnissen ausgestellt. Diese Auflistung verdeutlicht, dass als Kommunikationsteilnehmer zweckmäßigerweise nicht nur Empfänger, sondern auch Initiatoren einer Kommunikation (sogenannte Requestor) im Registrierungsverzeichnis verwaltet werden sollten. Die registrierten Teilnehmer variieren sowohl in der Rolle innerhalb einer Kommunikationsbeziehung (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 Bereitstellung der den Identitäten zugeordneten Daten (Verzeichnisabfragen, Adressbuch) 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 umfassender 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 begreifen. Das hier vorgestellte Konzept basiert auf den WS-* Spezifikationen 1, 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 Standards WS-Trust und WS-Federation, die gemeinsam von IBM und Microsoft entwickelt 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

15 Seite 15 von 49 zu beschreiben. Der untere Block ( Standards ) in Abbildung 1 zeigt alle Standards, die hier eine Rolle spielen, sowie deren Zusammenhänge. Ein nicht unwichtiger Aspekt ist, dass für die Implementierung der WS-* Spezifikationen mittlerweile eine beachtliche Zahl von Frameworks, Bibliotheken und Produkten verfügbar sind sowohl für Java als auch für.net. Dies erleichtert Herstellern von Lösungen und Produkten (kooperierenden Trust-Domains, Clients wie z.b. EGVP und Applikationen/Services), sich in das Gesamtsystem zu integrieren. Zudem fördert die Orientierung an Standards generell die Akzeptanz bei Drittanbietern. 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ürgerbü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 einem 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.

16 Seite 16 von 49 4 Vorgehensweise Um eine Implementierung des SAFE durchzuführen, muss der Implementierungsphase 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 Einzelschritte in eine grobe Zeitplanung eingeordnet, Abbildung 1 verdeutlicht die Zusammenhänge: Auf Basis von bestehenden Standards muss zunächst ein Architekturkonzept für die Deutschland-Online Anforderungen entwickelt werden (1). In einer Spezifikation werden Komponenten und Schnittstellen beschrieben. Dazu werden bereits existierende Standards profiliert und erweitert. Alle Schnittstellen werden streng standardkonform entwickelt. In dieser Phase wird das Konzept bereits 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 standardkonforme Softwarekomponenten, die aufgrund der modularen Architektur für spätere konkrete Projekte sehr gut wiederverwendbar aber auch einzeln austauschbar sind.

17 Seite 17 von 49 Registrierungslösung EGVP (SAFESAFESAFE) 3 Interope- rabilitäts- Nachweis Registrierung im GovernmentGateway für VPS (z.b Elba) Lösung Realisierung Realisierung Realisierung FIM Infrastruktur Open Source / Java 2 FIM Infrastruktur.NET Infrastruktur Implementierung Implementierung Implementierung Spezifikation für Föderiertes Identity Management (FIM) 1 Spezifikation Profilierung Metadata: WS-Policy WS-SecurityPolicy WS-Federation WS-Trust WS-SecureConversation WS-Security Standards Messaging: SOAP, WS-Addressing, MTOM XML Abbildung 1: Modulare Vorgehensweise bei der SAFE-Entwicklung

18 Seite 18 von 49 5 Architekturkonzept SAFE 5.1 Modulare Architektur 2 Im Rahmen von Deutschland-Online ist davon auszugehen, dass das zu entwerfende System von unterschiedlichsten Nutzergruppen verwendet wird. Aus dieser Diversifizierung von Benutzern und Benutzerdatenhoheiten ist ersichtlich, dass ein Adressbuch für Deutschland-Online nicht an einer Stelle zentral abgelegt werden kann. Es ist also erforderlich, die Nutzer nach Benutzergruppen aufzuteilen 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 Adressabfragen ü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 Dienstnutzern, die in einer gegenseitigen Vertrauensbeziehung stehen. In Abbildung 2 sind die Elemente einer solchen Vertrauensdomäne schematisch dargestellt. 2 Definitive Festlegung, siehe Tabelle in Abschnitt 9

19 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 Anwendung 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ändigkeit 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änenservices von außen, sei es durch eine Clientanwendung, eine Benutzerregistrierung 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 beschrieben. 5.3 Wichtige Strukturkomponenten innerhalb einer Vertrauensdomäne Innerhalb einer Vertrauensdomäne sind AS und IP die zentralen, obligatorischen Dienste 3, die in jedem Fall zu implementieren sind. Hinzu kommen fachliche Dienste, die aus einer konkreten Fachanwendung resultieren, sowie Registrierungsverfahren mit denen Nutzer in eine TD aufgenommen werden können. Neben der internen TD-Kommunikation muss auch die Kommunikation zwischen TDs und die Methode, mit der sich fachliche Dienste beim IP anmelden, spezifiziert werden Attribute Service (AS) Das vorliegende Grobkonzept folgt einem Modell, das in seinem Kern durch die Webservice-Spezifikation WS-Federation und der abhängigen Spezifikationsfamilie 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 Attributen 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 übermittelt wird. Der AS entscheidet dann auf Basis der übermittelten Rolle, welche Attribute und Datensätze für den Benutzer sichtbar sind. 3 Definitive Festlegung, siehe Tabelle in Abschnitt 9

20 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 vor 4. SPML ist ein von OASIS entwickeltes, XML-basiertes Framework für den Austausch von Benutzerund 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 Akzeptanz 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 enthalten. Das zweite, empfohlene Profil basiert auf XML-Schema oder XSD (SPMLv2 XSD Profile) und ermöglicht daher auch strukturierte Attributwerte. Die Anfragesprache innerhalb der search-operation ist XPath, daher sind prinzipiell auch komplexe 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ächliches Datenbankschema umwandeln. Ob die Datenbankimplementierung dabei als LDAP oder relationale Datenbank erfolgt, wird in diesem Architekturkonzept bewusst 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

21 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 Abschnitt 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) Attribute Attribute sind Eigenschaften eines Nutzers (Identität) wie Name, -Adresse und Zertifikate aber auch Rollenbezeichnungen, Gruppenzugehörigkeit und Rechte. Diese Attribute sind im Identity Store der TD gespeichert und können von dessen Identity Provider attestiert werden (siehe Abschnitt 5.3.3). Welche Attribute zu einem Nutzer im Identity Store gespeichert werden und welche vom Attribute Service an anfragende Dritte herausgegeben werden, hängt von der konkreten Anwendung ab. Wie im Abschnitt zum Attribute Service bereits beschrieben, werden die Attribute als XML-Schemata (XSD) festgelegt. Die Attribute einer TD werden durch mehrstufige XSD-Dateien beschrieben 5 - dies kann auch als Schalenmodell aufgefasst werden, wie in Abbildung 4 dargestellt. 5 Definitive Festlegung, siehe Tabelle in Abschnitt 9

22 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 allgemein gehalten sein und bildet so mit seinen Generellen Attributen die innerste Schale, die der AS jeder TD unterstützen muss. Damit wird eine minimale gemeinsame Schnittstelle für die Daten aller AS bereitgestellt. Die Erweiterten Attribute der nächsten Schale sind für eine Gruppe von TDs notwendig, die eine konkrete Fachlichkeit oder Nutzergruppe repräsentieren (z.b. elektronischer Rechtsverkehr ). Für die Realisierung des SAFE müssen z.b. alle Attribute festgelegt sein, die der EGVP-Client fordert und die im aktuellen Registrierungsserver 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 Inhalte 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-Kerndatensatz erfolgen.

23 Seite 23 von 49 Ein für diesen Zweck geeignetes, generisches XML-Schema stellt die Definition zu SAML-Assertions 6 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 Identitätsbezeichner, das auf einer Reihe unterschiedlicher Identitätskonzepte basieren kann (z.b. X.509, Windows-Domäne oder ). Schemaelemente der Attribute selbst beinhalten sowohl sprechende Namen als auch URI-bezogene Identifikatoren. URI-Bezogenheit ist wichtig für die Federation-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 OASISspezifizierten 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=" xmlns:xsi=" xmlns:ds=" ID="_33776a319493ad607b7ab3e689482e45" Version="2.0" IssueInstant=" T20:31:41Z"> <saml:issuer> <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:2.0:nameidformat:persistent">3f7b3dcf ecd-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"> 6 Vorläufige Festlegung, siehe Tabelle in Abschnitt 9

24 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> Identity Provider (IP) Das Vertrauenskonzept innerhalb einer Vertrauensdomäne basiert auf dem internationalen 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 Nachrichten ein IP verschickt und über welche Methoden die Services einer TD sich gegenseitig 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 angemeldeten Benutzer wie beispielsweise Name, Zertifikat-Herausgeber, Rolle oder - Adresse. Sie entsprechen z.b. den vom AS zu einer Identität veröffentlichten Attributen. 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 zuweisen und seine -Adresse nachschlagen. Diese Informationen werden dann in einem neuen Token als Claim zurückgesendet. Es findet also ein Aus-

25 Seite 25 von 49 tausch des Login-Claims gegen das Role-Claim und das -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) 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: (orientiert am E-Government-Plattformen wie dem HamburgGateway ):, Online-Registrierung unter Angabe des vollen Namens und der postalischen Anschrift sowie einer -Adresse (Stufe 1). Abschluss der Registrierung über einen per zugesandten Link.

26 Seite 26 von 49 Online-Registrierung wie in Stufe 1 sowie zusätzlich Angabe des Geburtsdatums und Abgleich der Daten mit Bundespersonalausweis in einem Kundenzentrum (Stufe 2) Online-Registrierung wie in Stufe 2 sowie Besitz einer qualifizierten elektronischen Signatur (Stufe 3, noch nicht realisiert) Neben der Registrierung von Privatpersonen besteht ein besonderes mehrstufiges Verfahren für Behörden, Standesorganisationen, Interessenvertretungen und Firmen, 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 Registrierungsprozesse mit unterschiedlichen Sicherheitsstufen denkbar, beispielsweise: Online-Registrierung ohne Identitätsnachweis (sehr unsicher). Online-Registrierung mit Freischaltung nach telefonischer Bestätigung (unsicher). 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 Sicherheitslevel erzielt werden können, sollte sich die Rolle des Benutzers an der Sicherheit der Registrierung orientieren. Diese Rolle entscheidet später über die Zugriffsrechte des Nutzers auf bestimmte Services und Daten. Wer für wen und unter welchen Bedingungen welche Rollen festlegen darf, muss organisatorisch in Betreibermodellen für IP festgelegt werden Fachliche Services Innerhalb einer TD werden im Allgemeinen auch fachliche Services angeboten, die mit dem IP der TD eine Vertrauensbeziehung unterhalten. Fachliche Services erwarten bzw. fordern ein Sicherheits-Token, das von ihrem IP herausgegeben wurde 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

27 Seite 27 von 49 nur bestimmter Sender (z.b. Mitglieder bestimmter TDs oder Inhaber einer bestimmten Rolle) zuzulassen. Der OSCI 1.2-Intermediär wird aber ebenso integriert werden. Hierfür wird wie bisher ein OSCI-Empfänger-Zertifikat vom AS bezogen. Abbildung 6: Postfächer, die nur Post von Meldebehörden empfangen 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 festgelegte 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 Beispiel für eine Clientanwendung ist der EGVP-Client. Dieser muss aus seiner Konfiguration 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.

28 Seite 28 von 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 stattfinden müsste. Durch Föderation werden mehrere TDs zu einem Circle Of Trust zusammengeschlossen. Die IPs der TDs unterhalten in diesem Circle Of Trust gegenseitige Vertrauensbeziehungen und ermöglichen so Single-Sign-On (SSO). Ein Benutzer muss sich dann nur ein einziges Mal am System anmelden, um fachliche Services aus beliebigen TDs innerhalb des Circle Of Trust zu nutzen 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 Federation-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 erstellt. 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 folgenden 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 akzeptiert 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.

29 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 Nachweis 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 Sicherheitskontext zwischen Client und fachlichem Service aufgebaut. Über diesen Sicherheitskontext können die Partner direkt miteinander kommunizieren, ohne Umweg über die IPs; dies ist im Standard WS-SecureConversation beschrieben. Zur direkten 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.

30 Seite 30 von 49 Abbildung 8: Identity Federation Vertrauen zwischen Trust Domains 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 Attributanfrage an mehrere oder alle Attribute-Services beliebiger TDs verteilt und die Antworten zusammenfasst und sortiert der Meta-Attribute-Service. Alternativ kann ein Client auch gezielt Anfragen an die Attribute-Services der einzelnen TDs richten. Entscheidendes Merkmal ist, dass die Schnittstelle des Meta-Attribut-Services i- dentisch ist zu der des einfachen Attribut-Services 7 (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

31 Seite 31 von 49 Attribut-Service handelt. Tatsächlich kann der Meta-Attribute-Service durch dieselbe 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 adressiert wird. Das Konzept ist vergleichbar mit dem der Virtual Directories ; es entsteht aber eine Vereinfachung durch die Beschränkung auf genau eine Schnittstellenimplementierung. 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. Dennoch muss auch der Meta-Attribute-Service sich beim Zugriff auf die Attribut Services der unterschiedlichen TDs über den jeweiligen IP autorisieren. Abbildung 9: Der Meta-Attribute-Service als übergeordneter Attribute Service 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 Verantwortlichkeiten ausgezeichnet sind, können den Betrieb einer autonomen Trust- Domain sinnvoll oder erforderlich machen. Auf der anderen Seite können betriebwirtschaftliche Gründe zu einer umfassenderen Nutzung gemeinsamer Infrastruktur auch mit einer höheren Anzahl von Nutzern sprechen.

32 Seite 32 von 49 Die Bildung von Trust-Domains wird sich letztendlich durch Kompromisse zu den konkurrierenden 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 Vertrauensbeziehungen 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 Zusammenfassung 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äftprozesse und den damit verbundenen Kommunikationsverhaltensweisen bestimmt. Als grobe Orientierung sollte aus heutiger Sicht die Anzahl der von einer Trust-Domain verwalteten Identitäten zwischen und liegen.

33 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 Architekturkonzeptes 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 Basisumsetzung und zwei Ausbaustufen realisiert werden kann. Die Ausbaustufen sind voneinander unabhängig und können je nach Anforderung in beliebiger Reihenfolge 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 Intermediä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 Zuordnung 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 verschiedenen TDs findet nicht statt.

34 Seite 34 von 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 implementierenden 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. Registrierungsprozesse werden wie bisher vom EGVP-Client abgewickelt, so dass hier keine Änderung nötig ist. Der Leistungsumfang dieser Ausbaustufe ist fast identisch mit der des aktuellen Registrierungsservers. Zusätzlich ist es aber möglich, durch Rollenvergabe 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).

35 Seite 35 von 49 Für die konkrete Umsetzung des SAFE empfiehlt dieses Konzept ein relationales Datenbanksystem für die Datenspeicherung 8 (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. Dadurch wird bei Fehlern im Änderungsprozess ein Rollback möglich. 3. Die Recovery-Funktionalität ist bei relationalen Datenbanken fortschrittlicher. Nach Systemcrashes können relationale Datenbanken einen konsistenten Systemzustand wieder herstellen. 4. Als Zukunftsoption für die Nutzung strukturierter Attribute sollten die eingesetzten Datenbanksysteme XML-fähig sein. Solche Datenbanksysteme unterstützen das Konzept, Attribute über XML-Schemata festzulegen. Selektive (XPath-)Anfragen können somit auf strukturierten Attributen filtern. 5. Die Schnittstelle des Attribut-Service ist als SPML über SOAP/http vorgesehen - 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 (lookup, 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 bestimmte 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 Erste AusbaustufErneuerung der Benutzerregistrierung Für die Vertrauenswürdigkeit einer Trust-Domain ist die Qualität des Registrierungsprozesses 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- 8 Vorläufige Festlegung, siehe Tabelle in Abschnitt 9

36 Seite 36 von 49 den. Ziel eines jeden Registrierungsprozesses ist es, die Identität der zu registrierenden Person oder Institution verifizieren zu können. Beispiele für Verfahren sind: Verifikation der angegebenen -Adresse durch Zustellung einer 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 Personalausweises bei einer autorisierten Instanz (z.b. Bürgerbüro). Sofern für die Registrierung qualifizierte elektronische Signaturen verwendet werden, kann der Registrierungsprozess optional die Zugangseröffnung für die rechtsverbindliche 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 eine erweiterte Kontrolle über den Datenzugriff. Implementierungen für Registrierungsprozesse sollten als austauschbare Systemerweiterungen 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 Abbildung 11 dargestellt.

37 Seite 37 von 49 Abbildung 11: Umsetzung des SAFE, 1. Ausbaustufe. Sollte die Registrierung aus dem EGVP-Client entfernt werden, ist die Entwicklung einer eigenständigen Registrierungsanwendung notwendig 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 Datenvolumen 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 entstehende Architektur verdeutlichen. Abbildung 12 zeigt die Komponenten und Beziehungen 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ürger-Portale für EGVP zu registrieren, zu authentisieren und zu autorisieren.

38 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öglich, bis alle Clientanwendungen umkonfiguriert sind. Ein detailliertes Migrationskonzept muss hier ausgearbeitet und getestet werden. Zum Beispiel wäre die Vergabe eines Migrations-Tokens möglich, womit der Client selbst die Migration 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 entsprechend umkonfiguriert werden. Nach der Aufteilung der Daten hat jeder Nutzer seine Heim-TD 9, 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, Vertrauensbeziehungen zwischen den Domänen aufzubauen. Wie in Abbildung 7 gezeigt, besteht die Vertrauensbeziehung dabei immer zwischen den IPs der Domänen. Diese können die Nutzung von Services aus anderen TD erlauben. Wie 9 Definitive Festlegung, siehe Tabelle in Abschnitt 9