Architektur

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. Die Definitionen einzelner Komponenten werden nachfolgend beschrieben.

Abbildung 1: Gesamtarchitektur

Die Gesamtarchitektur des E-ID-Systems setzt sich aus mehreren Domains zusammen. Jede Domain enthält eine oder mehrere Komponenten des E-ID-Systems. Der Begriff Domain bezeichnet hier einen Teil des E-ID-Systems, dessen Komponenten von einer Organisation (BRZ, BMI, etc.) betrieben werden und der eine bestimmte Funktionalität des E-ID-Systems kapselt. Eine Sonderstellung nimmt hier die User-Domain ein. Damit wird der Bereich des Endnutzers des E-ID-Systems bezeichnet. Dieser Bereich umfasst den Endnutzer selbst sowie die von ihm verwendeten Endnutzergeräte.

Vor einer Verwendung des E-ID-System muss der Benutzer seinen persönlichen E-ID aktivieren. Dies erfolgt über definierte organisatorische Prozesse und technische Komponenten, die in der Registration-Domain angesiedelt sind. Dementsprechend existiert eine Schnittstelle zwischen der User-Domain und der Registration-Domain. Die Registration Domain verfügt über weitere Schnittstellen zur E-ID-Backend-Domain und zur VDA-Domain, da im Zuge der Registrierung eine Interaktion mit Komponenten dieser Domains notwendig ist.

Nach erfolgter Registrierung kann der Benutzer seine E-ID zur Anmeldung an unterschiedlichen Service-Providern verwenden. Service-Provider sind in der Service-Provider-Domain angesiedelt. Der Service-Provider nutzt das E-ID-System zur Authentifizierung des Benutzers. Dementsprechend verfügt die Service-Provider-Domain über eine Schnittstelle zur E-ID-Fontend-Domain. Kernaufgabe der E-ID-Frontend-Domain ist die Authentifizierung des Benutzers. Die Authentifizierung erfolgt im Falle einers registrierten E-ID über den Vertrauensdienstanbieter (VDA), der in der VDA-Domain angesiedelt ist. Dementsprechend verfügt die E-ID-Frontend-Domain über eine Schnittstelle zur VDA-Domain. Für ausländische BenutzerEU-Staatsbürger kann eine Authentifizierung über das eIDAS-Framework erfolgen. Komponenten des eIDAS-Frameworks sind der eIDAS-Domain zugeordnet, welche ebenfalls über eine Schnittstelle zur E-ID-Frontend-Domain verfügten. Sowohl VDA-Domain als auch eIDAS-Domain haben eine Schnittstelle zur User-Domain, über die der Benutzer authentifiziert wird. Auch die E-ID-Frontend-Domain selbst verfügt über eine Schnittstelle zur User-Domain, da auch hier eine Interaktion mit dem Benutzer im Zuge der Benutzerauthentifizierung notwendig ist.

E-ID Frontend Domain

Die E-ID-Frontend-Domain ist primär für die Authentifizierung des Benutzers verantwortlich. Über sie werden benötigte Attribute dementsprechend über eine Schnittstelle zur E-ID-Backend-Domain abgefragt.

Abbildung 2: E-ID Frontend Domain

Shibboleth IdP

Der Shibboleth IdP nimmt Authentifizierungs-Requests von Service-Providern entgegen und fungiert als zentraler Identity Provider des E-ID-Systems. Seine Aufgabe ist die Authentifizierung des Benutzers und die Aggregation aller notwendigen Identitätsattribute. Beide Aufgaben delegiert der Shibboleth IdP an andere Komponenten des E-ID-Systems. Nach vollständiger Benutzer-Authentifizierung und der Aggregation aller benötigten Attribute erstellt der Shibboleth IdP eine Authentifizierungs-Response, welche die Identität des Benutzers bestätigt. Diese Response wird an den anfragenden Service-Provider retourniert.

Auth-Handler Plugin

Das Auth-Handler-Plugin implementiert die Schnittstelle zwischen dem Shibboleth IdP und dem Auth-Handler. Das Auth-Handler-Plugin führt den Benutzer durch den Anmeldevorgang (Authentication Flow) und übermittelt die vom Auth-Handler übergebenen Informationen an die Authentifizierungs-Schnittstelle des Shibboleth IdP.

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 einen Plugin-Mechanismus an den Auth.-Handler weitergegeben. Der Auth.-Handler unterstützt die folgenden beiden Authentifizierungsverfahren für Benutzer:

  1. VDA
  2. EU-Login über eIDAS-Framework

