S.A.F.E.-Feinkonzept - Dokument 2: IT-Feinkonzept S.A.F.E.

S.A.F.E.-Feinkonzept - Dokument 2: IT-Feinkonzept S.A.F.E. Thema: Verantwortlich: Secure Access to Federated E-Justice/E-Government Bund-Länderkommission für Datenverarbeitung und Rationalisierung in der Justiz (BLK) Version.Release: 1.5 Erstellt am: 01.02.2008 Zuletzt geändert am: 09.04.2008 Zustand: in Bearbeitung / vorgelegt / fertiggestellt Anzahl der Seiten: 89 Autoren: Jörg Apitzsch (bos) Werner Hartnick (bos) Harald Krause (Dataport) Klaus Lüttich (bos) Birger Streckel (Dataport) Dateiname: Zusammenfassung: Anfragen/Hinweise: 20080409_SAFE_Dokument2_IT-Feinkonzept_V1-5_veroeff.doc Die Anforderungen aus der EGVP-Lösung in funktionaler, qualitativer und quantitativer Hinsicht sind zusammengestellt, um daraus Erweiterungen oder Einschränkungen für eine Implementierung der Schnittstellen und Services aus dem S.A.F.E.-Basiskonzept für die Justiz abzuleiten. BLK-AG IT-Standards in der Justiz Jürgen Ehrmann (Justizministerium Baden-Württemberg) Telefon: 0711 279-2142 ehrmann@jum.bwl.de Meinhard Wöhrmann (Oberlandesgericht Düsseldorf) Telefon: 0211 4971-647 meinhard.woehrmann@olg-duesseldorf.nrw.de Status: Freigegeben durch die BLK am 8. Mai 2008

Seite 2 von 89 Urheber- und Kennzeichenrecht Das vorliegende Dokument wurde von Dataport, Anstalt des öffentlichen Rechts im Auftrag der Bund Länder Kommission für Datenverarbeitung und Rationalisierung in der Justiz kurz BLK vertreten durch das Justizministerium Baden-Württemberg erstellt. Sämtliche Inhalte sind urheberrechtlich geschützt. Die Verwendung, die Weitergabe oder Auswertung, die Vervielfältigung, Veröffentlichung oder Bearbeitung des Dokuments und/oder seiner Inhalte bedürfen der schriftlichen Genehmigung der BLK und sind mit einer Quellenangabe zu versehen. Alle innerhalb des Dokuments genannten und ggf. durch Dritte geschützten Markenund Warenzeichen unterliegen uneingeschränkt den Bestimmungen des jeweils gültigen Kennzeichenrechts und den Besitzrechten der jeweiligen eingetragenen Eigentümer. Allein aufgrund der bloßen Nennung im Dokument ist nicht der Schluss zu ziehen, dass Markenzeichen nicht durch Rechte Dritter geschützt sind. Haftungsausschluss Informationen und Verweise auf genutzte Standards und Normen, wurden nach bestem Wissen und Gewissen sorgfältig zusammengestellt und geprüft. Es wird jedoch keine Gewähr - weder ausdrücklich noch stillschweigend - für die Vollständigkeit, Richtigkeit, Aktualität oder Qualität und jederzeitige Verfügbarkeit übernommen.

Seite 3 von 89 Inhalt 1 AUSGANGSSITUATION UND ZIELSETZUNG...6 1.1 NAMENSRAUM...7 2 FUNKTIONALE ANFORDERUNGEN UND ANWENDUNGSFÄLLE...9 2.1 FUNKTIONALE ANFORDERUNGEN...9 2.2 ANWENDUNGSFÄLLE...10 2.2.1 Benutzer registrieren, modifizieren, löschen (Provisioning)...12 2.2.1.1 Anwendungsfall: Benutzer registrieren...13 2.2.1.2 Anwendungsfall: Benutzer gesichert registrieren...15 2.2.1.3 Anwendungsfall: Benutzer deregistrieren...17 2.2.1.4 Anwendungsfall: Benutzerattribute modifizieren...18 2.2.2 Administration...19 2.2.2.1 Anwendungsfall: Benutzer modifizieren durch Administrator...20 2.2.2.2 Anwendungsfall: Benutzer löschen...22 2.2.2.3 Anwendungsfall: Benutzer sperren...23 2.2.2.4 Anwendungsfall: Benutzer freischalten...25 2.2.3 Benutzer abfragen...26 2.2.3.1 Anwendungsfall: Attribute einer Identität (eines Benutzers) abfragen...26 2.2.3.2 Anwendungsfall: Benutzerliste abrufen...27 2.2.4 Replikation...28 2.2.4.1 Anwendungsfall: Benutzerdaten replizieren...29 2.2.5 Aktivitätsdiagramm: Benutzer gesichert registrieren und freischalten...30 2.3 ARCHITEKTUR-PRÜFLISTE DER FUNKTIONALEN ANFORDERUNGEN...34 2.4 ANFORDERUNGEN AN ATTRIBUTE...35 3 NICHT-FUNKTIONALE ANFORDERUNGEN UND MENGENGERÜSTE...36 3.1 QUANTITATIVE ANFORDERUNGEN...36 3.1.1 Handelsregister...36 3.1.2 Mahnanträge...36 3.1.3 Klageeinreichungen...36 3.1.4 Justiz-interne Kommunikation...37 3.1.5 Weitere Anwendungen...37 3.1.6 Plausibilität und Zusammenfassung...37 3.1.7 Datenvolumen...40 3.2 QUALITATIVE ANFORDERUNGEN...40 4 REALISIERUNG DER DIENSTE...41 4.1 PLATTFORM...41 4.2 TRUST-DOMAIN...41 4.3 KOMPONENTEN UND SUBSYSTEME...42 4.3.1 Identity-Provider (IdP)...42

Seite 4 von 89 4.3.1.1 Ausgestellte Assertions in der Version SAML 2.0...42 4.3.1.2 Authentifizierung des Requestors mittels X.509-Token...42 4.3.1.3 Authentifizierung des Requestors mittels SAML-Token...43 4.3.1.4 Attribute und Subject im SAML-Token...43 4.3.1.5 Konfiguration von Attributen eines SAML-Token...43 4.3.1.6 Angabe der Authentifizierungs- und Registrierungsmethode...44 4.3.2 Attribute-Service (AS)...44 4.3.2.1 Zu unterstützende Filter-Klauseln...45 4.3.2.2 Obligatorische SPML-Operationen...45 4.3.2.3 Implementierung Rollenkonzept...45 4.3.2.4 Differenzierter Informationsumfang...46 4.3.2.5 Spezielle Erweiterung ReplicationCapability...46 4.3.3 Provisioning-Service (PS)...48 4.3.3.1 Obligatorische SPML-Operationen...48 4.3.3.2 Registrierung mit Selbstbehauptung...48 4.3.3.3 SPML-Forwarding...49 4.3.4 Identitätsdatenbank...49 4.3.5 SAML-Token...50 5 FESTLEGUNG DER ERWEITERTEN ATTRIBUTE UND ROLLENKONZEPT...55 5.1 FESTLEGUNG DER ERWEITERTEN ATTRIBUTE UND EINSCHRÄNKUNG DER KERNATTRIBUTE...55 5.1.1 Namensraum...60 5.1.2 Syntax...60 5.2 MODELL DER ERWEITERTEN ATTRIBUTE...60 5.3 FESTLEGUNG VON ROLLEN UND SICHTBARKEITEN...61 6 REALISIERUNG DER IDENTITÄTSDATENBANK...62 6.1 DATENMODELL...62 6.1.1 Datenbanktabellen für die Identitätsattribute...62 6.1.2 Speicherung von Authentisierungszertifikaten...64 6.1.3 Datenbanktabellen zur Festlegung von RolleIDs...64 6.1.4 Datenbanktabellen für gesperrte und gelöschte Identitäten...65 6.1.5 Tabellen zur Verwaltung von Synchronisationsmodulen...66 6.1.6 Administrative Tabellen...67 6.2 ÜBERSICHT ÜBER DIE TABELLENBEZÜGE...70 7 ADMINISTRATION...71 7.1 ANWENDUNGSFÄLLE...71 7.2 ADMINISTRATIONS-TOOLS...71 7.3 AUDITING UND MONITORING...72 8 UMSETZUNG UND AUSBAUSTUFEN...73 8.1 STUFENMODELL FÜR DIE UMSETZUNG DES S.A.F.E.-KONZEPTES...74

