Der neue elektronische Identitätsnachweis E-ID wird die alte Bürgerkarte ersetzen und stellt ein System mit mehr Einsatzmöglichkeiten dar. Der neue E-ID basiert auf der nachfolgend dargestellten Architektur, die sich aus einer Vielzahl verschiedener Komponenten zusammensetzt. Das Zusammenspiel der Komponenten, sowie eine kurze Definition wird nachfolgend beschrieben.

Abbildung 1: Gesamtarchitektur

Die Gesamtarchitektur besteht aus vier Ebenen. Benutzer authentifizieren sich in der Applikationsebene gegenüber einem bestimmten Service Provider. Dieser Identifikations- und Authentifizierungsprozess erfolgt über den zentralen Identity Provider und dem Vertrauensdiensteanbieter (VDA) in der Authentifizierungsebene. Ebenso erfolgt hier im Vertretungsfall die Auswahl einer adäquaten Vollmacht über das Online-Vollmachten Service (OVS). Die Authentifizierungsebene wird auch als „E-ID Frontend“ bezeichnet. Die Personenbindung wird im E-ID Backend, in der Datenaggregierungsebene erstellt und über das E-ID Frontend an den Service Provider ausgeliefert. Werden über das Minimum Data Set (MDS) hinaus, d.h. bPK(s), Name und Geburtsdatum, weitere Attribute benötigt, so werden diese vom E-ID Backend von den jeweiligen Registern (Datenebene) bezogen und in die Personenbindung aufgenommen.

Identity Provider Komponenten

Der Identity Provider im E-ID besteht aus mehreren Komponenten, welche unterschiedliche Aufgaben im gesamten Authentifizierungsprozess umsetzen. Die Komponenten werden folgend einzeln beschrieben.

Abbildung 2: Identity Provider Komponenten

Shibboleth IDP

Das Identity Protokoll, welches die Schnittstelle zwischen Applikation und Identity Provider darstellt, wird über die Shibboleth Identity Provider Software umgesetzt. Die Shibboleth Identity Provider Software ist eine als OpenSource vom Shibboleth Consortium zur Verfügung gestellte Implementierung eines Identity Providers. Aktuell unterstützt der Shibboleth IDP SAML2 als Authentifizierungsprotokoll. Eine Unterstützung für OpenID Connect ist ab 4. Quartal 2019 vorgesehen. Der Shibboleth IDP verfügt über einen Pluginmechanismus, über welchen Identifikations- und Authentifizierungsvorgänge des Benutzers und die Abfrage von zusätzlichen Attributen für den Benutzer integriert werden können. Für die Validierung von Authentifizierungsrequests, welche über ein unterstütztes Authentifzierungsprotokoll an den IDP gesendet werden, hat der Shibboleth IDP Zugriff auf eine Datenbank, in welcher z.B. SAML2-Metadaten für die Kommunikation via SAML2, gespeichert sind.

Auth. Plugin

Das Auth.-Plugin ist die Schnittstelle des Shibboleth IDP zum Auth. Handler. Dieses Plugin kommt immer dann zum Einsatz wenn eine Identifikation und Authentifizierung des Benutzers und optional die Auswahl von elektronischen Vollmachten benötigt wird. Diese Komponente stellt eine eigens entwickelte Erweiterung für den Shibboleth IDP dar.

Auth. Handler

Der Auth.-Handler implementiert die technische Identifikation und Authentifizierung von Benutzern und bietet dem Benutzer die optionale Möglichkeit zur Verwendung von elektronischen Vollmachten. Hierfür wird der Authentifizierungsprozess vom Shibboleth IDP über das Auth. Plugin an den Auth. Handler weitergegeben. Der Auth. Handler unterstützt die folgenden beiden Authentifizierungsverfahren für Benutzer:

  • E-ID (Handy-Signatur)

  • EU Login mittels eIDAS

Für die Identifikation mittels E-ID erfolgt eine Authentifizierung auf Basis einer qualifizierten Signatur. Der Auth.-Handler übernimmt hierbei die Kommunikation mit dem Vertrauensdiensteanbieter (VDA). Die qualifizierte Signatur (QSIG) im Authentifizierungsvorgang dient zudem als Einverständniserklärung (User Consent) des Benutzers zur Übermittlung sämtlicher Attribute des Benutzers an die Applikation. Zusätzlich implementiert der Auth.-Handler eine Anbindung an das OVS, über welches der Benutzer entsprechende Vollmachten für vertretungsweises Einschreiten auswählen kann.

