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

Größe: px
Ab Seite anzeigen:

Download "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) Telefon: Herr Wöhrmann (Justiz Nordrhein-Westfalen, IT- Integration) Telefon: Herr Streckel (Dataport, Softwareengineering und Telefon: Herr Krause (Dataport, Softwareengineering und 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="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" ID="_33776a319493ad607b7ab3e689482e45" Version="2.0" IssueInstant=" T20:31:41Z"> <saml:issuer>http://wwww.safe.de/attributeservice</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

Glossar zum S.A.F.E. Feinkonzept

Glossar zum S.A.F.E. Feinkonzept Glossar zum S.A.F.E. Feinkonzept Thema: Verantwortlich: Secure Access to Federated E-Justice/E-Government Bund-Länder-Kommission für Datenverarbeitung und Rationalisierung in der Justiz Version.Release:

Mehr

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause 1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management Deckblatt Bremen, E-Government in medias res, 12. Juli 2007 Internationale Standards zu Identity Management 3 Dataport 12.Juli 2007

Mehr

Die elektronische Identität - einmal registriert, überall akzeptiert. Oberlandesgericht DüsseldorfD

Die elektronische Identität - einmal registriert, überall akzeptiert. Oberlandesgericht DüsseldorfD Die elektronische Identität - einmal registriert, überall akzeptiert. Dipl.-Phys. Meinhard Wöhrmann, W Oberlandesgericht DüsseldorfD IT-Forum: E-Justice Im Dienste der Gesellschaft Oberlandesgericht Köln,

Mehr

Einmal registriert, von allen akzeptiert

Einmal registriert, von allen akzeptiert DEUTSCHLAND ONLINE Workshop E-Government-Standards für Wirtschaft und Verwaltung der Initiative D21 am 27. und 28. November 2008 BMWi Berlin Einmal registriert, von allen akzeptiert S.A.F.E. - Secure Access

Mehr

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen Herzlichen Dank! Projektleitung S.A.F.E.: Meinhard Wöhrmann (meinhard.woehrmann@olg-duesseldorf.nrw.de)

Mehr

EDV - Gerichtstag. Einmal registriert, von allen akzeptiert. S.A.F.E. - Secure Access to Federated E-Justice / E-Government

EDV - Gerichtstag. Einmal registriert, von allen akzeptiert. S.A.F.E. - Secure Access to Federated E-Justice / E-Government DEUTSCHLAND ONLINE EDV - Gerichtstag 18. September 2008, Saarbrücken Einmal registriert, von allen akzeptiert S.A.F.E. - Secure Access to Federated E-Justice / E-Government Bund-Länderkommission für Datenverarbeitung

Mehr

VERZEICHNISDIENSTE IN E-GOVERNMENTSYSTEMEN

VERZEICHNISDIENSTE IN E-GOVERNMENTSYSTEMEN Marcel Huth, 31.07.2008 VERZEICHNISDIENSTE IN E-GOVERNMENTSYSTEMEN Schwerpunkt DVDV und SAFE Huth, Strack Inhalt 1. Allgemeines zu Verzeichnisdiensten 2. Das Projekt DVDV 1. Allgemeines 2. Komponenten

Mehr

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS

Mehr

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick Dr. Joachim Gerber INFORA-Kompetenzteam Informationssicherheit & Id-Management München, 14.06.2010 Agenda 1. Identität Begriff

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

S.A.F.E. 4. Dresdner Forum für Notarrecht. Secure Access to Federated E-Justice/E-Government

S.A.F.E. 4. Dresdner Forum für Notarrecht. Secure Access to Federated E-Justice/E-Government 4. Dresdner Forum für Notarrecht S.A.F.E. Secure Access to Federated E-Justice/E-Government Sven Voss 29. Juni 2012 Ausgangslage Ich möchte elektronisch rechtswirksame Erklärungen abgeben Einsicht in Register

Mehr

Analyse von Sicherheitaspekten in Service-orientierten Architekturen