Seite 5 von 89 8.1.1 Verzicht auf den IdP...74 8.1.1.1 Serviceanfrage mit Authentisierungszertifikat...74 8.1.1.2 Serviceantwort...75 8.1.2 Administrations-Tool mit direkter Anbindung an die Datenbank...76 8.2 AUSBAUSTUFEN...76 8.2.1 Unterstützung von Browser-SSO-Szenarien...77 8.2.2 Realisierung Registrierungssystem...77 8.2.2.1 Verfahren mit unterschiedlichen Stärken...77 8.2.3 Ausbau zum Föderalen System...78 9 BEDROHUNGSANALYSE UND RISIKOAKZEPTANZ...80 9.1 RISIKEN UND AUSWIRKUNGEN...80 9.2 MAßNAHMEN...81 9.3 BERECHTIGUNGSVERWALTUNG...82 10 BETRIEBSASPEKTE...83 10.1 SYSTEMVORAUSSETZUNGEN...83 10.2 SKALIER- UND VERFÜGBARKEIT...83 10.3 MONITORING UND SYSTEM-MANAGEMENT...83 11 ANHANG...84 11.1 SCHEMA-ERWEITERUNGEN...84 11.1.1 Schema MsgContact-Extension für OSCI-Parameter...84 11.1.2 SAML-AuthenticationContext-Erweiterung...84 11.1.3 Schema S.A.F.E. CapabilityData...85 11.1.4 Erweiterung der Attribute von ID-SIS-PP und des Basiskonzeptes... 240H86 102H11.1.5 AuthenticationClass für SelfSigned-Zertifikate... 241H87 103H11.2 ABKÜRZUNGSVERZEICHNIS UND GLOSSAR... 242H88 104H11.3 ABBILDUNGEN... 243H88 105H11.4 TABELLEN... 244H88 106H11.5 REFERENZIERTE DOKUMENTE... 245H89

Seite 6 von 89 1 Ausgangssituation und Zielsetzung In dem Dokument System- und Schnittstellenspezifikation - Föderiertes Identity Management des S.A.F.E.-Feinkonzepts [1] sind Anforderungen und Lösungen fachdomänenunabhängig betrachtet worden. Die dort dargestellten Schnittstellen definieren den kleinsten gemeinsamen Nenner zur Umsetzung föderaler Identity-Systeme. Dieses Dokument beschreibt den Teil des S.A.F.E.-Feinkonzepts, der die Rahmenbedingungen, die sich auch der konkreten Lösung zum elektronischen Rechtverkehr auf Basis EGVP ergeben, berücksichtigt. Aus den Rahmenbedingungen der Justiz werden Erweiterungen und Einschränkungen der in [1] definierten Schnittstellen abgeleitet. Dieses Dokument verfolgt insbesondere auch das Ziel, als genügend detaillierte Leistungsbeschreibung für eine Systemimplementierung zu dienen. Grundlagen für die Erstellung dieses Feinkonzepts waren: das Grobkonzept S.A.F.E. Version 1.1 vom 29.06.2007 ([3]), das Dokument System- und Schnittstellenspezifikation - Föderiertes Identity Management ([1]), die Entscheidungen im LK EGVP zur Öffnung des EGVP-Systems sowie die Rahmenbedingungen durch das EGVP in der aktuellen Version 2.2 und mit Blick auf die weitestgehend definierte Version 2.3. Letzteres ist wichtig, weil ein Ziel bei der Entwicklung von S.A.F.E. ein möglichst reibungsloser und kostengünstiger Übergang vom Registrierungsserver des heutigen EGVP-Systems auf S.A.F.E. war und ist. Das entsprechende Migrationskonzept ist separat in [3] dokumentiert. Als weitere Ziele sind von der Justiz vorgegeben; das Feinkonzept muss als Grundlage für die Ausschreibungsunterlagen (Leistungsbeschreibung) zur Realisierung von S.A.F.E. dienen können, es muss gleichzeitig als Basis für die Klärung der Betriebsfragen dienen, es sollen Aussagen zu den funktionalen und nicht funktionalen Anforderungen für einen lauffähigen S.A.F.E.-Kern für die Justiz beim Betreiber enthalten sein, parallele Entwicklungen mit denselben internationalen Standards bei OSCI 2.0 sind zu berücksichtigen, da das EGVP auf OSCI aufsetzt, es soll die genauen Ausgestaltungen der Schnittstellen enthalten und Bewertungen zum Kosten- und Terminrahmen für den S.A.F.E.-Kern ermöglichen.

Seite 7 von 89 Die im Konzept getroffenen Entwurfsentscheidungen - insbesondere zur Ausgestaltung der Schnittstellenprotokolle sind durch eine prototypische Teilimplementierung im Sinne eines Proof-of-Concepts verifiziert und unterstützt worden. Zusammengefasst verfolgt dieses Feinkonzept das Ziel, der Justiz eine Lösung für einen Verzeichnisdienst inkl. Identitätsmanagement unter Nutzung aktueller internationaler Standards zu entwerfen, die möglichst zukunftssicher und offen für die Einbeziehung anderer Mitspieler ist auch über die Justiz und über Deutschland hinaus. 1.1 Namensraum In diesem Dokument werden an mehreren Stellen Kurzbezeichnungen für Namensräume verwendet. Diese bezeichnen die folgenden Namensräume und werden in den angegebenen Standarddokumenten spezifiziert. Kurzbezeichnung Namensraum Standard osci safeac safecd safe urn:de:egov:names:safe:1.0:id-sispp: msgtechnology:osci12postbox 1 urn:de:egov:names:safe:1.0: authenticationcontext 1 urn:de:egov:names:safe:1.0: spmlcapabilitydata 1 urn:de:egov:names:safe:1.0:id-sispp:attributes 1 Schema MsgContact- Extension für OSCI- Parameter (Abschnitt 11.1.1) SAML- AuthenticationContext- Erweiterung (Abschnitt 11.1.2) S.A.F.E. Capability Data (Abschnitt11.1.3) ID-SIS-PP- Attributerweiterung Tabelle 1: Festlegung der Namensräume

Seite 8 von 89 Für Syntaxerweiterungen der verwendeten Standards, die im vorliegenden Dokument eingeführt werden, wird das folgende Namensraum-Muster vorgeschlagen: urn:de:egov:names:safe:1.0:* 1 Des Weiteren gelten die Namensraumfestlegungen aus Dokument [1] Abschnitt 1.2 Tabelle 2. 1 Diese Namensraumfestlegung ist als vorläufig zu betrachten. Der endgültige Namensraum kann nur durch die BLK Justiz beschlossen werden, weil es sich bei S.A.F.E. um einen justizspezifischen Standard handelt.