Die Identifikation und Authentifizierung via eIDAS erfolgt über den zentralen nationalen eIDAS Knoten, welcher die Schnittstelle in das europäische eIDAS Netzwerk darstellt. Nach erfolgreicher Identifikation und Authentifizierung im jeweiligen Heimatland des Bürgers werden die Identifikationsattribute, d.h. MDS sowie weitere optionale Attribute, über den nationalen eIDAS Knoten an den Auth.-Handler returniert.

Der Auth.-Handler kann Konfigurationsparameter und Policies einer Anwendung aus dem Application Register des E-ID Backends abfragen. Diese Abfrage erfolgt aus Perfomancegründen über eine zentrale Proxy Komponente im E-ID Frontend.

Proxy

Der Proxy stellt die zentrale Schnittstelle zu Komponenten, welche im E-ID Backend betrieben werden, dar. Hierbei handelt es sich im Speziellen um den Attribute Handler und das Application Register, welche im Data Aggregation Layer als Backend Komponenten betrieben werden. Zur Verbesserung der Performance bei einer hohen Durchsatzrate dient der Proxy auch als Bridge zwischen unterschiedlichen Kommunikationsprotokollen um die Kommunikation zwischen E-ID Frontend und Backend zu optimieren. Als Beispiel nimmt er Anfragen vom Identity Provider über HTTP/1.1 an und wandelt diese in performantere HTTP/2 Kommunikation unter Verwendung des Protocol Buffers Datenformat um.

Metadata Repository

Das Metadata Repository enthält alle Informationen welche der IDP zur Validierung und Verarbeitung von Authentifizierungsanfragen von Service Providern gemäß dem verwenden Authentifizierungsprotokoll benötigt. Im Falle einer SAML2 Authentifizierung beinhaltet das Metadata Repository die SAML2 Metadaten der Applikation, welche den SAML2 Authentifizierungsprozess gestartet hat. Das Application Register pusht hierfür die benötigten Informationen in das Metadata Repository.

Online Personenbindungs-Service

Das Online-Personenbindungs-Service des E-ID Backends stellt die erforderlichen Attributwerte für eine E-ID Anmeldung bereit. Dazu erhält das Service Identifikations- und Authentifizierungsparameter vom Identity Provider. Die Komponenten werden folgend im Detail beschrieben.

Abbildung 3: Online Personenbindungs-Service

Attribute Handler

Der Attribute Handler ist die Kernkomponente des Personenbindungs-Services im „Data Aggregation“ Layer und stellt Identifikationsattribute für den Identity Provider im Frontend bereit. Hierfür kann der Identity Provider nach erfolgreicher Identifikation und Authentifizierung des Benutzers weitere Identifikationsattribute am Attribute Handler anfordern. Diese Anforderung enthält zusätzlich zu den benötigten Identifikationsattributen auch alle Parameter (User Consent, MDS, Vertretungen, verschlüsselte Stammzahl, Applikationsidentifier, …), welche es dem Attribute Handler ermöglichen zu prüfen, ob der Benutzer seine Zustimmung zur Weitergabe der Identifikationsattribute erteilt hat und ob die Applikation berechtigt ist, die angeforderten Identifikationsattribute zu beziehen. Basierend auf dieser Validierung liefert der Attribute Handler die erlaubten Identifikationsattribute an den Identity Provider aus.

Die Bereitstellung von weiteren Attributen erfolgt unter Zuhilfenahme von Services im E-ID Backend bzw. der dahinterliegenden Register. So hat der Attribute Handler Zugriff auf das Attribute Register, welches Basisinformationen zu den im „Data“ Layer angebotenen Registern beinhaltet. Des Weiteren hat der Attribute Handler Zugriff auf das Stammzahlenregister und kann unter Zuhilfenahme der verschlüsselten Stammzahl bereichsspezifische Personenkennzeichen, sowohl in unverschlüsselter als auch in verschlüsselter Form, für eine Anwendung berechnen. Zur Historisierung und Protokollierung meldet der Attribute Handler die Freigabe durch den Benutzer an das Consent Protokoll.

Attribute Policy