Analyse von Sicherheitaspekten in Service-orientierten Architekturen Analyse von Sicherheitaspekten in Service-orientierten Architekturen Vortragende: Jia Jia Betreuer: Dipl.-Inf. Matthias Lehmann Dresden,10.12.2009 10.12.2009 Analyse von Sicherheitaspekten in SOA 1 Gliederung

Mehr

Registrierungsverfahren

Registrierungsverfahren Teilnahme am OSCI-gestützten elektronischen Rechtsverkehr Registrierungsverfahren gültig ab EGVP Version 2.7.0 Version 1.2 Freigabe: BLK-AG IT-Standards Seite 1 von 8 Inhaltsverzeichnis Einleitung... 3

Mehr

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I Sicherheitsaspekte in Service Orientierten Architekturen Eike Falkenberg Sommersemester 2006 Anwendungen I Agenda SOA? Web Services? Sicherheitsrisiko Web Services Web Services & Sicherheit Sichere SOAs

Mehr

Sichere Web-Services in einem föderierten Umfeld

Sichere Web-Services in einem föderierten Umfeld Sichere Web-Services in einem föderierten Umfeld ZKI Arbeitskreis Verzeichnisdienste ZEDAT FU Berlin Axel Maurer Die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH) integrierte

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

S.A.F.E.-Feinkonzept - Dokument 5: Kooperation S.A.F.E./DVDV

S.A.F.E.-Feinkonzept - Dokument 5: Kooperation S.A.F.E./DVDV S.A.F.E.-Feinkonzept - Dokument 5: Kooperation S.A.F.E./DVDV Thema: Verantwortlich: Secure Access to Federated E-Justice/E-Government Bund-Länder-Kommission für Datenverarbeitung und Rationalisierung in

Mehr

Sicherheitskonzepte in SOA auf Basis sicherer Webservices

Sicherheitskonzepte in SOA auf Basis sicherer Webservices HAW Hamburg Seminarvortrag - 16.12.2005 Thies Rubarth Folie 1 Sicherheit machen wir später...... wie hätt's auch anders sein sollen? Sicherheitskonzepte in SOA auf Basis sicherer Webservices Thies Rubarth

Mehr

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Ergebnisse der TeleTrusT-AG "SOA" SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Arbeitsergebnisse des SOA Security AKs Anfang 2009 - Themenfindung für das Dokument Mitte 2009 Vorgehenskonzept

Mehr

Positionspapier: Portalverbund und ehealth

Positionspapier: Portalverbund und ehealth Positionspapier: Portalverbund und ehealth e-government Arbeitsgruppe Integration und Zugänge (AG-IZ) Dr. Wilfried Connert Franz Hoheiser-Pförtner, MSc Rainer Hörbe Peter Pfläging Juli 2009 Inhalt Zielsetzung

Mehr

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

Mehr

S.A.F.E.-Feinkonzept - Dokument 1: System- und Schnittstellenspezifikation Föderiertes Identity Management

S.A.F.E.-Feinkonzept - Dokument 1: System- und Schnittstellenspezifikation Föderiertes Identity Management S.A.F.E.-Feinkonzept - Dokument 1: System- und Schnittstellenspezifikation Föderiertes Identity Management Thema: Verantwortlich: Secure Access to Federated E-Justice/E-Government Bund-Länder-Kommission

Mehr

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Ein Großteil der heutigen Kommunikation geschieht per email. Kaum ein anderes Medium ist schneller und effizienter. Allerdings

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

emra-x DIE ANFRAGERSCHNITTSTELLE FÜR DIE MELDEREGISTERAUSKUNFT 2.0

emra-x DIE ANFRAGERSCHNITTSTELLE FÜR DIE MELDEREGISTERAUSKUNFT 2.0 emra-x DIE ANFRAGERSCHNITTSTELLE FÜR DIE MELDEREGISTERAUSKUNFT 2.0 ÜBER UNS Die DVZ Datenverarbeitungszentrum Mecklenburg-Vorpommern GmbH (DVZ M-V GmbH) ist der IT-Service-Provider der Landesverwaltung