Seite 9 von 89 2 Funktionale Anforderungen und Anwendungsfälle 2.1 Funktionale Anforderungen Im Folgenden sind die Anforderungen zusammengestellt, die bei S.A.F.E. in Ergänzung zu den in Kap. 2 von [1] dargestellten allgemeinen Anforderungen zu berücksichtigen sind. Ergänzend sind so weit wie möglich die Anwendungsfälle in standardisierter Form dargestellt, die sich aus diesen Anforderungen und den grundsätzlichen Entscheidungen im Grobkonzept ergeben. Die Anforderungen gehen von einem offenen System aus, bei dem beliebige Clients und Fachverfahren die Kommunikationspartner sein können. Als gemeinsame Kernelemente des Systems werden dabei vorausgesetzt: Die Kommunikation zur Nachrichtenübermittlung zwischen der Justiz und ihren Kunden wird über OSCI erfolgen, zunächst gemäß Version 1.2 und später gemäß 2.0. Daher sollten aus Effizienzgründen die Authentisierungsmechanismen von OSCI auch von S.A.F.E. bereitgestellt werden können. Bei OSCI 2.0 wird es z. B. auch einen Dienst zum asynchronen Nachrichtenaustausch über Postfächer geben, dessen Nutzung der Authentisierung und Autorisierung bedarf differenziert jeweils für Zustellung und Abholung von Nachrichten. Das Organisationskonzept des EGVP mit Regelungen zu Download, Registrierung und Freischaltung, Rollenmodell, Repliken für Gerichte ist zu berücksichtigen und muss durch S.A.F.E. abbildbar sein. Insbesondere sind Mechanismen vorzusehen, um Aktualisierungen auf der zentralen Instanz zeitnah und performant auf die replizierten Bestände zu übernehmen. Die Möglichkeit zum Opting Out (keine Empfangsbereitschaft für elektronische Nachrichten) soll weiterhin gegeben sein. Das Löschen eines Eintrags im Verzeichnisdienst bzw. das Ändern des dort hinterlegten Verschlüsselungszertifikats darf generell erst erfolgen, wenn evtl. noch vorhandene Nachrichten abgeholt sind. Damit sollen nicht abholbare Nachrichten in Postfächern vermieden werden, für die es positive Eingangsbestätigungen gibt. Dies ist eine für S.A.F.E. technisch nicht prüfbare Anforderung an sämtliche Clients und Fachanwendungen, die eine Nachrichtenübermittlung über OSCI implementieren. Diese Funktionalität muss also außerhalb von S.A.F.E. über die eingesetzten Clients bzw. Fachanwendungen oder von zentraler Stelle als benutzbarer Dienst zur Verfügung gestellt werden. Die in [1], Kap. 5.3.2. und [2] Kap.8 festgelegten Standardattribute müssen sich in so weit an den Attributen des bestehenden EGVP-Registrierungsservers orientieren, und es muss klargestellt werden, wie sich die Attribute des EGVP- Registrierungsservers auf die neuen Attributfestlegungen abbilden lassen, um eine einfache Migration zu ermöglichen.

Seite 10 von 89 Auf die bestehende Infrastruktur der Justiz mit dem EGVP-System für den rechtssicheren Justizverkehr ist jedoch ebenfalls aus wirtschaftlichen Gründen und aus Gründen eines sicheren Betriebs im Zuge der Migration Rücksicht zu nehmen: Es wurde darauf geachtet, S.A.F.E. so zu gestalten, dass die späteren Aufwände zur Migration beim EGVP-Client möglichst gering sind, aber dennoch eine allgemeine und übergeordnete Architektur geschaffen wird, die eine Entwicklung weiterer Clientanwendungen unterstützt. Um die Migration der bestehenden Infrastruktur zu erleichtern, müssen die Protokolle und Datenstrukturen berücksichtigt werden, die mit der heute absehbaren Entwicklung des EGVP und seines Registrierungsservers gegeben sind, konkret also mit der vom Lenkungskreis (LK) EGVP verabschiedeten Version 2.3. (Andererseits wird der LK EGVP gebeten werden, bei der Planung der Folgeversionen des EGVP bis zur Integration des S.A.F.E. dessen Spezifikation zu berücksichtigen.) Insbesondere soll eine erneute Registrierung der - Stand Dezember 2007 - etwa 28.000 EGVP-Nutzer vermieden werden. Es soll also möglich sein, die Daten aus dem Registrierungsserver automatisiert in die S.A.F.E.-Identitätsdatenbank zu überführen. 2.2 Anwendungsfälle Die hier behandelten Anwendungsfälle stellen einerseits eine spezielle Ausprägung der Fälle dar, die in ihrer allgemeinen Form in Kap. 2 von [1] dargestellt sind (siehe dort Abbildung 1 Dok. [1]: Anwendungsfälle innerhalb einer Trust-Domain). Andererseits berücksichtigen sie konkrete Anforderungen für S.A.F.E., die aus den funktionalen Anforderungen im vorherigen Abschnitt motiviert sind. Da es in diesem Kapitel um funktionale Anforderungen aus fachlicher Sicht geht, wird nicht behandelt, welche jeweilige Funktionalität von den S.A.F.E.-Einzelkomponenten wie Identity-Provider (IdP) oder Attribute-Service (AS), gemäß Grobkonzept, erbracht werden. Dies wird in den Folgekapiteln hergeleitet. In den Anwendungsfällen wird lediglich die Interaktion zwischen Akteuren und dem S.A.F.E.-System beschrieben. Damit soll deutlich werden, welche konkreten funktionalen Anforderungen auf welche Weise erfüllt werden müssen. Wie in [1] wird eine Gliederung in Trust-Domains vorgenommen, es kann aber zunächst von der Implementation einer einzigen Trust-Domain für S.A.F.E. ausgegangen werden. Die Services innerhalb der S.A.F.E.-Trust-Domain basieren auf der Definition einer Trust-Domain aus [1]. Insbesondere müssen alle Services (fachliche sowie Infrastruktur-Services) den Anwendungsfall Identität autorisieren aus [1] inkludieren. Den Überblick über die Anwendungsfälle gibt die folgende Abbildung 1. Während in [1] von Identitäten gesprochen wird, die Nutzer, aber auch Systeme oder Anwendungen sein können, sind die Identitäten hier Benutzeridentitäten, da für S.A.F.E. von menschlichen Anwendern ausgegangen wird.

Seite 11 von 89 RVKD-Trust-Domain (TD) S.A.F.E. Trust-Domain Benutzer registrieren Benutzerattribute modifizieren Benutzer deregistrieren Benutzer gesichert registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und dort erläutert. Identität authentisieren Identität autorisieren Benutzer löschen l d >> Identitäten suchen Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Registrierungssystem Justiz- Registrierungssystem Abbildung 1: Anwendungsfälle innerhalb der S.A.F.E.-Trust-Domain