Bei einer Authentifizierung über VDA erfolgt eine Benutzerauthentifizierung auf Basis einer qualifizierten Signatur. Der Auth.-Handler übernimmt hierbei die Kommunikation mit dem VDA. Zusätzlich implementiert der Auth.-Handler eine Anbindung an das Online-Vollmachten-System (OVS), über welches der Benutzer entsprechende Vollmachten für vertretungsweises Einschreiten auswählen kann.
Die Identifikation und Authentifizierung via mittels eIDAS erfolgt über denie zentralen nationalen eIDAS-NodeKnoten, welcher die Schnittstelle in das europäische eIDAS-Netzwerk darstellt. Nach erfolgreicher Identifikation und Authentifizierung im jeweiligen Heimatland des Benutzers werden die Identifikationsattribute, d.h. das MDS sowie weitere optionale Attribute, über denie nationalen eIDAS-NodeKnoten an den Auth.-Handler retourniert.
Der Auth.-Handler besitzt einen eigenen Cache, in dem temporäre Daten zwischengespeichert werden. Wird der Auth.-Handler in einem Cluster betrieben, teilen sich alle Auth.-Handler-Instanzen des Clusters einen gemeinsamen Cache. Dadurch werden effektive Methoden des Load-Balancing ermöglicht.

Binding-Service

Das Binding-Service gibt dem Benutzer die Möglichkeit, sein mobiles Gerät (konkret: seine Digitales-Amt-App) kryptographisch an den Shibboleth IdP zu binden. Die im Zuge des Bindungsprozesses erstellte kryptographische Bindung ermöglicht dem Benutzer eine spätere vereinfachte Authentifizierung am Shibboleth IdP. Konkret muss diese Authentifizierung nicht mehr über VDA oder eIDAS erfolgen. Die damit verbundenen Schritte zur Benutzerauthentifizierung entfallen dadurch, was eine erhöhte Benutzerfreundlichkeit zur Folge hat.

User Store

Relevante Informationen zur erstellten kryptographischen Bindung werden vom Binding-Service über ein Service im User-Store hinterlegt. Der Shibboleth IdP hat im Zuge des Anmeldeprozesses ebenfalls Zugriff auf diesen User-Store und kann die dort hinterlegten Informationen verwenden und so den Benutzer vereinfacht authentifizieren.

PKI

Diese Komponente wird vom Binding-Service im Zuge der Erstellung der kryptographischen Bindung, die für die vereinfachte Weiterverwendung des E-ID genutzt wird, angesprochen und verwendet. Die kryptographische Bindung beruht auf einem Zertifikat, das über die PKI ausgestellt wird.

Backend-Proxy

Der Backend-Proxy stellt die zentrale Schnittstelle zu Komponenten dar, welche in der E-ID-Backend-Domain betrieben werden. Aus Sicht des Shibboleth IdP wird der Backend-Proxy über einen Plugin-Mechanismus integriert, um notwendige Attribute zu aggregieren.

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.

E-ID Backend Domain

Die E-ID Backend Domain stellt die erforderlichen, unterstützten Attributwerte teilweise selbst, oder nach Anforderung von der Attribute-Provider-Domain, für eine E-ID Anmeldung bereit. Dazu verfügt die E-ID-Backend-Domain über eine Schnittstelle zur Attribute-Provider-Domain.

Abbildung 3: E-ID Backend Domain

Attribute Handler

Der Attribute-Handler ist die zentrale Komponente der E-ID-Backend-Domain. Seine Aufgabe ist die Aggregierung notwendiger Benutzer-Attribute und deren Übermittlung an den Backend-Proxy und in weiterer Folge an den Shibboleth IdP in der E-ID-Frontend-Domain. Der Attribute-Handler bedient sich dazu mehrerer Attributquellen. So hat der Attribute-Handler Zugriff auf das Attribute-Register, welches Basisinformationen zu den in der Attribute-Provider-Domain angebotenen Registern beinhaltet. Des Weiteren hat der Attribute-Handler Zugriff auf das Stammzahlenregister und dieses kann unter Zuhilfenahme der verschlüsselten Stammzahl des Benutzers bereichsspezifische Personenkennzeichen, sowohl in unverschlüsselter als auch in verschlüsselter Form, für eine Anwendung berechnen.

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

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 Vollmachten-Profile, etc.) 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 Shibboleth IdP in der E-ID-Frontend-Domain notwendigen Informationen werden durch das Application-Register in das Metadatena-Repository in der E-ID-Frontend-Domain gepusht.

Attribute Register

Das Attribute-Register speichert welches Attribut über welchen Attribute-Provider in der Attribute-Provider-Domain abrufbar ist und welcher Bereich für die Berechnung von bereichsspezifischen Kennzeichen jedem Attribute Provider zugeordnet ist.

Registration Domain

Die Registration-Domain enthält jene Entitäten, die für die Durchführung der Registrierung des E-ID eines Benutzers notwendig sind. Entsprechend den definierten Registrierungsprozessen sind sowohl technische Komponenten als auch Personen (Registration Officer) Entitäten dieser Domain.