Mehr

Verzeichnisdienst: Firmenkonzepte. Universität Duisburg-Essen

Verzeichnisdienst: Firmenkonzepte. Universität Duisburg-Essen Verzeichnisdienst: Firmenkonzepte Universität Duisburg-Essen Übersicht 1. Problem 2. Produktvorstellungen von Sun, IBM und Siemens 3. Anforderungspapier 4. Konzepte von IBM und Sun für die Universität

Mehr

Webservices am Beispiel. De-Mail. fp-francotyp.com

Webservices am Beispiel. De-Mail. fp-francotyp.com Webservices am Beispiel De-Mail VORSTELLUNG MENTANA-CLAIMSOFT / FP Über Mentana-Claimsoft Softwarehaus seit 1999 spezialisiert auf: Qualifizierte elektronische Signaturen Langzeitarchivierung / Beweiswerterhaltung

Mehr

Sicherheit in Web Services. Seminar Service-orientierte Software Architekturen Melanie Storm

Sicherheit in Web Services. Seminar Service-orientierte Software Architekturen Melanie Storm Sicherheit in Web Services Seminar Service-orientierte Software Architekturen Melanie Storm Agenda Motivation Fallbeispiel WS-Security XML Encryption XML Signature WS-Policy WS-SecurityPolicy WS-Trust

Mehr

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen Thomas Lenggenhager thomas.lenggenhager@switch.ch Bern, 11. Juni 2010 Übersicht Die Shibboleth basierte SWITCHaai

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

Kolloquium zur Diplomarbeit

Kolloquium zur Diplomarbeit Kolloquium zur Diplomarbeit Konzeption und prototypische Umsetzung von Authentifizierungsverfahren und Kommunikationsschnittstellen für das Identity-Management-System CIDAS unter besonderer Berücksichtigung

Mehr

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216 WS-Security Sicherheitskonzepte in global verteilten Anwendungen Thies Rubarth 21. Sep 2007 ACM/GI Localgroup #216 Thies Rubarth, M.Sc. (Informatik) IT Berater Jahrgang 1979 Anwendungsentwicklung seit

Mehr

1 Die Active Directory

1 Die Active Directory 1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure

Mehr

3. Web Service Security 3.3 WS-Trust. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit

3. Web Service Security 3.3 WS-Trust. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit XML- und Webservice- Sicherheit 3. Web Service Security 3.3 WS-Trust Gliederung 1. WS-Trust 2. WS-Trust: X.509 CustomToken 3. WS-Trust: Kerberos X.509 Literatur: J. Rosenberg and D. Remy, Securing Web

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

E-Mail-Verschlüsselung Vorrausetzungen

E-Mail-Verschlüsselung Vorrausetzungen E-Mail-Verschlüsselung Vorrausetzungen Datum: 09.08.2011 Dokumentenart: Anwenderbeschreibung Version: 2.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3 2. Voraussetzungen...4

Mehr

Programmierhandbuch SAP NetWeaver* Sicherheit

Programmierhandbuch SAP NetWeaver* Sicherheit Martin Raepple Programmierhandbuch SAP NetWeaver* Sicherheit Galileo Press Bonn Boston Inhalt Vorwort 13 2.1 Sicherheit und serviceorientierte Architekturen 24 2.1.1 Sicherheitsziele der Informationssicherheit

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 15.07.2013 Dokumentenart: Anwenderbeschreibung Version: 3.2 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...

Mehr

(c) 2014, Peter Sturm, Universität Trier

(c) 2014, Peter Sturm, Universität Trier Soziotechnische Informationssysteme 6. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 1 Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung Nachweis einer behaupteten

Mehr

Identity and Access Management for Complex Research Data Workflows

Identity and Access Management for Complex Research Data Workflows Identity and Access Management for Complex Research Data Workflows Richard Zahoransky, Saher Semaan, Klaus Rechert richard.zahoransky@rz.uni-freiburg.de, semaan@uni-freiburg.de, klaus.rechert@rz.uni-freiburg.de