Seite 12 von 89 2.2.1 Benutzer registrieren, modifizieren, löschen (Provisioning) Für S.A.F.E. existieren die folgenden konkreten Anforderungen an eine Benutzerregistrierung: Alle Teilnehmer, die über S.A.F.E. adressierbar sein wollen, müssen sich unter Angabe bestimmter Daten registrieren, wobei bei den Kunden der Justiz keine Überprüfung der Daten stattfindet. Ihre Adressdaten werden sofort nach der Registrierung für die Nutzer der Justizseite (Justizmitarbeiter) sichtbar und über den Anwendungsfall Benutzerliste abrufen abrufbar. Alternativ können noch festzulegende Sicherheitsmechanismen gegen das automatische Anmelden einer Vielzahl von Benutzern im Sinne einer DoS-Attacke eingeführt werden, z. B. eine automatische Mail mit einem Kennwort in grafischer Darstellung, um eine Aktion durch den Nutzer erforderlich zu machen, die schwerer durch ein Programm zu simulieren ist. Ein flexibles Rollenmodell muss geschaffen werden, bei dem die Berechtigung zum Zugriff auf die Identitätsdatenbank detailliert gesteuert werden kann. Das bisher im EGVP vorhandene Rollenmodell muss dabei in die neue Struktur überführbar sein. Neben den aktuell definierten drei Rollen sind aber prinzipiell weitere Rollen definierbar. Diese unterscheiden sich in der Sichtbarkeit der eigenen Identitäten für andere und im Umfang der für sie selbst sichtbaren Identitäten. Die mindestens bereitzustellenden Rollen sind: 1. Kunde: Kunden-Identitäten sind sichtbar für alle Justizmitarbeiter und unsichtbar für andere Kunden. 2. Justizmitarbeiter (sichtbar): Der sichtbare Justizmitarbeiter kann im Adressbuch sämtliche Identitäten sehen und wird von allen gesehen. 3. Justizmitarbeiter (unsichtbar): Der unsichtbare Justizmitarbeiter kann im Adressbuch sämtliche Identitäten sehen, wird aber nur von anderen Justizmitarbeitern, nicht aber von Kunden gesehen. Sämtliche Anmeldungen von Justizmitarbeitern müssen explizit durch einen Administrator freigeschaltet werden. Aus Sicherheitsgründen wird die vom Client vorgeschlagene Rolle nicht einfach akzeptiert, wenn sie mehr als Kunden-Client aussagt. In den Anwendungsfällen werden diese konkreten Anforderungen durch ein allgemeines Rollenmodell berücksichtigt, in dem Sichtbarkeiten anhand vergebener Rollen frei konfigurierbar sind. Damit sind die beschriebenen Anforderungen leicht erfüllbar, aber auch erweiterte oder geänderte Anforderungen lassen sich ohne Wechsel der Technik abbilden. Damit wird es beispielsweise möglich, dass un-

Seite 13 von 89 sichtbare Justizmitarbeiter nur innerhalb einer bestimmten Behörde sichtbar sind und nicht mehr generell von allen anderen Justizmitarbeitern. Kunden der Justiz müssen aus Datenschutzgründen eine explizite Zustimmung zur Datenweitergabe geben. Falls sie dies nicht tun, können sie nicht im S.A.F.E. registriert werden. Modifikation und Löschung der Identitäten können nur durch den Nutzer selbst oder einen Administrator nach vorheriger Authentisierung und Autorisierung vorgenommen werden. 2.2.1.1 Anwendungsfall: Benutzer registrieren Ein neuer Benutzer in der Rolle Kunde (z. B. Anwalt, Notar) möchte sich zur Nutzung von EGVP-Services anmelden. Dies kann er ohne weitere Prüfung seiner Daten tun. Die Art der Registrierung beeinflusst dabei die späteren Zugriffsrechte des Nutzers. Benutzerattribute modifizieren Benutzer deregistrieren Registrierungssystem RVKD-Trust-Domain (TD) Benutzer registrieren Justiz- Registrierungssystem Benutzer gesichert registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und Identität authentisieren Identität autorisieren dort erläutert. Benutzer löschen i l d Identitäten suchen Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Akteur/Initiator Beschreibung Registrierungssystem Ein S.A.F.E.-Benutzer möchte sich an der S.A.F.E.-Trust-Domain für den Basiszugriff anmelden, ohne weitere Prüfung seiner Angaben zur Person. Dazu verwendet er ein Registrierungssystem. Vorbedingungen Der Benutzer hat am Registrierungssystem zumindest alle für S.A.F.E. erforderlichen Pflicht-Attribute (siehe [1], Kap. 5.3.2. und [2] Kap.8) angegeben und der Datenweitergabe an die Justiz zugestimmt. Insbesondere hat er ein Verschlüsselungszertifikat (OSCI-Adresse seines Postfachs) und ein Authentisierungszertifikat beschafft oder erzeugt und dem Registrierungssystem verfügbar gemacht.

Seite 14 von 89 Im Registrierungssystem ist seine Rolle als ungeprüfter Benutzer fest vorkonfiguriert. Basisablauf Nachbedingungen 1. Das Registrierungssystem sendet eine Anfrage an die S.A.F.E.- Trust-Domain, einen neuen Benutzer zu registrieren. Diese Anfrage enthält das Authentisierungszertifikat als Identätsnachweis, sowie alle angegebenen Benutzerdaten und Zertifikate. 2. Die S.A.F.E. -Trust-Domain stellt mit kryptographischen Verfahren sicher, dass das Registrierungssystem im Besitz des privaten Schlüssels des Authentisierungszertifikates ist. 3. Die S.A.F.E.-Trust-Domain prüft auch, dass das Zertifikat noch nicht in der Datenbank vorhanden ist, um eine doppelte Registrierung mit demselben Zertifikat zu vermeiden. 4. Die S.A.F.E.-Trust-Domain fügt den Benutzer als neue Identität zu ihrer Identitätsdatenbank hinzu. Dabei wird ihm eine eindeutige ID zugewiesen und seine Benutzerangaben, Zertifikate und Rolle werden gespeichert. Aus der Rolle muss hervorgehen, dass der Nutzer sich ohne weitere Prüfung seiner Daten angemeldet hat. Die Nutzerdaten stehen allen zugreifenden Services sofort zur Verfügung. 5. Die S.A.F.E.-Trust-Domain sendet eine Rückmeldung (inkl. der eindeutigen ID) an das Registrierungssystem, die besagt, dass der Benutzer korrekt registriert ist. Der Benutzer ist registriert. Er kann sich zukünftig unter Benutzung seiner ID und des Authentisierungszertifikates am System anmelden. Alle berechtigten (gemäß Rolle) Zugriffe auf die Identitätsdatenbank können die Daten zu dem Benutzer abrufen.