Die Attribute Policy stellt das Berechtigungssystem für den Zugriff auf die Attribute durch die Anwendungen dar. Die wichtigste Funktion der Attribute Policy ist, dass festlegt wird, welche Anwendungen auf welche Attribute Zugriff haben.

Application Register

Im Application Register werden Anwendungen, die zur Abfrage von E-ID Daten berechtigt sind, registriert. Im Zuge der Registrierung werden alle für den E-ID Prozess benötigten Informationen (z.B. Identifier der Anwendung, Zertifikate, erlaubte Authentifizierungsverfahren, erlaubte Vollmachtenprofile, …) im Register gespeichert. Welche Attribute von welcher Anwendung angefragt werden dürfen, wird ebenfalls vom Application Register in Kombination mit der Attribute Policy definiert. Alle für den Identity Provider und das Authentifizierungsprotokoll notwendigen Informationen werden durch das Application Register in das Metadata Repository gepusht.

Attribute Register

Das Attribute Register ist Teil des Online Personenbindungs-Service und speichert welches Attribut über welchen Attribute Provider abrufbar ist und welcher Bereich für die Berechnung von bereichsspezifischen Kennzeichen jedem Attribute Provider zugeordnet ist.

Consent Protocol

Diese Komponente stellt eine Datenbank zur Protokollierung und Einsicht der Einverständniserklärungen der Benutzer (User Consent) für die Weiterleitung von Attributen an Anwendungen dar.

Attribute Provider

Die Attribute Provider sind ein Überbegriff für unterschiedliche Register, welche die erforderlichen Attributwerte an den Attribute Handler zurück liefern . In Abbildung 4 sind folgende Register beispielhaft dargestellt.

  • Register BMI: Register, die vom Bundesministerium für Inneres betrieben werden.

  • Andere Register: Weitere Register die von verschiedenen Entitäten der öff. Verwaltung betrieben werden.

Abbildung 4: Attribute Provider Komponenten

Sonstige Komponenten

Zur Umsetzung der E-ID werden folgende weitere Komponenten benötigt.

Abbildung 5: Sonstige Komponenten

Stammzahlenregister

Das Stammzahlenregister wird von der Stammzahlenregisterbehörde betrieben und kann unter Zuhilfenahme der verschlüsselten Stammzahl bereichsspezifische Personenkennzeichen, sowohl in unverschlüsselter als auch in verschlüsselter Form, für eine Anwendung bereitstellen. Hierfür stellt das Stammzahlenregisters eine Schnittstelle zum Attribute Handler des Online Personenbindungs-Services bereit.

IDR

Das Identitätsdokumentenregister beinhaltet Daten zur Person, welche zur sicheren Identifikation (z.B. Reisepässe, Personalausweise, E-ID) benötigt werden. Bei der Aktivierung des E-ID wird das IDR vom VDA zur Abfrage von Personendaten im Zuge der Registrierung des E-ID benötigt. Ebenso verwendet das SZR das IDR zur Prüfung ob ein E-ID aktiviert und gültig ist.

Vertrauensdiensteanbieter

Der Vertrauensdiensteanbieter (VDA) stellt die Infrastruktur für die Authentifizierung von Benutzern mittels qualifizierten elektronischen Signaturen (QSIG) bereit. Im Falle der oben angeführten E-ID Architektur, ist das der VDA A-Trust. Die Erstellung der QSIG durch den Benutzer stellt zugleich die Authentifizierung des Benutzers als auch die Einverständniserklärung zur Freigabe der Attribute durch den Benutzer dar.

MIS

Das MIS (Mandate Issuing Service) ist Teil des Online Vollmachten Services und wird zur Abfrage von elektronischen Vollmachten durch den Identity Provider und zur Auswahl der Vollmacht durch den Benutzer benötigt.

eIDAS Node

Der eIDAS Knoten bildet die Schnittstelle in das europäische eIDAS Netzwerk und wird für die Identifikation und Authentifizierung von ausländischen Personen verwendet.

Application AP

Diese Komponente repräsentiert die Online Anwendung des Service Providers, die eine Identifikation und Authentifizierung mittels E-ID für eine Autorisierung an der Online-Anwendung benötigt.

Client

Der Client stellt das Gerät (Smartphone/Tablet/PC/Laptop) dar, mit dem der Benutzer auf eine Online Anwendung oder Service zugreifen möchte.

User

Der Bürger bzw. die Bürgerin, die eine Online Anwendung oder eine elektronisches Service  nutzt.