Mehr

IT-Umsetzung der EU- Dienstleistungsrichtlinie in Sachsen-Anhalt

IT-Umsetzung der EU- Dienstleistungsrichtlinie in Sachsen-Anhalt IT-Umsetzung der EU- Dienstleistungsrichtlinie in Sachsen-Anhalt Umsetzungskonzept - ENTWURF - Version 0.9a Stand: 08.04.2009 Inhaltsverzeichnis 1 Ausgangslage und Lösungsansatz...1 1.1 IT-Umsetzung beim

Mehr

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards:

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards: MSP SSO Portalübergreifendes Single Sign-on Für das Abwickeln von Online- Geschäftsprozessen ist es wichtig, sein Gegenüber zu kennen. Das gilt sowohl für den Kunden als auch den Betreiber des Online-

Mehr

Föderiertes Identity Management

Föderiertes Identity Management Föderiertes Identity Management 10. Tagung der DFN-Nutzergruppe Hochschulverwaltung Berlin, 09.05.-11.05.2011 Peter Gietz, CEO, DAASI International GmbH Peter.gietz@daasi.de 1 von 23 (c) Mai 2011 DAASI

Mehr

Daten-Kommunikation mit crossinx

Daten-Kommunikation mit crossinx Daten-Kommunikation mit Datenübertragung.doc Seite 1 von 8 Inhaltsverzeichnis 1 Einführung... 3 1.1 Datenübertragung an... 3 1.2 Datenversand durch... 3 2 X.400... 4 3 AS2... 4 4 SFTP (mit fester Sender

Mehr

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate

Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Seite 1 von 6 Autor: G. Raptis Gültigkeitsmodell der elektronischen Arztausweise und Laufzeit der Zertifikate Gültigkeitsmodelle beschreiben den Algorithmus nach dem ein Client oder Dienst entscheidet,

Mehr

Sachstand. Das Bürgerkonto Niedersachsen mit integrierter eid-funktion sowie epayment als Shared- Service-Angebote des Landes

Sachstand. Das Bürgerkonto Niedersachsen mit integrierter eid-funktion sowie epayment als Shared- Service-Angebote des Landes Sachstand Das Bürgerkonto mit integrierter eid-funktion sowie epayment als Shared- Service-Angebote des Landes Niedersächsisches Ministerium für für Inneres und und Sport Sport Referat 41 41 IT-Strategie

Mehr

Federated Identity Management

Federated Identity Management Federated Identity Management Verwendung von SAML, Liberty und XACML in einem Inter Campus Szenario d.marinescu@gmx.de 1 Fachbereich Informatik Inhalt Grundlagen Analyse Design Implementierung Demo Zusammenfassung

Mehr

Enterprise Web-SSO mit CAS und OpenSSO

Enterprise Web-SSO mit CAS und OpenSSO Enterprise Web-SSO mit CAS und OpenSSO Agenda Gründe für SSO Web-SSO selbst gemacht Enterprise Web-SSO mit CAS Enterprise Web-SSO mit SUN OpenSSO Federation-Management Zusammenfassung Gründe für SSO Logins

Mehr

7 Der Exchange Server 2010

7 Der Exchange Server 2010 Der Exchange Server 2010 7 Der Exchange Server 2010 Prüfungsanforderungen von Microsoft: Configuring and Managing Messaging and Collaboration o Configure email. o Manage Microsoft Exchange Server. Managing

Mehr

Sicherheitsaspekte von Web Services. Hauptseminar Rechnernetze

Sicherheitsaspekte von Web Services. Hauptseminar Rechnernetze Sicherheitsaspekte von Web Services Hauptseminar Rechnernetze Stefan Hennig sh790883@inf.tu-dresden.de 21. Januar 2005 Gliederung Einführung Überblick Sicherheit auf Netzwerk- und Transportebene XML-Sicherheit

Mehr

1. Sept. 2010. Über Keyon

1. Sept. 2010. Über Keyon Über Keyon 1 Eidgenössisches Volkswirtschaftsdepartement EVD Staatssekretariat für Wirtschaft SECO 1. September 2010, Zürich eberhard@keyon.ch 3 SuisseID: Kurz-Steckbrief Die SuisseID ist: ein ZertES-konformes

Mehr

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de Grundlagen AAI, Web-SSO, Metadaten und Föderationen Wolfgang Pempe, DFN-Verein pempe@dfn.de DFN-AAI IdP-Workshop, 24./25. Juni 2015, HS Amberg-Weiden Was ist DFN-AAI? AAI Authentifizierung Autorisierung

Mehr

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF Dipl.-Inf. Lutz Suhrbier Prof. Dr.-Ing. Robert Tolksdorf Dipl.-Inf. Ekaterina Langer Freie Universität Berlin Institut

Mehr

Produktinformation. bi-cube Identity Server. T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g

Produktinformation. bi-cube Identity Server. T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g rmation bi-cube Identity Server T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Inhalt 1 DIE LÖSUNG ZU EINER GESICHERTEN AUTHENTIFIKATION...3 2 BI-CUBE IDENTITY SERVER IN EINEM IPM

Mehr

DriveLock in Terminalserver Umgebungen

DriveLock in Terminalserver Umgebungen DriveLock in Terminalserver Umgebungen Technischer Artikel CenterTools Software GmbH 2011 Copyright Die in diesen Unterlagen enthaltenen Angaben und Daten, einschließlich URLs und anderen Verweisen auf

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Intelligente und organisationsübergreifende Authentifikations- und Signaturmethoden

Intelligente und organisationsübergreifende Authentifikations- und Signaturmethoden Intelligente und organisationsübergreifende Authentifikations- und Signaturmethoden Markus Hertlein hertlein@internet-sicherheit.de Institut für Internet-Sicherheit if(is) Westfälische Hochschule, Gelsenkirchen

Mehr

Sichere Authentifizierung SSO, Password Management, Biometrie. 21.06.2007 Dr. Horst Walther, KCP hw@kuppingercole.de

Sichere Authentifizierung SSO, Password Management, Biometrie. 21.06.2007 Dr. Horst Walther, KCP hw@kuppingercole.de Sichere Authentifizierung SSO, Password Management, Biometrie 21.06.2007 Dr. Horst Walther, KCP hw@kuppingercole.de Single Sign-On, Password Management, Biometrie Single Sign-On: Anmeldung an mehreren

Mehr

De-Mail. So einfach wie E-Mail, so sicher wie Papierpost. Dr. Uwe Schiel. (BearingPoint GmbH, Berater für den IT-Stab, BMI)

De-Mail. So einfach wie E-Mail, so sicher wie Papierpost. Dr. Uwe Schiel. (BearingPoint GmbH, Berater für den IT-Stab, BMI) De-Mail So einfach wie E-Mail, so sicher wie Papierpost Dr. Uwe Schiel (BearingPoint GmbH, Berater für den IT-Stab, BMI) Weitere Informationen unter 14. Ministerialkongress (Berlin, 10.09.2009) 1 Problemlage

Mehr

S Sparkasse Markgräflerland. Secure E-Mail: Sicher kommunizieren per E-Mail. Kundeninformation. Sparkassen-Finanzgruppe

S Sparkasse Markgräflerland. Secure E-Mail: Sicher kommunizieren per E-Mail. Kundeninformation. Sparkassen-Finanzgruppe S Sparkasse Markgräflerland Secure E-Mail: Sicher kommunizieren per E-Mail. Kundeninformation Sparkassen-Finanzgruppe Gute Gründe für Secure E-Mail Mit Secure E-Mail reagiert die Sparkasse Markgräflerland

Mehr

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07. Zusicherung von Qualitätskriterien bei WebServices Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.2003 Agenda Verteilte Systeme am am Beispiel Beispiel Aspekte von Verteilung

Mehr

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13 NEWpixi* API und die Umstellung auf REST Fakten NEWpixi* API Technik REST-basierend.NET Webservice IIS Webserver Release 31. August 2013, zusammen mit dem NEWpixi* ELI Release Legacy API und erste NEWpixi*

Mehr

dvv.virtuelle Poststelle

dvv.virtuelle Poststelle Allgemeine Information zu unseren Angeboten über die dvv.virtuelle Poststelle 1 Ausgangssituation Der Einsatz von E-Mail als Kommunikations-Medium ist in der öffentlichen Verwaltung längst selbstverständliche

Mehr

Sehr geehrte/r Newsletter Abonnent/in. Behörden. Zugang zum Dokument: http://reference.egovernment.gv.at/weitere_informationen.506.0.

Sehr geehrte/r Newsletter Abonnent/in. Behörden. Zugang zum Dokument: http://reference.egovernment.gv.at/weitere_informationen.506.0. September 2006 Sehr geehrte/r Newsletter Abonnent/in Dieser Newsletter des Reference Servers liefert Ihnen einen Überblick über die neuesten Ergebnisse der Kooperation auf dem Gebiet des E-Government.

Mehr

VPS. progov VPS TRESOR

VPS. progov VPS TRESOR Mit SICHERHEIT die richtige Lösung Virtuellen Poststelle progov Ordnungsgemäße Veraktung von De-Mail Ein- und Ausgängen in der Verwaltung Michael Genth Key Account Manager VPS Elektronische Kommunikationsregeln

Mehr

secunet Security Networks AG De-Mail 21.09.2010 Steffen Heyde, secunet Security Networks AG

secunet Security Networks AG De-Mail 21.09.2010 Steffen Heyde, secunet Security Networks AG De-Mail 21.09.2010 Steffen Heyde, Agenda 1 Wie funktioniert De-Mail? 2 De-Mail für Unternehmen sowie öffentliche Stellen 3 De-Mail in der Pilotierung 4 Fragen und Antworten 2 De-Mail-Dienste im Überblick

Mehr

Studie Interoperables Identitätsmanagement für Bürgerkonten

Studie Interoperables Identitätsmanagement für Bürgerkonten Referat ITI4 ITI4-17000/26#4 Studie Interoperables Identitätsmanagement für Bürgerkonten - Management Summary - Projektgruppe Strategie für eid und andere Vertrauensdienste im E-Government eid-strategie

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr

Bildungsportal-Verbund

Bildungsportal-Verbund Bildungsportal-Verbund BPVP Bildungsportal-Verbund Protokoll Kurzspezifikation Für weitere technische Details nehmen kontaktieren Sie bitte: Robert.kristoefl@bmbwk.gv.at Thomas.menzel@bmbwk.gv.at Version

Mehr

Sichere Kommunikation für SOAP-basierte Web Services

Sichere Kommunikation für SOAP-basierte Web Services Whitepaper SOA Security Framework Sichere Kommunikation für SOAP-basierte Web Services Holger Junker, BSI, soa@bsi.bund.de Die Sicherheitsanforderungen an SOA Infrastrukturen und den darin stattfindenden

Mehr

De-Mail. So einfach wie E-Mail, so sicher wie Papierpost. www.de-mail.de www.fn.de-mail.de

De-Mail. So einfach wie E-Mail, so sicher wie Papierpost. www.de-mail.de www.fn.de-mail.de De-Mail So einfach wie E-Mail, so sicher wie Papierpost. 1 Die heutige E-Mail ist deutlich unsicherer als die Papierpost E-Mails können mit wenig Aufwand mitgelesen werden. Kommunikationspartner können

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

Mehr

Performance Untersuchung von WS Security Implementierungen in interoperablen Umgebungen

Performance Untersuchung von WS Security Implementierungen in interoperablen Umgebungen Performance Untersuchung von WS Security Implementierungen in interoperablen Umgebungen Master Thesis Outline Eike Falkenberg Im Master Studiengang Informatik Wintersemester 2006 / 2007 Department Informatik

Mehr

Initiative»Elektronische Fallakte«

Initiative»Elektronische Fallakte« Deklarative Sicherheit zur Spezifikation und Implementierung der elektronischen FallAkte Workshop»Sichere Informationstechnologie für das Gesundheitswesen von morgen«gmds Jahrestagung 2010, Mannheim R.

Mehr

S Kreis- und Stadtsparkasse

S Kreis- und Stadtsparkasse S Kreis- und Stadtsparkasse Kaufbeuren im September 2011 Informationen zum sicheren E-Mailverkehr Mit diesem Schreiben wollen wir Ihnen Inhalt: 1. die Gründe für die Einführung von Sichere E-Mail näher

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Technische Konzeption der Bürgerportale

Technische Konzeption der Bürgerportale Technische Konzeption der Bürgerportale Armin Wappenschmidt (secunet) Weitere Informationen unter www.buergerportale.de www.bmi.bund.de 1 Agenda Technische Übersicht über Bürgerportale Postfach- und Versanddienst

Mehr

S.A.F.E.-Feinkonzept - Dokument 3: Migrationskonzept EGVP/S.A.F.E.

S.A.F.E.-Feinkonzept - Dokument 3: Migrationskonzept EGVP/S.A.F.E. S.A.F.E.-Feinkonzept - Dokument 3: Migrationskonzept EGVP/S.A.F.E. Thema: Verantwortlich: Secure Access to Federated E-Justice/E-Government Bund-Länderkommission für Datenverarbeitung und Rationalisierung

Mehr

E-POSTBRIEF Sicherheit in der digitalen Schriftkommunikation

E-POSTBRIEF Sicherheit in der digitalen Schriftkommunikation E-POSTBRIEF Sicherheit in der digitalen Schriftkommunikation Dr. André Wittenburg, Vice President Architektur & Plattformstragie i2b, Bremen, Februar 2012 1 Der E-Postbrief: Ein kurzer Überflug 2 Sicherheit

Mehr

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten Handelsplatz Köln.de Leitfaden zur Projektplanung bei en Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei en Autor: Christoph Winkelhage Status: Version 1.0 Datum:

Mehr

OpenLDAP, adieu? Ein LDAP Server in Java: ApacheDS Reality Check. Stefan Zörner

OpenLDAP, adieu? Ein LDAP Server in Java: ApacheDS Reality Check. Stefan Zörner OpenLDAP, adieu? Ein LDAP Server in Java: ApacheDS Reality Check Stefan Zörner Zusammenfassung. Short Talk: OpenLDAP, adieu? Ein LDAP Server in Java: ApacheDS Reality Check Das Apache Directory Projekt

Mehr

Nutzerbeirat 2012 Bonn 20.11.2012

Nutzerbeirat 2012 Bonn 20.11.2012 Der neue Personalausweis Einsatzmöglichkeiten in der Lucom Interaction Platform Nutzerbeirat 2012 Bonn 20.11.2012 Henning Meinhardt Leiter Software Entwicklung Ab Version 3.2.2 unterstützt die LIP den

Mehr

Information über die Secure E-Mail

Information über die Secure E-Mail Information über die Secure E-Mail Ihre Möglichkeiten Der Austausch von verschlüsselten E-Mails kann auf 3 Arten erfolgen 1. über das Webmail-Portal: Direkt empfangen und senden Sie vertrauliche Informationen

Mehr

Kundeninformation zu Secure E-Mail

Kundeninformation zu Secure E-Mail S Sparkasse Höxter Kundeninformation zu Secure E-Mail,,Digitale Raubzüge und Spionageangriffe gehören aktuell zu den Wachstumsbranchen der organisierten Kriminalität. Selbst modernste Sicherheitstechnologie

Mehr

Elektronische Gewerbemeldung

Elektronische Gewerbemeldung E-Government in der IHK-Organisation Elektronische Gewerbemeldung Arbeitshilfe für die Prozess-Implementierung: Technische Rahmenbedingungen für die Anlieferung von Gewerbemeldungen an die IHK-Organisation

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language.

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language. Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo Security Assertion Markup Language Björn Rathjens Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo 1 Einführung

Mehr

Bayerisches Staatsministerium des Innern, für Bau und Verkehr. Sichere elektronische Kommunikation. Warum? www

Bayerisches Staatsministerium des Innern, für Bau und Verkehr. Sichere elektronische Kommunikation. Warum? www Erreichbarkeitsplattform Bayern ein Beitrag zum Datenschutz und zur Cyber-Sicherheit Berthold Gaß Bayerisches Staatsministerium des 6. Bayerisches Anwenderforum egovernment München 21./22. Mai 2014 www.dienstleistungsportal.bayern.de

Mehr

Anwendungsintegration an Hochschulen am Beispiel von Identity Management. Norbert Weinberger - Sun Summit Bonn 26.4.2006

Anwendungsintegration an Hochschulen am Beispiel von Identity Management. Norbert Weinberger - Sun Summit Bonn 26.4.2006 Anwendungsintegration an Hochschulen am Beispiel von Identity Management Norbert Weinberger - Sun Summit Bonn 26.4.2006 Ausgangslage: Anwendungsinseln Zugang zu IT- Ressourcen, z.b. Radius Rechenzentrum

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

XJustiz und IuK-Infrastruktur

XJustiz und IuK-Infrastruktur Workshop XJustiz und IuK-Infrastruktur Stuttgart 22. bis 23. Februar 2006 Justizministerium Baden-Württemberg - IuK-Referat Folie 1 Mittwoch, 22. Februar 2006 Auftakt Plenumsvorträge 13:00 Uhr Begrüßung

Mehr

S Sparkasse. UnnaKamen. Secure Mail Notwendigkeit?

S Sparkasse. UnnaKamen. Secure Mail Notwendigkeit? S Sparkasse UnnaKamen Secure Mail Notwendigkeit? Das sogenannte Sniffen, Ausspähen von E-Mailinhalten und Authentifizierungsdateien sowie das E-Mail Spoofing, das Erstellen einer E-Mail mit gefälschtem

Mehr

Inhaltsverzeichnis Vorwort Konzepte des Active Directory

Inhaltsverzeichnis Vorwort Konzepte des Active Directory Vorwort.................................................................. XI Warum dieses Buch.................................................... XI Kapitelübersicht.......................................................

Mehr

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Das E-Mail-Programm Outlook 98 von Microsoft bietet Ihnen durch die Standard- Integration des E-Mail-Protokolls S/MIME (Secure/MIME) die Möglichkeit,

Mehr

Vorab: Anlegen eines Users mit Hilfe der Empfängerbetreuung

Vorab: Anlegen eines Users mit Hilfe der Empfängerbetreuung Seite 1 Einrichtung der Verschlüsselung für Signaturportal Verschlüsselung wird mit Hilfe von sogenannten Zertifikaten erreicht. Diese ermöglichen eine sichere Kommunikation zwischen Ihnen und dem Signaturportal.

Mehr

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SO A Fraunhofer-Institut für Softwareund Systemtechnik ISST Dr. Ulrich Springer Dr. Bernhard Holtkamp Dortmund, 20.01.2009

Mehr

E-Mail Verschlüsselung

E-Mail Verschlüsselung E-Mail Verschlüsselung S/MIME Standard Disclaimer: In der Regel lässt sich die Verschlüsselungsfunktion störungsfrei in den E-Mail-Programmen einrichten. Es wird aber darauf hingewiesen, dass in einigen

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

MOA-ID Workshop. Anwendungsintegration, Installation und Konfiguration. Klaus Stranacher Graz, 25.06.2013

MOA-ID Workshop. Anwendungsintegration, Installation und Konfiguration. Klaus Stranacher Graz, 25.06.2013 MOA-ID Workshop Anwendungsintegration, Installation und Konfiguration Graz, 25.06.2013 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Überblick»

Mehr