Seite 15 von 89 2.2.1.2 Anwendungsfall: Benutzer gesichert registrieren Ein Gericht oder eine Justiz-Einrichtung möchte sich zur EGVP-Nutzung in der Rolle Justizmitarbeiter anmelden. Dazu ist eine gesicherte Registrierung nötig. Durch die gesicherte Registrierung wird der Benutzer zwar korrekt angemeldet, eine Service- Nutzung ist aber erst nach einer manuellen Freischaltung durch einen Administrator möglich. Bis diese Freischaltung erfolgt ist, wird der neue Nutzer nicht authentisiert und seine Daten können nur durch einen Administrator abgerufen werden. i l d Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Identitäten suchen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Registrierungssystem RVKD-Trust-Domain (TD) Benutzerattribute modifizieren Benutzer registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und Identität authentisieren dort erläutert. Benutzer löschen Justiz- Registrierungssystem Benutzer deregistrieren Benutzer gesichert registrieren Identität autorisieren Akteur/Initiator Beschreibung Registrierungssystem (Zusatzanforderung Justiz) Ein Benutzer möchte sich an der S.A.F.E.-Trust-Domain mit erweiterten Zugriffsrechten anmelden. Dazu verwendet er ein Registrierungssystem (z. B. einen EGVP-Slave). Um erweiterte Zugriffsrechte zu erhalten ist eine nachgelagerte manuelle Freischaltung durch einen Administrator nötig. Vorbedingungen Der Benutzer hat am Registrierungssystem zumindest alle für S.A.F.E. erforderlichen Pflicht-Attribute (siehe [1], Kap. 5.3.2. und [2] Kap.8) angegeben und der Datenweitergabe zugestimmt. Insbesondere hat er ein Verschlüsselungszertifikat (OSCI-Adresse seines Postfachs) und ein Authentisierungszertifikat beschafft oder erzeugt und dem Registrierungssystem verfügbar gemacht. Im Registrierungssystem ist seine Rolle als Benutzer mit erweiterten Zugriffsrechten fest vorkonfiguriert. Es müssen aber Angaben zur Sichtbarkeit der zu erstellenden Identität gemacht werden. Basisablauf 1. Das Registrierungssystem sendet eine Anfrage an die S.A.F.E.- Trust-Domain, einen neuen Benutzer zu registrieren. Diese Anfrage enthält das Authentisierungszertifikat als Identätsnachweis, sowie alle angegebenen Benutzerdaten und Zertifikate. 2. Die S.A.F.E. -Trust-Domain stellt mit kryptographischen Verfahren

Seite 16 von 89 sicher, dass das Registrierungssystem im Besitz des privaten Schlüssels des Authentisierungszertifikates ist. 3. Die S.A.F.E.-Trust-Domain prüft auch, dass das Zertifikat noch nicht in der Datenbank vorhanden ist, um eine doppelte Registrierung mit demselben Zertifikat zu vermeiden. 4. Die S.A.F.E.-Trust-Domain fügt den Benutzer als neue Identität zu ihrer Identitätsdatenbank hinzu. Dabei wird ihm eine eindeutige ID zugewiesen und seine Benutzerangaben, Zertifikate und Rolle werden gespeichert. Aus der Rolle muss hervorgehen, dass es sich um einen Benutzer mit erweiterten Zugriffsrechten handelt. Ebenso wird über die Rolle die Sichtbarkeit der neuen Identität für andere Identitäten modelliert, dabei können weitere Benutzerangaben hinzugezogen werden. 5. Die S.A.F.E.-Trust-Domain muss vermerken, dass für die neue Identität eine Freischaltung erforderlich ist. Bis diese erfolgt ist, ist die neue Identität gesperrt und kann nicht genutzt werden. 6. Die S.A.F.E.-Trust-Domain sendet eine Rückmeldung (inkl. der eindeutigen ID) an das Registrierungssystem, die besagt, dass der Benutzer korrekt registriert ist, aber vor der Nutzung der Identität eine Freischaltung erfolgen muss. Nachbedingungen Der Benutzer ist registriert, die angelegte Identität ist gesperrt. Bevor sie genutzt werden kann, muss eine Freischaltung durch einen Administrator erfolgen (Anwendungsfall: Benutzer freischalten [2]; S.23ff Kap. 2.2.2.4).

