E-Government-Initiative für D und den neuen Personalausweis

Transkript

1 E-Government-Initiative für D und den neuen Personalausweis Stadt Mörfelden-Walldorf in Zusammenarbeit mit ekom21 KGRZ Hessen Architekturkonzept zum neuen Personalausweis Das Bundesministerium des Innern ist nicht verantwortlich für den Inhalt der Ergebnisdokumente, die im Rahmen der E-Government-Initiative für D und den neuen Personalausweis erstellt wurden. Deshalb werden die jeweils Verantwortlichen im Impressum auf der letzten Seite der Dokumente genannt. Sie stehen Ihnen für inhaltliche Fragen zur Verfügung.

2 Architekturkonzept zum neuen Personalausweis Version 0.91 vom Stadt Mörfelden-Walldorf in Zusammenarbeit mit ekom21-kgrz Hessen und der E-Government Initiative des BMI 1/30

3 Inhaltsverzeichnis 1 Einleitung Rahmenbedingungen Evaluierung eid-services Übersicht eid-server Hersteller OpenLimit SignCubes GmbH media transfer AG Bremen Online Services Entwicklungs- und Betriebsgesellschaft mbh & Co. KG AGETO Innovation GmbH Übersicht eid-service Anbieter AGETO Innovation GmbH Atos Worldline GmbH Bremen online services Bundesdruckerei GmbH Deutsche Post Signtrust und DMDA GmbH ]init[ AG Kommunale Datenverarbeitung Region Stuttgart (KDRS) / Rechenzentrum Region Stuttgart GmbH (RZRS) Telesec/T-Systems Anbieter von Berechtigungszertifikaten Übersicht eid-clients AusweisApp AGETO AusweisApp: Bos Governikus Autent Open ecard App (mobile Eignung) Einsatz mobiler Endgeräte eid-integrationsmöglichkeiten Auswahlverfahren Auswahlkriterien Multi-Mandantenfähigkeit Multi-Dienste-Fähigkeit Plattform-Unabhängigkeit der Dienste Zentrales eid-know-how Option eines späteren Eigenbetriebs eines eid-servers Auswahl der Variante zur Anbindung eines eid-services Auswahl eines eid-service-anbieters Technische Anbindung an bestehende IT-Infrastruktur Anbindung der Fachverfahren mit AGETO eid-gateway Anbindung der Fachverfahren mit eigenentwickeltem eid-dienst Architektur des ekom21 eid-dienstes Kommunikationsablauf ekom21 eid-dienst SOAP-Schnittstelle des ekom21 eid-dienstes /30

4 6 Anhang WSDL-Definition des ekom21 eid-dienstes Tabellenverzeichnis Tabelle 1: Parameter EIDSessionRequest Tabelle 2: Rückgabewerte der Funktion geteidsession Tabelle 3: Parameter des geteidresult Request Tabelle 4: Rückgabewerte des EIDResultResponse Tabelle 5: Rückgabewerte im Datentyp EIDServiceResult Abbildungsverzeichnis Abbildung 1: Ablauf der eid-nutzung... 5 Abbildung 2: AusweisApp Abbildung 3: AGETO AusweisApp Abbildung 4: Governikus Autent App Abbildung 5: Open ecard App Abbildung 6: Das AGETO eid-gateway Abbildung 7: eid-architektur ekom Abbildung 8: Kommunikationsablauf des ekom21 eid-dienstes Abbildung 9: Funktionen des ekom21 eid-dienstes Abbildung 10: getiedsession Request Abbildung 11: geteidsession Response Abbildung 12: geteidresult Request Abbildung 13: EIDResultResponse Abbildung 14: Datentyp EIDServiceResult /30

5 1 Einleitung Das Fachszenario sieht die elektronische Anmeldung einer Wohnung im Bereich des Meldewesens vor. Die Details werden im Fachkonzept beschrieben. Technisch wird die Webschnittstelle für die Anmeldung einer Wohnung mit dem kommunalen Fallmanagement fm21 abgebildet. fm21 ist ein Basismodul der egovernment-suite der ekom21 und als fachverfahrensübergreifendes Workflow-Management-System zu verstehen. Die Bereitstellung der eid-funktionalität wird hingegen als zentrale Komponente im Rechenzentrum der ekom21 realisiert. Hierdurch sollen auch weitere Webanwendungen diese Funktion nutzen können. Die zentrale eid-komponente ist Bestandteil dieses Architekturkonzepts, das die Darstellungen der IT-Architektur bzw. der technischen Umsetzung beinhaltet. Dabei werden verschiedene eid-server und eid-services betrachtet. Weiterhin wird der Aufbau der Komponente dargestellt, die die gesamte eid-funktionalität als Schnittstelle zwischen Fachverfahren und eid-server bereitstellen soll. Neben diesem Architekturkonzept beschreiben zwei weitere Konzepte zur Realisierung und Sicherheit die fachlichen Hintergründe sowie den IT- Sicherheitsrahmen. Die Dokumente wurden mit Unterstützung der E-Government-Initiative des BMI entwickelt. Das BMI wird die Ergebnisse anderen Gemeinden in Deutschland zur Verfügung stellen, um deren E-Government-Projekte zu beschleunigen. Dabei soll diese Konzeption insbesondere bei der Auswahl geeigneter eid-services und der Realisierung einer eid-lösung helfen. 4/30

6 2 Rahmenbedingungen Der spätere Betrieb einer eid-architektur unterliegt bei der ekom21 Rahmenbedingungen, die sich insbesondere in der RZ-Architektur und in den Betriebsanforderungen begründen. Hierbei spielt insbesondere das Thema IT-Sicherheit und die ISO Zertifizierung auf Basis von IT-Grundschutz eine wichtige Rolle. Dabei müssen die Richtlinien zur Aufnahme in den Rechenzentrums-Betrieb erfüllt sein, auf die an dieser Stelle nicht weiter eingegangen wird. Neben den grundsätzlichen Betriebsfragen gibt es weitere technisch- und fachlich gelagerte Rahmenbedingungen, die in Kapitel Auswahlkriterien näher beschrieben sind. Grundsätzlich besteht die Intension, die eid-funktionalitäten durch verschiedene Verfahren und mehrere Mandanten nutzen zu können. Aus diesem Grund muss eine zentrale eid- Komponente multi-fachverfahrens- und multi-mandanten-fähig sein. Darüber hinaus ist insbesondere das Thema Berechtigungszertifikate von zentraler Bedeutung, da es wesentliche monetäre Auswirkungen haben kann. Berechtigungszertifikate bilden die Grundlage für die Nutzung von eid-services. Die Bescheide zur Beantragung von Berechtigungszertifikaten müssen beim Bundesverwaltungsamt beantragt und durch dieses ausgestellt werden. Im Antrag auf Ausstellung eines Berechtigungszertifikates sind die auszulesenden Werte aus dem neuen Personalausweis anzugeben und zu begründen, auf welcher rechtlichen Grundlage diese ausgelesen werden dürfen. Hier ist zu prüfen, ob die ekom21 ein Zertifikat für mehrere Kommunen und/oder verschiedene Verfahren einsetzen darf oder ob jeweils ein eigenständiges Zertifikat von Nöten ist. Abbildung 1: Ablauf der eid-nutzung 5/30

7 3 Evaluierung eid-services Zur Nutzung des elektronischen Identitätsnachweises auf Seiten des Dienstanbieters wird ein sogenannter eid-server benötigt. Der eid-server ermöglicht es Dienstanbietern, die Online-Ausweisfunktion in ihre bereits existierenden IT-Systeme zu integrieren. Er steuert die elektronische Kommunikation zwischen dem Online-Angebot des Unternehmens oder der Behörde und dem neuen Personalausweis der Bürgerin oder des Bürgers. Das heißt er übernimmt die sichere Kommunikation mit der Client-Software (z.b. AusweisApp) und dem Personalausweischip und gibt ausgelesene Daten an den Dienst weiter. Das Berechtigungszertifikat, mit dem sich der Dienstanbieter gegenüber dem Nutzer seines Online-Angebotes authentifiziert, wird auf dem eid-server vorgehalten. Die Authentifizierungskomponente, die die Bürgerin oder der Bürger verwendet, sendet die freigegebenen Daten aus dem neuen Personalausweis an diesen eid-server, der die Daten wiederum zum Online-Angebot des Unternehmens oder der Behörde überträgt. Weiterhin stellt der eid-server die Authentizität und die Gültigkeit des Personalausweises fest, und prüft, ob dieser vom Besitzer gesperrt wurde. Außerdem ist der eid-server in der Lage, regelmäßig neue Berechtigungszertifikate sowie aktualisierte Sperrlisten für Dienstanbieter automatisch von der BerCA zu beziehen. Dem Dienstanbieter stehen grundsätzlich zwei alternative Integrationsszenarien zur Auswahl: Er kann seinen eigenen eid-server betreiben oder den eid-service eines externen Dienstleisters nutzen. Betreibt der Dienstanbieter einen eigenen eid-server muss er selbst für die Einhaltung der organisatorischen, technischen und sicherheitstechnischen Maßnahmen zur Durchführung der Online-Authentisierung sorgen. Webserver und eid-server sind hier meist in einer geschützten Umgebung des Dienstanbieters aufgestellt und über ein internes Netz verbunden. Sie können sich jedoch auch an verschiedenen Standorten befinden und müssen dann geschützt kommunizieren. Durch Nutzung eines eid-services sinken die Anforderungen an den Dienstanbieter, da insbesondere Sicherheitsanforderungen vom eid-service Betreiber erfüllt werden müssen. Die folgenden Kapitel geben einen Marktüberblick über verfügbare eid-server und eid- Services und sollen bei der Auswahl eines geeigneten eid-servers / eid-dienstes unterstützen. 3.1 Übersicht eid-server Hersteller Es existieren die folgenden eid-server Hersteller. 6/30

8 3.1.1 OpenLimit SignCubes GmbH Die OpenLimit SignCubes GmbH 1 als Hersteller der AusweisApp vertreibt die benötigte Software zum Betrieb eines eid-servers. Ein eigener eid-service wird nicht zur Nutzung angeboten. Als Betriebssystembasis wird Solaris 10 benötigt. 2 Der OpenLimit eid-sever wird unter anderem von der Bundesdruckerei als eid-service zur Verfügung gestellt. Kontakt: OpenLimit SignCubes AG Vertrieb und Consulting Saarbrücker Str. 38A Berlin Telefon +49 (0) Telefax +49 (0) sales@openlimit.com Internet media transfer AG Das media Transfer eid-serverprodukt auf Basis von J2EE Java Enterprise Komponentenarchitektur 3 wird als eid-service zukünftig von der Telesec (T-Systems) angeboten. Der mtg eid-server ist in den Produktvarianten Stand-alone und Clusterlösung verfügbar und ermöglicht in der Clusterlösung auch den ausfallsicheren Betrieb von HSM Clustern. Kontakt: media transfer AG Dolivostraße Darmstadt Günter Hirschmann Business Development Manager Telefon: +49 (0) / -29 Telefax: +49 (0) ghirschmann@mtg.de Internet 1 Vgl. 2 Vgl. 3 Vgl. 7/30

9 3.1.3 Bremen Online Services Entwicklungs- und Betriebsgesellschaft mbh & Co. KG Die Firma bos bietet zwei Betriebsformen für die Nutzung des eid-servers an. Zum einen ist der Betrieb eines eigenen Autent-Servers als eigener eid-server möglich, zum anderen besteht die Möglichkeit der Nutzung des bos eigenen eid-servers als eid-service. 4 Behörden können den bos Server teilweise im Rahmen des bestehenden Governikus Rahmenvertrags beziehen. Der bos Server wird z.b. von der Deutsche Post Signtrust als eid-service angeboten. Kontakt: bremen online services GmbH & Co. KG (bos) Am Fallturm Bremen Jens de Haan Projektmanager Telefon +49 (0) Telefax +49 (0) kontakt@bos-bremen.de Internet AGETO Innovation GmbH Die AGETO Holding AG bietet sowohl die nötige Software zum Betrieb eines eid-servers an, als auch ein eid-gateway als Schnittstelle zum Anbinden verschiedener eid-server. Der eid-server der AGETO ist rein Java basiert und kann daher auf diversen Plattformen betrieben werden. 5 Ein eigener eid-server wird nicht als eid-service zur Verfügung gestellt. Hier wird mit der Bundesdruckerei kooperiert. Kontakt: AGETO Innovation GmbH Winzerlaer Straße Jena Christian Bruntsch Telefon +49 (0) Telefax +49 (0) c.bruntsch@ageto.de Internet 4 Vgl. 5 Vgl. bzw. 8/30

10 3.2 Übersicht eid-service Anbieter Der sogenannte eid-service eines beauftragten externen Dienstleisters, der für mehrere Dienste einen mandantenfähigen eid-server betreibt, ist eine weitere Möglichkeit sich als Dienstanbieter an die Infrastruktur anzubinden. Auch in diesem Fall ist der Dienstanbieter der Inhaber der Berechtigung und damit für die Einhaltung sämtlicher Vorgaben und Anforderungen im eigenen Haus sowie im Falle der Aufgabenübertragung an einen Dritten vollständig verantwortlich. Der eid-service regelt die gesamte Kommunikation mit dem Personalausweis-Chip sowie den Bezug aktueller Berechtigungszertifikate und Sperrlisten, übermittelt nach erfolgreicher Authentisierung des Personalausweisinhabers die aus dem Ausweis-Chip gelesenen Daten an den anfragenden Dienst, kommuniziert mit dem Anbieter über eine abgesicherte SSL- Verbindung und kann auch bei der Beantragung von Berechtigungen bei der VfB unterstützen. Bei Beauftragung eines eid-services müssen die kryptografischen Schlüssel für die Kommunikation zwischen dem Dienstanbieter und dem eid-service auf beiden Seiten auf dem gleichen sicheren Schutzniveau gespeichert werden. Soll ein eid-service verwendet werden, findet sich im Folgenden eine Übersicht der möglichen Anbieter: AGETO Innovation GmbH Der eid-server ist eine Eigenentwicklung der AGETO Innovation GmbH. Kontakt: AGETO Innovation GmbH Winzerlaer Straße Jena Christian Bruntsch Telefon +49 (0) Telefax +49 (0) c.bruntsch@ageto.de Internet 9/30

11 3.2.2 Atos Worldline GmbH Atos Worldline GmbH implementiert den neuen Personalausweis (npa) zur Authentifizierung bei Onlinezahlungen. Außerdem verfügt das Unternehmen mit Worldline Ident über einen eigenen eid-service. Kontakt: Atos Worldline GmbH Hahnstraße Frankfurt Telefon +49 (0) Internet Bremen online services Bos nutzt den eigenentwickelten Governikus eid-server. Kontakt: bremen online services GmbH & Co. KG (bos) Am Fallturm Bremen Jens de Haan Projektmanager Telefon +49 (0) Telefax +49 (0) kontakt@bos-bremen.de Internet Bundesdruckerei GmbH Die Bundesdruckerei nutzt den OpenLimit eid-server und betreibt diesen unter dem Produktnamen D-Trust. Zusätzlich stellt sie als Zertifizierungsstelle Berechtigungszertifikate aus. Ebenfalls ist der Bezug von Demo-Ausweisen über die Bundesdruckerei möglich. Zur Nutzung des D-Trust eid-services wird eine sogenannte eid-anbindung, die auf Java Servlets beruht, zur Verfügung gestellt. 10/30

12 Kontakt: Bundesdruckerei GmbH Oranienstraße Berlin Mark Rüdiger / Joachim Mahlstedt Telefon +49 (0) / +49 (0) mark.ruediger@bdr.de / joachim.mahlstedt@bdr.de Internet Deutsche Post Signtrust und DMDA GmbH Die Deutsche Post AG stellt ihren eid-server (Hersteller ist bos) als eid-service im ASP- Verfahren bereit. Eine Java-Bibliothek zur Erweiterung des Webservices für den eid-service wird zur Verfügung gestellt. 6 In der Produktbeschreibung wirbt die Deutsche Post mit einer Abrechnung nach tatsächlich angefallenen Transaktionen. Kontakt: Deutsche Post Signtrust und DMDA GmbH Charles-de-Gaulle-Straße Bonn Telefon +49 (0) info@deutschepost.signtrust.de Internet ]init[ AG Die ]init[ AG betreibt einen eid-server und bietet auch eid-services an. Dabei kommt als eid-server-produkt die Variante von OpenLimit zum Einsatz. Kontakt: ]init[ AG für Digitale Kommunikation Köpenicker Straße Berlin Telefon +49 (0) Telefax +49 (0) eid@init.de Internet 6 Vgl. 11/30

13 3.2.7 Kommunale Datenverarbeitung Region Stuttgart (KDRS) / Rechenzentrum Region Stuttgart GmbH (RZRS) Die Kommunale Datenverarbeitung Region Stuttgart (KDRS) und das Rechenzentrum Region Stuttgart GmbH (RZRS) stellen einen eid-service auf Basis des eid-servers der Firma OpenLimit bereit. Der Dienst wird unter anderem von der WGV Versicherung 7 benutzt. Kontakt: Kommunale Datenverarbeitung Region Stuttgart (KDRS) / Rechenzentrum Region Stuttgart GmbH (RZRS) Krailenshaldenstraße Stuttgart Victor Kostic Leiter Geschäftsfeldentwicklung Telefon +49 (0) Telefax +49 (0) eid-sales@kdrs.de Internet Telesec/T-Systems Die Telesec eid-service-lösung ist ein Cloud-basiertes Produkt auf Basis des eid-servers der Firma media transfer AG. Neben dem eid-server-betrieb tritt Telesec auch als Aussteller von Berechtigungszertifikaten auf. Das Produkt ist angekündigt, wird aber noch nicht auf den Webseiten der Telesec beworben. 3.3 Anbieter von Berechtigungszertifikaten Für jeden elektronischen Dienst ist ein Berechtigungszertifikat erforderlich, das die gegenseitige Authentisierung von Nutzer und Anbieter ermöglicht. Das Berechtigungszertifikat ist eine elektronische Bescheinigung, die vom Chip des Personalausweises vor jedem Lesevorgang geprüft wird. Es legt fest, welche personen- und ausweisbezogenen Daten der Anbieter eines Dienstes aus dem Personalausweis des Nutzers abfragen darf. Um ein Berechtigungszertifikat erwerben zu können, benötigen Sie als Dienstanbieter eine Berechtigung der staatlichen Vergabestelle für Berechtigungszertifikate (VfB) im Bundesverwaltungsamt. Mit der staatlichen Berechtigung können dann bei einem Zertifikate-Anbieter (BerCA) entsprechende Berechtigungszertifikate erworben werden. 7 Vgl. QUERYSTRING=eid 12/30

14 Es existieren derzeit folgende Zertifikatanbieter. T-Systems International GmbH/Trust Center Deutsche Telekom D-Trust Deutsche Post Signtrust In der Regel kooperiert der ausgewählte eid-service-anbieter mit einem Aussteller von Berechtigungs-Zertifikaten und führt die Kosten für das Zertifikat in seiner Angebotskalkulation mit auf. Eine Evaluierung des Zertifikatsanbieters ist daher nur notwendig wenn ein eigener eid-server betrieben werden soll. Diese plant die ekom21 im ersten Schritt noch nicht, so dass die Zertifikatsanbieter nicht weiter evaluiert werden sollen. 3.4 Übersicht eid-clients Aktuell stehen folgende eid-clients zur Verwendung mit dem neuen Personalausweis zur Verfügung: AusweisApp Die offizielle AusweisApp des Bundes unterstützt alle in den technischen Richtlinien des BSI definierten Vorgaben und wird dem Bürger kostenfrei unter zur Verfügung gestellt. Derzeit steht die AusweisApp für Windows XP, Vista, 7, 8, Ubunto ab 10.4, Debian Linux 6, opensuse ab 11.4 und Mac OS X ab 10.6 zur Verfügung. Unter Windows wird aktuell nur der Firefox in einer ESR Version und der Internet Explorer unterstützt. Mit der Spezifizierung und Anpassung der Technischen Richtlinien TR und TR in 2012 und der im Februar 2013 veröffentlichten Version der AusweisApp wurde eine alternative Client-Aktivierung eingeführt. Die eid-server werden in einer Übergangsfrist bis Ende 2013 ebenfalls angepasst. Bisher wurde für den Aufruf der AusweisApp immer ein Browser-PlugIn benötigt, das dann die AusweisApp anspricht. Dies grenzt die Nutzung auf bestimmte Browser-Versionen ein, für die entsprechende AusweisApp-Plugins verfügbar sind. Mit der alternativen Client-Aktivierung wird der PlugIn-Ansatz durch den Aufruf eines lokalen Links ( + Aufruf-Parameter) ersetzt. Damit kann die AusweisApp in Zukunft direkt angesprochen werden. Dies ermöglicht die Nutzung der AusweisApp aus beliebigen Programmen (z.b. auch auf mobilen Endgeräten oder FatClients) /30

15 Abbildung 2: AusweisApp AGETO AusweisApp: Die AGETO AusweisApp ist eine Java-Implementierung der ecard-api die nur ca. 650kb groß ist. Derzeit kann die AGETOApp noch nicht den vollen Funktionsumfang der AusweisApp abdecken, beherrscht aber die wesentliche Funktion der Online Identifikation. Die AGETO AusweisApp ist plattformunabhängig und lässt sich prinzipiell auch auf mobilen Endgeräten verwenden, sofern entsprechende NFC Lesegeräte vorhanden sind. Abbildung 3: AGETO AusweisApp 14/30

16 3.4.3 Bos Governikus Autent Es handelt sich hierbei um ein Java-Applet, dass nur in Verbindung mit dem eid-server der bos verwendet werden kann. Die Lösung unterstützt nur die Online Ausweisfunktion, hat aber den Vorteil, dass User sich die AusweisApp nicht installieren müssen. Abbildung 4: Governikus Autent App Open ecard App (mobile Eignung) Das Open Source ecard-projekt Open ecard stellt eine freie Variante der AusweisApp zur Verfügung. Das Projekt befindet sich noch in der Implementierung. Eine Web-Start Anwendung konnte unter Windows bereits präsentiert werden. Eine mobile Umsetzung für das Android Betriebssystem ist in Arbeit. Da die Open ecardapp die neu spezifizierte alternative Client-Aktivierung verwendet, ist sie noch nicht produktiv nutzbar. Abbildung 5: Open ecard App 15/30

17 3.5 Einsatz mobiler Endgeräte Mobiltelefone mit Near Field Communication (NFC) können prinzipiell als npa-lesegeräte eingesetzt werden, da NFC die kontaktlosen Protokolle des npa gemäß ISO Typ A und B unterstützt allerdings sind NFC-Standards und ISO nicht vollständig kompatibel. Das führt dazu, dass es von namenhaften Herstellern wie RIM, Huawei, Nokia und Samsung zahlreiche Smartphones mit NFC Controller gibt. Ein Smartphone, dessen NFC-Chip den Personalausweis jedoch vollumfänglich unterstützt, ist bisher nicht bekannt. Eines der wesentlichen Probleme sind dabei die Kartenkommandos mit mehr als 256 Byte Daten (Extended Length APDUs), wie sie beim npa z.b. für die Übertragung von Berechtigungszertifikaten (größer 400 Byte) notwendig sind. Dies wird meist nicht unterstützt. Hinzu kommen Inkompatibilitäten zwischen dem ISO und NFC-Standard. 3.6 eid-integrationsmöglichkeiten Ein wichtiges Kriterium bei der Auswahl eines eid-services ist die darunter liegende eid- Service-Schnittstelle zum Dienstanbieter. Die technische Richtlinie BSITR beschreibt diese Schnittstelle und ermöglicht zwei Arten der Implementierung. SAML-Schnittstelle: Die Kommunikation zwischen AusweisApp und eid-server wird über den Browser des Nutzers abgewickelt. Request und Response werden dabei als verschlüsselter SAML-Token durch den Browser geschickt. Um SAML einfach zu verarbeiten, bieten die eid-server-hersteller Bibliotheken für die SAML-Verarbeitung an. Teilweise werden diese Komfortbibliotheken nur in der Programmiersprache Java angeboten. Die Anbindung weiterer Programmiersprachen kann schwierig sein, da dann die SAML Kommunikation unter Umständen selbst ausprogrammiert werden muss. WebService-Schnittstelle: Neben der SAML-Schnittstelle besteht die Möglichkeit die Kommunikation via WebServie-Schnittstelle abzubilden. Diese Schnitstelle ist in der TR-3130 definiert und hat den Vorteil, dass sie sehr unabhängig bezüglich der zu verwendenden Programmiersprache ist. Die eid-hersteller unterstützen nach unserem Kenntnisstand folgende Schnittstellen: Server SAML-Schnittstelle WebService-Schnittstelle AGETO Ja Ja Bos Ja Ja OpenLimit Ja In Entwicklung. Soll in Kürze bereitstehen. Media transfer AG Ja Ja /30

18 Folgende Integrationsmöglichkeiten bestehen für Diensteanbieter: 1. Komfort-Bibliothek Die eid-server-hersteller bieten i.d.r. mit ihren eid-lösungen Komfort-Bibliotheken an, die primär in JAVA implementiert sind, so dass die Anbindung über ein Java Servlet erfolgen kann. Die Kommunikation dieser Komfort-Bibliotheken mit dem eid-server erfolgt per SAML oder WebService-Schnittstelle. 2. Direkte SAML-Anbindung Die Spezifikation zur SAML-Anbindung befindet sich in der technischen Richtlinie eid- Server (BSI TR-03130) 11. Die Verwendung dieser Schnittstelle schätzen wir als relativ aufwendig ein. 3. Nutzung der WebService-Schnittstelle Die Spezifikation zur WebService-Anbindung befindet sich ebenfalls in der technischen Richtlinie eid-server (BSI TR-03130). 4. eid-gateway Mit Hilfe eines eid-gateways lassen sich verschiedene Webplattformen an den eid- Service anbinden. In diesem Zusammenhang ist nur das Gateway der Fa. AGETO bekannt. Das AGETO eid-gateway bietet eine Universal-Schnittstelle zwischen der Online- Anwendung des Diensteanbieters (z. B. einem Onlineshop) und einem frei wählbaren eid-server. Die Schnittstelle berücksichtigt dabei die geforderten Sicherheitsaspekte, ist mandantenfähig und technologieunabhängig. Dabei lässt sich das Gateway in gängigen Umgebungen auf Basis von Java,.NET, Ruby, PHP, Javascript oder Perl integrieren. 11 Vgl. TR-03130_TR-eID-Server_V1_6_pdf.pdf? blob=publicationfile 17/30

19 4 Auswahlverfahren 4.1 Auswahlkriterien Bezugnehmend auf die gesetzten Rahmenbedingungen sind bei der Einschränkung der möglichen eid-server bzw. eid-services folgende Punkte zu berücksichtigen: Multi-Mandantenfähigkeit Die Basiskomponente zur Bereitstellung der eid-funktionalität sollte von verschiedenen Mandanten genutzt werden können. Dabei gilt es zu berücksichtigen, dass ggf. mehrere Berechtigungs-Zertifikate zum Einsatz kommen. Demnach ist seitens des Diensteanbieters die Fachanwendung sowie der eid-webservice bzw. das eid-gateway multi-mandantenfähig zu konzipieren. Hierbei müssen mehrere Kommunen parallel unter Nutzung eines oder mehrerer Berechtigungszertifikate verarbeitet werden können Multi-Dienste-Fähigkeit Ein Mandant kann zudem mehrere Dienste anbieten, die ggf. durch unterschiedliche Webanwendungen bereitgestellt werden. Dabei sollte es möglich sein verschiedene Fachverfahren, die unterschiedliche eid-daten auslesen müssen, verwenden zu können. Auch an dieser Stelle gilt es, ggf. mehrere Berechtigungszertifikate zu unterstützen Plattform-Unabhängigkeit der Dienste Die Anbindung bzw. der Zugriffsweg auf den eid-webservice bzw. das eid-gateway sollte möglichst Plattformunabhängig konzipiert werden, so dass eine Anbindung in den unterschiedlichsten Programmiersprachen und aus den verschiedensten Systemen-Plattformen heraus möglich ist. Die Integration muss mit einer.net-webanwendung ebenso möglich sein wie mit einer JAVA- oder PHP-Anwendung. Im Idealfall sollte auch ein Rich-Client die eid-funktion nutzen können Zentrales eid-know-how Durch Kapselung der eid-funktionen in einem zentralen eid-webservice bzw. -Gateway wird auch die Entwicklung und Konfiguration dieser Schnittstelle zentral durchgeführt. Demnach muss die Kompetenz in Bezug auf die eid und deren Nutzung ebenfalls nur einmal und nicht dezentral in allen Teams der eid-konsumierenden Fachanwendungen vorhanden sein. Die Teams der Fachanwendungen können hierdurch den eid-service sowohl technisch zentral nutzen als auch sich der zentralen eid-kompetenz bedienen. Die einzelnen Teams benötigen dabei das Wissen um die eid nicht in der gesamten Tiefe. 18/30

20 4.1.5 Option eines späteren Eigenbetriebs eines eid-servers Zu Beginn der Einführung einer eid-funktion für Webanwendungen ist es offensichtlich unwirtschaftlich von Beginn an einen eigenen eid-server zu betreiben. Die Option sollte jedoch nicht verbaut und zu einem späteren Zeitpunkt neu bewertet werden. 4.2 Auswahl der Variante zur Anbindung eines eid-services Auf Grundlage der oben genannten Rahmenbedingungen erfolgt im Folgenden die Auswahl der zu nutzenden Variante zur Anbindung eines eid-services: 1. Komfort-Bibliothek Diese Variante scheidet insbesondere aufgrund der Plattformabhängigkeit sowie der fehlenden Multi-Mandanten- bzw. Multi-Dienste-Fähigkeit aus. 2. Direkte SAML-Anbindung Die Verwendung dieser Schnittstelle ist im Vergleich zur WebService-Schnittstelle sehr aufwendig. Ebenfalls ist davon auszugehen, dass nicht für jede Programmierplattform entsprechende SAML-Bibliotheken existieren. Demnach scheidet auch diese Variante aus. 3. Nutzung der WebService-Schnittstelle Die Nutzung der WebService-Schnittstelle passt sehr gut in eine SOA-Infrastruktur und erfüllt grundsätzlich die gesteckten Anforderungen. Die Schnittstelle lässt sich durch einen selbstentwickelten multi-mandanten- und multi-dienste-fähigen zentralen eid-dienst kapseln. Somit wird diese Variante in der weiteren Betrachtung mit einbezogen. Hersteller: Alle Hersteller bieten aktuell oder in kürze diese Schnittstelle an. Anbieter: Die Auswahl eines Anbieters erfolgt im Rahmen einer Kosten-/Nutzen-Analyse. 4. eid-gateway: Das eid-gateway erfüllt prinzipiell ebenfalls die gesteckten Anforderungen und wird ebenfalls in die weitere Betrachtung genommen. Hersteller: AGETO Innovation GmbH Betreiber: AGETO Innovation GmbH 4.3 Auswahl eines eid-service-anbieters Die Auswahl des eid-service-vertragspartners erfolgt in einem Auswahlprozess außerhalb dieses Dokuments auf Basis der oben genannten Rand- und Rahmenbedingungen sowie nach monetären Auswahlkriterien. 19/30

21 5 Technische Anbindung an bestehende IT-Infrastruktur Ziel der ekom21-lösung ist es, einen zentralen eid-dienst für Fachverfahren zur Verfügung zu stellen. Binden Fachverfahren diesen Dienst ein, soll kein tiefgreifendes eid-spezifisches Wissen notwendig sein. Dies impliziert die Entwicklung einer eigenen ekom21-komponente zur Identifikation mit dem npa, die den eigentlichen eid-service von der Fachanwendung kapselt und zusätzlich automatisch notwendige Berechtigungszertifikate, im Sinne einer Mandantenfähigkeit, anspricht. Prinzipiell sind für die praktische Umsetzung einer solchen zentralen Komponente zwei Lösungen denkbar. Zum einen die Anschaffung des eid-gateways der Fa. Ageto oder die Eigenentwicklung eines ekom21-eid-dienstes unter Nutzung der WebService-Spezifikation der TR Diese beiden Varianten werden im Folgenden beschrieben. 5.1 Anbindung der Fachverfahren mit AGETO eid-gateway Mit Hilfe des eid-gateway der Fa. Ageto lassen sich Applikation verschiedenster Programmiersprachen an einen eid-server anbinden. Der Diensteanbieter stellt dabei alle Anfragen an das eid-gateway. Das eid-gateway kommuniziert als Schnittstelle zwischen Diensteanbieter-Applikation und eid-server. Dabei kann das AGETO eid-gateway an eid-server verschiedener Hersteller angebunden werden. Die Anfragen der Diensteanbieter-Applikation werden per http-request an das eid-gateway gesendet. Diese startet die Ausweis-App und baut die Verbindung zum eid-server auf und liefert die ausgelesenen Ausweisdaten per http- Response über eine per SSL-verschlüsselte Verbindung zurück. Abbildung 6: Das AGETO eid-gateway Entnommen aus: 20/30

22 5.2 Anbindung der Fachverfahren mit eigenentwickeltem eid-dienst Im Rahmen des Prototyps wird ein eigener zentraler eid-dienst für die Anbindung eines Fachverfahrens bereitgestellt. Hintergrund ist dabei insbesondere die Möglichkeit einer individuellen Implementierung von Business-Logik und Sicherheitsmechanismen. Dieses wird im Folgenden, inklusive eines Entwurfs der für die Fachverfahren zur Verfügung gestellten WebService-Schnittstelle, beschrieben Architektur des ekom21 eid-dienstes Der zentrale ekom21 eid-dienst soll wie folgt entwickelt werden. Fachapplikationen können über eine SOAP-Schnittstelle auf den eid-dienst zugreifen. Die WebService-Schnittstelle des eid-dienstes ist ein Kapitel SOAP-Schnittstelle des ekom21 eid-dienstes definiert und kapselt den Zugriff auf die in der TR-3130 definierte SOAP-Schnittstelle. Der Zugriff auf die SOAP Schnittstelle wird über ein TLS Verbindung abgesichert. Durch die Definition einer WebService-Schnittstelle ist der ekom21 eid-dienst plattformabhängig, sofern darauf zugreifende Dienste per SOAP-WebServices kommunizieren können. Eine Einbindung in Fat-Clients oder mobile Anwendung ist durch Berücksichtigung der in TR definierten alternativen Client-Aktivierung ebenfalls möglich. Zusätzlich enthält der eid-dienst einige Komfortfunktionen: Die Fachdienste benötigen wenige Kenntnisse von der Funktion des neuen Personalausweises. Zum Beispiel ist das Schlüsselmaterial zur Kommunikation mit dem eid-server bereits vorkonfiguriert. Der eid-dienst ist mandantenfähig und verwendet automatisch das entsprechende Berechtigungszertifikat für den entsprechenden Anwendungsfall. Der eid-dienst liest die Felder aus dem npa aus für die der jeweilige Anwendungsfall berechtigt ist und gibt genau diese zurück. Wird die Pseudonymisierung verwendet, z.b. um einen wiederkehrenden Benutzer zu erkennen, speichert das Gateway automatisch das Pseudonym in der dazugehörigen Datenbank ab. Abbildung 7: eid-architektur ekom21 21/30

23 5.2.2 Kommunikationsablauf ekom21 eid-dienst Der Kommunikationsablauf im ekom21 eid-dienst ist wie folgt vorgesehen und in Einzelschritten in der folgenden Abbildung beschrieben. Abbildung 8: Kommunikationsablauf des ekom21 eid-dienstes Die Kommunikation läuft in folgenden Schritten ab: 1. Aufruf der Identifizierung in der Fachanwendung: Die Fachanwendung spricht die WebService-Operation geteidsession an. Über eine Parametrisierung kann festgelegt werden, welcher im Gateway konfigurierte Mandant in Test- oder Wirkumgebung verwendet werden soll. Es wird außerdem eine Rücksprung URL festgelegt die nach Identifizierung vom eid-service aufgerufen wird. 2. Erzeugung der eid-session: Der ekom21 eid-dienst spricht den eid-server gemäß der in TR-3130 definierten WebService-Spezifikation auf und generiert eine eid- Session. 3. Der eid-service übergibt an das ekom21 eid-gateway die in TR-3130 beschriebene tctokenurl zum Aufruf der AusweisApp. 4. Der eid-dienst generiert das zum Aufruf der AusweisApp notwendige HTML- Formular und gibt dieses gemeinsam mit der SessionID an die Fachanwendung zurück. 5. Die Fachanwendung initiiert mit Hilfe des vorgefertigten HTML Formulars einen http- Forward an die tctokenurl und ruft damit die AusweisApp auf. 6. Der Nutzer identifiziert sich mit der AusweisApp oder dem alternativem eid-client. 22/30

24 7. Weiterleitung an die definierte Rücksprungadresse. Diese wird in Schritt 1 durch den Fachdienst bereitgestellt. Ein Aufruf dieser Rücksprungadresse signalisiert dem Fachdienst, dass die Identifizierung abgeschlossen ist. 8. Der Fachdienst ruft einen WebService des ekom21 eid-dienstes auf, um die Ergebnisse des Auslesevorgangs aus dem npa abzufragen. 9. Aufruf der WebService-Funktion useid nach TR-3130 zur Abfrage des Ergebnisses der Identifikation vom eid-server. 10. Rückgabe der Ergebnisse der Identifikation lt. SOAP Schnittstelle der TR Rückgabe der Ergebnisse der Identifikation durch SOAP Schnittstelle des ekom21 eid-gateway an den Fachdienst. Die Ergebnisse der Identifikation können im Fachdienst verwendet werden SOAP-Schnittstelle des ekom21 eid-dienstes Funktionen der SOAP Schnittstelle Die SOAP-Schnittstelle des ekom21 eid-dienstes hat die im Folgenden beschriebenen Funktionen. Diese sind technisch in der angehängten WSDL Datei (Kapitel 6.1 WSDL- Definition des ekom21 eid-dienstes) beschrieben. Abbildung 9: Funktionen des ekom21 eid-dienstes geteidsession Die Funktion geteidsession baut eine Session im eid-server gemäß der in TR-3130 definierten WebService-Spezifikation auf. Dazu wird die TR-3130 Funktion useid aufgerufen. Das Ergebnis wird direkt als HTML-Formular aufbereitet, so dass die aufrufende Fachseite fertiger HTML-Code zum Aufruf der AusweisApp zur Verfügung steht. 23/30

25 Request Abbildung 10: getiedsession Request Parameter Umgebung Verfahren Mandant idproviderurl Beschreibung Mögliche Werte sind Test und Produktion. Anhand dieser Einstellung entscheidet das ekom21 eid-gateway über die Verwendung eines Testberechtigungszertifikats, bzw. dazugehöriger PKI. Identifiziert das zu nutzende Fachverfahren ID des Mandanten der das ekom21 eid-gateway verwendet. Anhand der Mandanten-ID entscheidet das eid-gateway über die Verwendung des entsprechenden Berechtigungs-Zertifikats. Rücksprungadresse an die nach erfolgter Identifizierung mit dem npa zurückgeleitet werden soll. Wird diese URL in der Fachanwendung aufgerufen, kann der Response der Identifizierung abgerufen werden. Tabelle 1: Parameter EIDSessionRequest Response Abbildung 11: geteidsession Response 24/30

26 Rückgabewert SessionId tctoken tctokenform Beschreibung Kennzeichnet die ID der Session im eid-server. Die Fachanwendung benötigt diese ID zum Aufruf des Ergebnisses der Identifikation. TC-Token gem. Richtlinie TR-3130 HTML-Formular zur Einbindung in der Fachanwendung und Aufruf der AusweisApp. Das Formular kann verfahrensspezifisch aufgebaut sein geteidresult Tabelle 2: Rückgabewerte der Funktion geteidsession Request Abbildung 12: geteidresult Request Parameter eidsessionid Umgebung Verfahren Mandant Beschreibung Kennzeichnet die ID der Session im eid-server. Die Fachanwendung benötigt diese ID zum Aufruf des Ergebnis der Identifikation. Mögliche Werte sind Test und Produktion. Anhand dieser Einstellung entscheidet das ekom21 eid-gateway über die Verwendung eines Testberechtigungszertifikats, bzw. dazugehöriger PKI. Identifiziert das zu nutzende Fachverfahren ID des Mandanten der das ekom21 eid-gateway verwendet. Anhand der Mandanten-ID entscheidet das eid-gateway über die Verwendung des entsprechenden Berechtigungs-Zertifikats. Tabelle 3: Parameter des geteidresult Request 25/30

27 Response Abbildung 13: EIDResultResponse Rückgabewert ResultReturn Beschreibung Eigener Datentyp EIDServiceResult enthält die aus dem Ausweis ausgelesenen Attribute oder eine Fehlermeldung. Der selbstdefinierte Datentyp ist in Kapitel beschrieben. Tabelle 4: Rückgabewerte des EIDResultResponse Eigendefinierte Datentypen EIDServiceResult Der Datentyp EIDServiceResult enthält die Ergebnisse des Auslesevorgangs mit dem neuen Personalausweis. Die enthaltenen Felder müssen nicht gefüllt sein. Abbildung 14: Datentyp EIDServiceResult 26/30

28 Rückgabewert Error Nachname Vorname DateOfExpiry Kuenstlername akademischertitel Geburtsdatum Geburtsort Nationalitaet Geburtsname PlaceOfResidence ResidencePermit RestrictedID Beschreibung Text der im Fachdienst anzuzeigenden Fehlermeldung falls Identifizierung mit dem npa nicht erfolgreich war. Ausgelesener Nachname Ausgelesener Vorname Ablaufdatum des Ausweises im Format DD.MM.YYYY Ausgelesener Künstlername Ausgelesener akademischer Titel Geburtsdatum im Format DD.MM.YYYY Ausgelesener Geburtsort Ausgelesene Nationalität Ausgelesener Geburtsname PlaceOfResidence gemäß TR-3130 ResidencePermit gemäß TR-3130 RestrictedID des npa. Diese kann zur eindeutigen Wiedererkennung verwendet werden. Beispielsweise zur Zuordnung eines Nutzerkontos. Tabelle 5: Rückgabewerte im Datentyp EIDServiceResult 27/30

29 6 Anhang 6.1 WSDL-Definition des ekom21 eid-dienstes <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace=" xmlns:apachesoap=" xmlns:impl=" xmlns:intf=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:xsd=" <wsdl:types> <schema elementformdefault="qualified" targetnamespace=" xmlns=" <element name="eidresult"> <complextype> <sequence> <element name="eidsessionid" type="xsd:string"/> <element name="umgebung" type="xsd:string"/> <element name="verfahren" type="xsd:string"/> <element name="mandant" type="xsd:string"></element> </sequence> </complextype> </element> <element name="eidresultresponse"> <complextype> <sequence> <element name="resultreturn" type="impl:eidserviceresult"/> </sequence> </complextype> </element> <complextype name="eidserviceresult"> <sequence> <element name="error" nillable="true" type="xsd:string"/> <element name="nachname" nillable="true" type="xsd:string"/> <element name="vorname" nillable="true" type="xsd:string"/> <element name="dateofexpiry" nillable="true" type="xsd:date"/> <element name="kuenstlername" nillable="true" type="xsd:string"/> <element name="akademischertitel" nillable="true" type="xsd:string"/> <element name="geburtsdatum" nillable="true" type="xsd:date"/> <element name="geburtsort" nillable="true" type="xsd:string"/> <element name="nationalität" nillable="true" type="xsd:string"/> <element name="geburtsname" nillable="true" type="xsd:string"/> <element name="placeofresidence" nillable="true" type="xsd:string"/> <element name="residencepermit" nillable="true" type="xsd:string"/> <element name="restrictedid" nillable="true" type="xsd:string"/> </sequence> </complextype> <element name="eidsessionrequest"> <complextype> <sequence> <element name="umgebung" type="xsd:string" /> 28/30

30 <element name="verfahren" type="xsd:string" /> <element name="mandant" type="xsd:string"></element> <element name="idproviderurl" type="xsd:string"/> </sequence> </complextype> </element> <element name="eidsessionresponse"> <complextype> <sequence> <element name="sessionid" type="xsd:string"/> <element name="tctoken" type="xsd:string"/> <element name="tctokenform" type="xsd:string"/> </sequence> </complextype> </element> </schema> </wsdl:types> <wsdl:message name="geteidsessionresponsemessage"> <wsdl:part element="impl:eidsessionresponse" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:message name="geteidsessionrequestmessage"> <wsdl:part element="impl:eidsessionrequest" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:message name="geteidresultresponsemessage"> <wsdl:part element="impl:eidresultresponse" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:message name="geteidresultrequestmessage"> <wsdl:part element="impl:eidresult" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:porttype name="ekom21npawebservice"> <wsdl:operation name="geteidresult"> <wsdl:input message="impl:geteidresultrequestmessage" name="geteidresultrequestmessage"> </wsdl:input> <wsdl:output message="impl:geteidresultresponsemessage" name="geteidresultresponsemessage"> </wsdl:output> </wsdl:operation> <wsdl:operation name="geteidsession"> <wsdl:input message="impl:geteidsessionrequestmessage" name="geteidsessionrequestmessage"> </wsdl:input> <wsdl:output message="impl:geteidsessionresponsemessage" name="geteidsessionresponsemessage"> </wsdl:output> </wsdl:operation> 29/30

31 </wsdl:porttype> <wsdl:binding name="ekom21npawebservicesoapbinding" type="impl:ekom21npawebservice"> <wsdlsoap:binding style="document" transport=" <wsdl:operation name="geteidresult"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="geteidresultrequestmessage"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="geteidresultresponsemessage"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="geteidsession"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="geteidsessionrequestmessage"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="geteidsessionresponsemessage"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="ekom21npawebservice"> <wsdl:port binding="impl:ekom21npawebservicesoapbinding" name="ekom21npawebservice"> <wsdlsoap:address location=" </wsdl:port> </wsdl:service> </wsdl:definitions> 30/30

32 Herausgeber Bundesministerium des Innern IT-Stab, Referat IT4 Alt-Moabit 101 D, Berlin Bezugsquelle Bundesministerium des Innern Internet: und Tel.: +49 (0) Fax: +49 (0) Veröffentlicht September 2013 HINWEIS Das Bundesministerium des Innern ist nicht verantwortlich für den Inhalt der Ergebnisdokumente, die im Rahmen der E-Government-Initiative für D und den neuen Personalausweis erstellt wurden. Bitte wenden Sie sich bei inhaltlichen Fragen direkt an die hier genannten Ansprechpartner. Verantwortlich für den Inhalt dieses Ergebnisdokumentes ekom21 Kommunales Gebietsrechenzentrum Hessen Herr Armin Merle Knorrstraße 30, Kassel Tel.: +49 (0) Internet: Diese Veröffentlichung ist Teil der Öffentlichkeitsarbeit der Bundesregierung. Sie wird kostenlos abgegeben und ist nicht zum Verkauf bestimmt.