Als nicht-technische Komponente fungiert in der Registration-Domain der Registration Officer. Dabei handelt es sich um einen Behördenmitarbeiter, der den Registrierungsprozess behördenseitig durchführt. Unterstützt wird der Registration Officer dabei von technischen Komponenten, die ebenfalls in der Registration-Domain angesiedelt sind. Diese werden in den folgenden Unterabschnitten beschrieben.

Abbildung 4: Registration-Domain

Identitätsdokumentenregister (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 Vertrauensdiensteanbieter 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.

Vorregistrierungssystem

Das Vorregistrierungssystem bietet dem Benutzer die Möglichkeit, den Registrierungsprozess zumindest teilweise zu Hause durchzuführen. Über das Vorregistrierungssystem erfasste Daten werden dann durch den Registration Officer im Zuge des Registrierungsprozesses in der Behörde ergänzt.

Attribute-Provider-Domain

Die Attribute-Provider-Domain implementiert notwendige Funktionalität zur Bereitstellung von Attributen im Zuge von Anmeldeprozessen an Applikationen. Notwendige Funktionalität wird durch diverse technische Komponenten umgesetzt. Dabei handelt es sich im Wesentlichen um Register, die in der betrieblichen Verantwortung des BMI oder unter Kontrolle einer anderen Organisation sind.

Abbildung 5: Attribute Provider Komponenten

VDA-Domain

Die VDA-Domain beinhaltet den Vertrauensdienstanbieter (VDA). Der VDA stellt die Infrastruktur für die Authentifizierung von Benutzern mittels qualifizierter elektronischer Signaturen bereit. Aktuell wird die Rolle des VDA von der Firma A-Trust wahrgenommen. Die Erstellung der qualifizierten Signatur durch den Benutzer stellt sowohl die Authentifizierung des Benutzers als auch die Einverständniserklärung zur Freigabe der Attribute durch den Benutzer dar.

Neben dem VDA selbst wird in der VDA-Domain auch das Self-Service betrieben, über das der Benutzer sein VDA-Konto verwalten kann.

Abbildung 6: Vertrauensdiensteanbieter Domain

eIDAS-Domain

Alternativ zur VDA-Domain kann die Authentifizierung des Benutzers im Zuge eines Anmeldeprozesses an einer Applikation auch über die eIDAS-Domain erfolgen. Der österreichische eIDAS-Knoten bildet die Schnittstelle in das europäische eIDAS-Netzwerk, das für die Identifikation und Authentifizierung von ausländischen Personen verwendet werden kann.

Abbildung 7: eIDAS Domain

User-Domain

Die User-Domain beschreibt die Umgebung des Benutzers, von der aus dieser das E-ID-System verwendet. Dementsprechend umfasst die User-Domain den Benutzer selbst sowie auch seine Endnutzergeräte.

Prinzipiell erlaubt die Flexibilität des E-ID-Systems die Verwendung unterschiedlicher Endnutzergeräte durch den Benutzer . So kann eine Authentifizierung gegen das E-ID-System im Zuge der Anmeldung an einem Service-Provider beispielsweise neben Benutzername/Passwort über einen zweiten SMS-basierten Authentifizierungsfaktor umgesetzt werden. Notwendige Endnutzergerte wären hier ein Gerät mit Web-Browser und ein zweites Gerät mit der Möglichkeit es Empfangs von SMS-Nachrichten.

Abbildung 8: User-Domain

Primär verfolgt das E-ID-System jedoch das Ziel der Unterstützung von rein mobilen Anwendungsszenarien. Dementsprechend ist eine Anmeldung an Service-Providern unter Verwendung eines mobilen Endnutzergeräts (z.B. Smartphone) als einziges Endnutzergerät möglich. Zentrales Element dabei ist die sogenannte Digitales-Amt-App, über die der Benutzer mit dem E-ID-System interagieren kann.

Da die Verwendung der Digitales-Amt-App das primäre Ziel ist (SMS-basierte und andere Varianten dienen nur als Fall-back), wird auch hier der Fokus bewusst auf diese Variante gelegt. Prinzipiell können jedoch auch andere Apps oder Web-Browser in Prozesse des E-ID-Systems involviert sein.

Service-Provider-Domain

Die Service-Provider-Domain ist dementsprechend relativ einfach gehalten und enthält im Wesentlichen die bereitgestellte Applikation. Die Service-Provider-Domain ist dementsprechend relativ einfach gehalten und enthält im Wesentlichen die bereitgestellte Applikation.
Diese ist vor allem im Zuge der Akkreditierung der Applikation im E-ID-System über eine entsprechende Komponente der E-ID-Backend-Domain relevant, greift in nachfolgende Anmeldeprozesse jedoch nicht direkt ein.
Zu beachten ist, dass es in der Praxis beliebig viele Service-Provider und damit auch beliebig viele Service-Provider-Domains geben kann, auch wenn deren Aufbau und deren Anbindung an das E-ID-System konzeptionell stets gleich ist.

Abbildung 9: Service-Provider-Domain