Seite 17 von 89 2.2.1.3 Anwendungsfall: Benutzer deregistrieren Ein Registrierter Benutzer in einer beliebigen Rolle möchte sich beim System abmelden, seine Daten sollen aus dem System entfernt werden. RVKD-Trust-Domain (TD) Benutzer registrieren Benutzerattribute modifizieren Benutzer deregistrieren Benutzer gesichert registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und dort erläutert. Identität authentisieren Identität autorisieren Benutzer löschen i l d Identitäten suchen Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Registrierungssystem Justiz- Registrierungssystem Akteur/Initiator Beschreibung Vorbedingungen Registrierungssystem Ein Benutzer möchte sich dauerhaft von der Teilnahme am S.A.F.E.- System abmelden und seine Identität aus der Identitätsdatenbank löschen. Das Registrierungssystem wurde von der S.A.F.E.-Trust-Domain authentifiziert. Das Registrierungssystem kann dieses durch den Besitz eines von der S.A.F.E.-Trust-Domain herausgegebenen Berechtigungsnachweises nachweisen. Dieser stammt aus dem Anwendungsfall Identität authentisieren ([1]; S. 24ff Kap. 2.3.1.), ein föderierter Zugriff ist dem Registrierungssystem nicht erlaubt. Der Berechtigungsnachweis enthält Informationen, die die Identität als zugriffsberechtigt ausweisen und insbesondere die eindeutige ID des Benutzers, der den Berechtigungsnachweis beantragt hat. Vor dem Löschen aus der Identitätsdatenbank müssen die evtl. noch im Postfach des Benutzers liegenden Nachrichten abgeholt werden. Achtung: Diese Vorbedingung muss vom Registrierungssystem geprüft werden, S.A.F.E. kann diese Prüfung nicht leisten. Basisablauf 1. Das Registrierungssystem sendet eine Anfrage zur Deregistrierung an die S.A.F.E. -Trust-Domain. Diese Anfrage enthält den Berechtigungsnachweis. 2. << include >> des Anwendungsfalls Identität autorisieren ([1];

Seite 18 von 89 S.32 Kap. 2.3.5. 3. Die Trust-Domain löscht die Identität, für die der Berechtigungsnachweis herausgegeben wurde, aus der Identitätsdatenbank, und sendet eine Bestätigung an das Registrierungssystem. Nachbedingungen Fehlerszenarien Der Benutzer ist aus der Identitätsdatenbank gelöscht und kann sich ohne Neuregistrierung nicht mehr am S.A.F.E.-System anmelden. Das Postfach wurde nicht geleert. Dann bleiben Nachrichten auf dem OSCI-Intermediär, die nicht mehr abgeholt werden können, da eine Löschung durch das S.A.F.E.-System nicht geleistet werden kann. (Vergleiche [2]; Kap. 2.1. und Vorbedingungen Kap. 2.2.1.3) 2.2.1.4 Anwendungsfall: Benutzerattribute modifizieren Ein Benutzer möchte seine persönlichen Daten ändern und die geänderten Daten in der Identitätsdatenbank ablegen. Soll sein Authentisierungszertifikat geändert werden, mit dem er sich beim System anmeldet, muss er zuvor sein Postfach leeren. Benutzerattribute modifizieren Benutzer deregistrieren Registrierungssystem RVKD-Trust-Domain (TD) Benutzer registrieren Justiz- Registrierungssystem Benutzer gesichert registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und dort erläutert. Identität authentisieren Identität autorisieren Benutzer löschen i l d Identitäten suchen Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Akteur/Initiator Beschreibung Vorbedingungen Registrierungssystem Ein Benutzer möchte seine persönlichen Angaben in der Identitätsdatenbank ändern. Das Registrierungssystem wurde von der S.A.F.E.-Trust-Domain authentifiziert. Das Registrierungssystem kann dieses durch den Besitz eines von der S.A.F.E.-Trust-Domain herausgegebenen Berechtigungsnachweises nachweisen. Dieser stammt aus dem Anwendungsfall Identität authentisieren ([1]; S. 24ff Kap. 2.3.1.), ein föderierter Zugriff ist dem Registrierungssystem nicht erlaubt. Der Berechtigungsnachweis enthält Informationen, die die Identität als zugriffsbe-

Seite 19 von 89 rechtigt ausweisen und insbesondere die eindeutige ID des Benutzers, der den Berechtigungsnachweis beantragt hat. Soll das zur ID gehörige Verschlüsselungszertifikat geändert werden, müssen die evtl. noch im Postfach des Benutzers liegenden Nachrichten abgeholt werden. Achtung: Diese Vorbedingung muss vom Registrierungssystem geprüft werden, S.A.F.E. kann diese Prüfung nicht leisten. (vergleiche Vorbedingungen Kap. 2.2.1.3) Basisablauf Nachbedingungen Fehlerszenarien 1. Das Registrierungssystem sendet eine Anfrage zur Modifikation einer Identität an die S.A.F.E. -Trust-Domain. Diese Anfrage enthält den Berechtigungsnachweis. 2. << include >> des Anwendungsfalls Identität autorisieren ([1]; S.32 Kap. 2.3.5. 3. Die S.A.F.E.-Trust-Domain ruft die Informationen zu der Identität, für die der Berechtigungsnachweis herausgegeben wurde, aus der Identitätsdatenbank ab und sendet sie an das Registrierungssystem. 4. Das Registrierungssystem kann Änderungen an den Daten vornehmen oder diese ergänzen. Vor Änderung des Verschlüsselungszertifikates muss das Registrierungssystem prüfen, ob das zur Identität gehörende Postfach geleert ist. 5. Das Registrierungssystem sendet die modifizierten Daten an die S.A.F.E.-Trust-Domain. 6. Die S.A.F.E.-Trust-Domain prüft die geänderten Daten und legt sie in der Identitätsdatenbank ab. 7. Die S.A.F.E.-Trust-Domain sendet eine positive Rückmeldung an das Registrierungssystem. Die Nutzerdaten in der Identitätsdatenbank sind modifiziert. Die Benutzerangaben sind nicht korrekt und werden deshalb nicht angenommen. Das Postfach ist bei Änderung des Verschlüsselungszertifikats nicht geleert, was zu nicht abholbaren Nachrichten beim Intermediär führt. (vergleiche Vorbedingungen Kap. 2.2.1.3) 2.2.2 Administration Für die Benutzerdaten und Attribute ist eine Möglichkeit zur Administration erforderlich. Ein Administrator muss ebenfalls in der Lage sein, beliebige Identitäten zu ändern und

Seite 20 von 89 zu löschen. Zudem muss er Benutzer, die sich z. B. gesichert registriert haben, freischalten und temporär sperren können. Dazu ist eine weitere Rolle Administrator nötig, die einem Nutzer die entsprechenden Rechte zuschreibt. Es wird davon ausgegangen, dass ein Administrator über eine eigene Anwendung zur Administration verfügt, im Folgenden Administrationsmodul genannt. 2.2.2.1 Anwendungsfall: Benutzer modifizieren durch Administrator Ein Administrator möchte die Daten zu einem Benutzer modifizieren. Das Authentisierungszertifikat kann von Administrator nicht geändert werden. Benutzerattribute modifizieren Benutzer deregistrieren Registrierungssystem RVKD-Trust-Domain (TD) Justiz- Registrierungssystem Benutzer Benutzer registrieren gesichert registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und dort erläutert. Identität authentisieren Identität autorisieren Benutzer löschen i l d Identitäten suchen Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Akteur/Initiator Beschreibung Vorbedingungen Administrationsmodul Ein Administrator möchte die in der Identitätsdatenbank zu einem Benutzer gespeicherten Daten modifizieren. Das Administrationsmodul wurde von der S.A.F.E.-Trust-Domain authentifiziert. Das Administrationsmodul kann dieses durch den Besitz eines von der S.A.F.E.-Trust-Domain herausgegebenen Berechtigungsnachweises nachweisen. Dieser stammt aus dem Anwendungsfall Identität authentisieren ([1]; S. 24ff Kap. 2.3.1.), ein föderierter administrativer Zugriff ist nicht erlaubt. Der Berechtigungsnachweis enthält eine Rolle und eine Sicherheitsstufe, die dem Administrationsmodul Administratorrechte bescheinigen. Das Administrationsmodul kennt die ID des zu modifizierenden Mitarbeiters. Basisablauf 1. Das Administrationsmodul sendet eine Anfrage zur Modifikation

Seite 21 von 89 einer Identität an die S.A.F.E. -Trust-Domain. Diese Anfrage enthält den Berechtigungsnachweis und die ID der zu modifizierenden Identität. 2. << include >> des Anwendungsfalls Identität autorisieren ([1]; S.32 Kap. 2.3.5. 3. Die S.A.F.E.-Trust-Domain ruft die Informationen zu der angegebenen Identität aus der Identitätsdatenbank ab und sendet sie an das Administrationsmodul. 4. Das Administrationsmodul kann Änderungen an den Daten vornehmen oder diese ergänzen. 5. Das Administrationsmodul sendet die modifizierten Daten an die S.A.F.E.-Trust-Domain. 6. Die S.A.F.E.-Trust-Domain prüft die geänderten Daten und legt sie in der Identitätsdatenbank ab. 7. Die S.A.F.E.-Trust-Domain sendet eine positive Rückmeldung an das Administrationsmodul. Nachbedingungen Fehlerszenarien Die Nutzerdaten in der Identitätsdatenbank sind modifiziert. Die Benutzerangaben sind nicht korrekt und werden deshalb nicht angenommen.

Seite 22 von 89 2.2.2.2 Anwendungsfall: Benutzer löschen Da die Anmeldung für Benutzer in der Rolle Kunde ohne Prüfung geschieht, ist es möglich, dass Benutzer falsche Angaben machen oder Datensätze mit erfundenen Daten eintragen. Solche offensichtlich nicht genutzten Einträge können vom Administrator auf Geheiß der Justiz gelöscht werden. Benutzerattribute modifizieren Benutzer deregistrieren Registrierungssystem RVKD-Trust-Domain (TD) Benutzer registrieren Justiz- Registrierungssystem Benutzer gesichert registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und dort erläutert. Identität authentisieren Identität autorisieren Benutzer löschen i l d Identitäten suchen Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Akteur/Initiator Beschreibung Vorbedingungen Administrationsmodul Ein Administrator möchte einen Benutzer dauerhaft von der Teilnahme am S.A.F.E.-System abmelden und die Benutzeridentität aus der Identitätsdatenbank löschen. Das Administrationsmodul wurde von der S.A.F.E.-Trust-Domain authentifiziert. Das Administrationsmodul kann dieses durch den Besitz eines von der S.A.F.E.-Trust-Domain herausgegebenen Berechtigungsnachweises nachweisen. Dieser stammt aus dem Anwendungsfall Identität authentisieren ([1]; S. 24ff Kap. 2.3.1.), ein föderierter administrativer Zugriff ist nicht erlaubt. Der Berechtigungsnachweis enthält eine Rolle und eine Sicherheitsstufe, die dem Administrationsmodul Administratorrechte bescheinigen. Das Administrationsmodul kennt die ID des zu löschenden Mitarbeiters. Vor dem Löschen aus der Identitätsdatenbank müssen die evtl. noch im Postfach des Benutzers liegenden Nachrichten gelöscht werden. Achtung: Diese Vorbedingung muss vom Administrationsmodul geprüft werden, S.A.F.E. kann diese Prüfung nicht leisten (vergleiche Vorbedingungen Kap. 2.2.1.3). Basisablauf 1. Das Administrationsmodul sendet eine Anfrage zur Deregistrie-

Seite 23 von 89 rung an die S.A.F.E. -Trust-Domain. Diese Anfrage enthält den Berechtigungsnachweis und die ID der zu deregistrierenden Identität. 2. << include >> des Anwendungsfalls Identität autorisieren ([1]; S.32 Kap. 2.3.5. 3. Die Trust-Domain löscht die angegebene Identität aus der Identitätsdatenbank und sendet eine Bestätigung an das Administrationsmodul. Nachbedingungen Fehlerszenarien Der Benutzer ist aus der Identitätsdatenbank gelöscht und kann sich ohne Neuregistrierung nicht mehr am S.A.F.E.-System anmelden. Das Postfach wurde nicht geleert. Dann entstehen verwaiste Nachrichten, da eine Überprüfung durch S.A.F.E. nicht geleistet werden kann. (vergleiche Vorbedingungen Kap. 2.2.1.3) 2.2.2.3 Anwendungsfall: Benutzer sperren Ein Administrator kann einen Benutzer temporär sperren, die Identität und die Daten des Benutzers bleiben aber im System erhalten. Eine Anmeldung durch einen gesperrten Benutzer ist nicht möglich, ebenso ist seine Identität für andere Nutzer unsichtbar. Eine Entsperrung erfolgt mit dem Anwendungsfall Benutzer freischalten. Benutzerattribute modifizieren Identität authentisieren Registrierungssystem RVKD-Trust-Domain (TD) Benutzer registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und dort erläutert. Justiz- Registrierungssystem Benutzer deregistrieren Benutzer gesichert registrieren Identität autorisieren Benutzer löschen i l d Identitäten suchen Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Akteur/Initiator Beschreibung Vorbedingungen Administrationsmodul Ein Administrator möchte einen bereits registrierten Benutzer vorübergehend sperren, ohne seine Identität aus der Identitätsdatenbank zu entfernen. Das Administrationsmodul wurde von der S.A.F.E.-Trust-Domain authentifiziert. Das Administrationsmodul kann dieses durch den Besitz eines von der S.A.F.E.-Trust-Domain herausgegebenen Berechti-

Seite 24 von 89 gungsnachweises nachweisen. Dieser stammt aus dem Anwendungsfall Identität authentisieren ([1]; S. 24ff Kap. 2.3.1.), ein föderierter administrativer Zugriff ist nicht erlaubt. Der Berechtigungsnachweis enthält eine Rolle und eine Sicherheitsstufe, die dem Administrationsmodul Administratorrechte bescheinigen. Das Administrationsmodul kennt die ID des zu sperrenden Mitarbeiters. Basisablauf 1. Das Administrationsmodul sendet eine Anfrage an die S.A.F.E.- Trust-Domain, einen Benutzer zu sperren. Diese Anfrage enthält die ID des zu sperrenden Mitarbeiters sowie den Berechtigungsnachweis. 2. << include >> des Anwendungsfalls Identität autorisieren ([1]; S.32 Kap. 2.3.5. 3. Die S.A.F.E.-Trust-Domain nimmt die Sperrung der Identität vor. 4. Die S.A.F.E.-Trust-Domain sendet eine Rückmeldung an das Administrationsmodul, die besagt, dass die Identität gesperrt ist. Nachbedingungen Der Benutzer ist gesperrt. Er kann sich nicht mehr anmelden und ist bei Zugriffen auf die Identitätsdatenbank unsichtbar. Um die gesperrte Identität wieder nutzen zu können, ist eine Freischaltung durch einen Administrator (Anwendungsfall: Benutzer freischalten ) notwendig.

Seite 25 von 89 2.2.2.4 Anwendungsfall: Benutzer freischalten Ein Administrator kann einen gesperrten Benutzer frei schalten. Die Identität ist dann für andere sichtbar und kann sich am System anmelden. Ein Benutzer ist gesperrt, wenn er sich in der Rolle Justizmitarbeiter gesichert neu registriert hat oder wenn er manuell von einem Administrator gesperrt wurde. Benutzerattribute modifizieren Benutzer deregistrieren Registrierungssystem RVKD-Trust-Domain (TD) Benutzer registrieren Justiz- Registrierungssystem Benutzer gesichert registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und Identität authentisieren Identität autorisieren dort erläutert. Benutzer löschen i l d Identitäten suchen Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Akteur/Initiator Beschreibung Vorbedingungen Administrationsmodul Ein Administrator möchte einen bereits registrierten aber gesperrten Benutzer freischalten. Das Administrationsmodul wurde von der SAFE-Trust-Domain authentifiziert. Das Administrationsmodul kann dieses durch den Besitz eines von der S.A.F.E.-Trust-Domain herausgegebenen Berechtigungsnachweises nachweisen. Dieser stammt aus dem Anwendungsfall Identität authentisieren ([1]; S. 24ff Kap. 2.3.1.), ein föderierter administrativer Zugriff ist nicht erlaubt. Der Berechtigungsnachweis enthält eine Rolle und eine Sicherheitsstufe, die dem Administrationsmodul Administratorrechte bescheinigen. Das Administrationsmodul kennt die ID des freizuschaltenden Mitarbeiters. Basisablauf 1. Das Administrationsmodul sendet eine Anfrage an die S.A.F.E. - Trust-Domain, einen Benutzer freizuschalten. Diese Anfrage enthält die ID des freizuschaltenden Mitarbeiters sowie den Berechtigungsnachweis. 2. << include >> des Anwendungsfalls Identität autorisieren ([1]; S.32 Kap. 2.3.5.

Seite 26 von 89 3. Die S.A.F.E.-Trust-Domain ruft die Informationen zur freizuschaltenden Identität aus der Identitätsdatenbank ab und sendet sie an das Administrationsmodul. 4. Das Administrationsmodul kann Änderungen an den Attributen vornehmen oder diese ergänzen (z. B. externe XJustiz-Id). 5. Das Administrationsmodul sendet die geänderten Attribute an die S.A.F.E.-Trust-Domain zusammen mit der Mitteilung, dass die zugehörige Identität freizuschalten ist. 6. Die S.A.F.E.-Trust-Domain nimmt die Freischaltung der Identität vor und legt die geänderten Attribute in der Identitätsdatenbank ab. 7. Die S.A.F.E.-Trust-Domain sendet eine Rückmeldung an das Administrationsmodul, die besagt, dass die Identität korrekt freigeschaltet ist. Nachbedingungen Die Benutzer ist freigeschaltet. Er kann sich zukünftig unter Benutzung seiner ID und des Authentisierungszertifikates am System anmelden. 2.2.3 Benutzer abfragen Die registrierten Benutzer sind in der Lage, andere Benutzeridentitäten und deren Attribute abzufragen. Dabei können Daten zu einzelnen Identitäten abgefragt werden, es ist aber auch eine Suche über die gesamte Identitätsdatenbank und die Rückgabe einer Liste von Identitäten möglich. 2.2.3.1 Anwendungsfall: Attribute einer Identität (eines Benutzers) abfragen Im EGVP-System wird unmittelbar vor dem Versenden von Nachrichten geprüft werden, ob die Empfängeradresse noch ansprechbar (das Verschlüsselungszertifikat noch gültig und nicht gesperrt) ist. Damit soll erreicht werden, dass nicht abholbare Nachrichten erst gar nicht gesendet werden. Für diese Anforderung ist es nötig, dass im S.A.F.E.-System Daten zu einzelnen Nutzern abgefragt werden können. Der zugehörige Anwendungsfall entspricht dem Anwendungsfall Attribute einer Identität abfragen aus [1].

Seite 27 von 89 2.2.3.2 Anwendungsfall: Benutzerliste abrufen Der Anwendungsfall Benutzerliste abrufen ist eine Spezialisierung des in Kap. 2 von [1] dargestellten Anwendungsfall Identitäten suchen, so dass hier nur noch die spezifischen Anforderungen für das S.A.F.E. beschrieben werden. Benutzerattribute modifizieren Benutzer deregistrieren Registrierungssystem RVKD-Trust-Domain (TD) Benutzer registrieren Justiz- Registrierungssystem Benutzer gesichert registrieren Wie schon im Anwendungsfall Identitäten suchen angedeutet, sollen nicht beliebig viele Identitäten geliefert werden. vielmehr sollen (ähnlich wie bei Google) nur die ersten (etwa 20) Treffer übermittelt werden, ein Nachfordern der nächsten Treffer geschieht über die dort beschriebene Iterate- Funktionalität. Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und Identität authentisieren Identität autorisieren dort erläutert. Benutzer löschen i l d Identitäten suchen Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzerdaten replizieren Benutzer sperren Benutzer freischalten Benutzerliste abrufen Synchronisationsmodul Administrationsmodul Abfragesystem Akteur/Initiator Beschreibung Abfragesystem Das Abfragesystem möchte eine Liste von Identitäten aus der Identitätsdatenbank der S.A.F.E.-Trust-Domain abfragen. Die Anfrage kann mittels angegebener Suchkriterien eingeschränkt werden. Die Einschränkung kann sich sowohl auf die zurückgelieferten Identitäten (Selektion) als auch auf die abgefragte Attributmenge (Projektion) beziehen. Dieser Anwendungsfall ist eine Spezialisierung des Anwendungsfalls Identitäten suchen aus [1]. Vorbedingungen Basisablauf Das Abfragesystem wurde von der S.A.F.E.-Trust-Domain authentifiziert. Das Abfragesystem kann dieses durch den Besitz eines von der S.A.F.E.-Trust-Domain herausgegebenen Berechtigungsnachweises nachweisen (z. B. aus dem Anwendungsfall Identität authentisieren ([1]; S. 24ff Kap. 2.3.1.)). Dieser enthält Informationen, die die Identität als zugriffsberechtigt ausweisen. Es enthält auch Informationen zur Rolle der Identität, über diese werden die Zugriffsrechte gesteuert. 1. Das Abfragesystem sendet eine Anfrage an die S.A.F.E.-Trust- Domain, um eine Liste von Identitäten aus der Identitätsdatenbank der S.A.F.E.-Trust-Domain abzufragen. Diese Anfrage enthält den Berechtigungsnachweis sowie möglicherweise Suchkriterien. Die Anfrage kann einen Iterationszähler enthalten.

Seite 28 von 89 Die Suchkriterien beziehen sich auf bestimmte Attribute, die in der Identitätsdatenbank zu den Identitäten gespeichert sind. Einschränkungen in der Sichtbarkeit von Attributen (Projektion) sind über das Rollenmodell definiert. 2. Wie Punkt 2 und 3 im allg. Anwendungsfall Identitäten suchen aus [1]. Dabei werden die ausgewählten Identitäten folgendermaßen eingeschränkt: o Eine Einschränkung der zurückgegebenen Identitäten (Selektion) findet aufgrund der Rolle statt. Gesichert registrierte Justizmitarbeiter haben dabei andere Rechte, als ohne Überprüfung registrierte Justiz-Kunden. Die genauen Sichtbarkeiten sind über das Rollenmodell detailliert konfigurierbar. Eine Einschränkung auf die sichtbaren Attribute (Projektion) findet ebenfalls auf Basis des Rollenmodells statt. o Eine festgelegte obere Grenze für die Anzahl an zurückgegebenen Datensätzen darf dabei nicht überschritten werden, die folgenden Teillisten werden durch einen Iterationszähler adressiert. Nachbedingungen Fehlerszenarien 3. Die S.A.F.E.-Trust-Domain übermittelt die Liste von Identitäten und deren Attribute an das Abfragesystem zurück. Das Abfragesystem hat Kenntnis über einen Ausschnitt aus der Identitätsdatenbank der S.A.F.E.-Trust-Domain. Die Suchkriterien sind fehlerhaft oder betreffen Attribute, zu deren Einsicht das Abfragesystem nicht autorisiert ist. 2.2.4 Replikation Beim EGVP können Anfragen an einen Adressbuch-Master gestellt werden, in dem alle registrierten Benutzer verzeichnet sind. Mit denselben Mechanismen können Anfragen an dezentrale (nicht lokale!) Replikationen gestellt werden werden. Um diese EGVP-Funktionalität zu unterstützen, benötigt das S.A.F.E. eine Replikationsschnittstelle, die sich im Anwendungsfall Benutzerdaten replizieren ausdrückt.

Seite 29 von 89 2.2.4.1 Anwendungsfall: Benutzerdaten replizieren Für Organisationen, die die S.A.F.E.- Identitätsdatenbank stark nutzen, kann eine lokale Kopie der Datenbank Performance- Vorteile bringen. Um eine solche dezentrale Replikation zu ermöglichen, wird eine entsprechende Replikationsschnittstelle bereitgestellt, über die die entsprechenden Daten abgerufen werden. Der Replikations-Master ist dabei immer die Identitätsdatenbank, die dezentralen Kopien stellen nur Abbilder dar, die nicht modifiziert werden dürfen. Aus Performancegründen wird eine inkrementelle Replikation unterstützt, es werden immer nur die Änderungen an den Daten übertragen. i l d Benutzer modifizieren durch Administrator Attribute einer Identität abfragen Benutzer sperren Benutzer freischalten Benutzerliste abrufen Identitäten suchen Benutzerdaten replizieren Synchronisationsmodul Administrationsmodul Abfragesystem Registrierungssystem RVKD-Trust-Domain (TD) Benutzerattribute modifizieren Benutzer registrieren Grau hinterlegte Anwendungsfälle sind aus Dokument [1] übernommen und Identität authentisieren dort erläutert. Benutzer löschen Justiz- Registrierungssystem Benutzer deregistrieren Benutzer gesichert registrieren Identität autorisieren Akteur/Initiator Beschreibung Vorbedingungen Synchronisationsmodul Das Synchronisationsmodul möchte seine Replik-Datendank auf den aktuellen Stand bringen. Dazu stellt es eine Anfrage an die S.A.F.E.- Trust-Domain und erhält eine Liste all der Identitäten, die sich seit dem letzten Aufruf der Replikation geändert haben (inkrementelle Replikation). Das Synchronisationsmodul wurde von der S.A.F.E.-Trust-Domain authentifiziert. Das Synchronisationsmodul kann dieses durch den Besitz eines von der S.A.F.E.-Trust-Domain herausgegebenen Berechtigungsnachweises nachweisen (z. B. aus dem Anwendungsfall Identität authentisieren ([1]; S. 24ff Kap. 2.3.1.)). Dieser enthält Informationen, die die Identität als zugriffsberechtigt ausweisen. Die Identitätsdatenbank kennt zu jeder Identität den Änderungszeitpunkt. Dies ist der Zeitpunkt der letzten Änderung oder der Registrierung einer Identität. Basisablauf 1. Das Synchronisationsmodul sendet eine Anfrage an die S.A.F.E.- Trust-Domain, um eine Liste von Identitäten aus der Identitätsdatenbank der S.A.F.E.-Trust-Domain abzufragen. Diese Anfrage enthält den Berechtigungsnachweis sowie den spätesten Änderungszeitpunkt aller Identitätsdatensätze im lokalen Replikat der