Wie funktioniert digitale Identität – Teil 5: Identitätsübermittlung / Delegation / Rechtsrahmen

Damit ein Identity Provider oder ein Identity Broker die digitale Identität oder Authentifizierung eines Nutzers an einen Webservice liefern kann, werden standardisierte Schnittstellen und Protokolle benötigt. Sollen diese Aktionen auch noch rechtssicher sein, müssen die entsprechenden Gesetze beachtet werden. Diese Themen sind Gegenstand des folgenden Artikels.

von Rudolf Linsenbarth

SAML

Die Security Assertion Markup Language (SAML) ist ein XML-Framework zum Austausch von Authentifizierungs- und Autorisierungsinformationen.

Autor Rudolf Linsenbarth

Rudolf Linsenbarth beschäftigt sich mit Mobile Payment, NFC, Kundenbindung und digitaler Identität. Er ist seit über 15 Jahren in den Bereichen Banken, Consulting, IT und Handel tätig. Linsenbarth ist profilierter Blogger der Finanzszene und kommentiert bei Twitter unter @holimuk die aktuellen Entwicklungen. Alle Beiträge schreibt Rudolf Linsenbarth im eigenen Namen.

SAML assertions werden vom Identity Provider zum Service Provider übertragen. Assertions sind statements (Aussagen), die ein Service Provider nutzt, um über das Zulassen eines Zugriffs zu entscheiden. Drei Typen von statements werden von SAML genutzt:

1. Authentication statements (z.B. Zusicherung einer Authentifizierung für ein Single Sign-On SSO)

2. Attribute statements (z.B. Zusicherung, dass ein Subjekt über bestimmte Attribute verfügt – Altersverifizierung)

3. Authorization decision statements (z.B. Autorisierung bestimmter Ressourcen – Zugriff auf eine Datei)

SAML ist ein sicheres und mächtiges Protokoll. In Unternehmen ist es de-facto-Standard für web-basierte Authentifizierung und Single-Sign-On. Kritik gibt es auf Grund der Komplexität des unterliegenden Standards für XML-Signaturen. Im offenen Internetbetrieb ist es auf Grund der Verwendung von X.509-Zertifikaten schwer beherrschbar.
Leichtgewichtigere Protokolle werden daher bevorzugt.

OpenID

OpenID ist eine offene Spezifikation für Webseiten und Authentifizierungsdienste zum standardisierten Austausch von Anmeldedaten und Sicherheitsinformationen. Im Jahr 2007 wurde die OpenID Foundation als Non-Profit-Organisation gegründet. Ihre Aufgabe ist die Verwaltung von Urheber- und Markenrechten sowie das Marketing. Die unter Open-Source-Lizenzen gestellte Software kann auch auf einem eigenen Server installiert werden.

Eine OpenID hat die Form einer URL entweder als Subdomain des OpenID-Anbieters (username.oepenidprovider.com) oder als URL-Pfad (oepenidprovider.com/username). Bei der Anmeldung mit OpenID wird der Nutzer mittels dieses Pfades auf die Webseite seines OpenID-Anbieters geleitet. Dieses Vorgehen wird als Delegation bezeichnet.

Eine Alternative zur expliziten Nutzung einer OpenID ist Account Chooser. Er soll vor allem die Bedienung erleichtern. Der Chooser funktioniert ausschließlich über E-Mail-Adressen. Der Nutzer gibt hierbei seine E-Mail-Adresse in das Anmeldefeld ein. Wenn der E-Mail-Provider OpenID unterstützt, wird sofort der Authentifizierungsprozess gestartet, wie man ihn von OpenID oder Facebook Connect gewohnt ist.

Digitale Identität:
Dossier in sieben Schritten

I Teil1: Die Anforderungen

II Teil 2: PKI (Public/Private Key Infrastruktur)

III Teil 3: Authentifizierung mit FIDO (Fast IDentity Online)

IV Teil 4: Wer liefert die rechtssichere Identität?

V Teil 5: Identitätsübermittlung / Delegation / Rechtsrahmen

VI Teil 6: Was kann die Blockchain zur Lösung beitragen?

VII Teil 7: Die Lösungsanbieter im Identity-Bereich

Die Information, die ein OpenID-Anbieter einem Website-Betreiber liefert, kann basieren auf der sogenannten OpenID Simple Registration. Es handelt sich um neun grundlegende Informationen eines OpenID-Benutzer, wenn er diese zuvor beim OpenID-Anbieter hinterlegt hat und der Weiterleitung zustimmt:
1. nickname (Spitzname)
2. email (E-Mail-Adresse)
3. fullname (bürgerlicher Name)
4. dob (date of birth Geburtsdatum)
5. gender (Geschlecht)
6. postcode (Postleitzahl)
7. country (Land)
8. language (Sprache)
9. timezone (Zeitzone)

Einige OpenID-Anbieter und OpenID-fähige Website-Betreiber haben zusätzlich auch das neuere OpenID-Attribute-Exchange-Protokoll zum erweiterten Datenaustausch implementiert. Dann werden die Daten übertragen, die jeweils beide Parteien unterstützen. Auch hier gilt, dass der Benutzer die volle Kontrolle über Daten und deren Weitergabe hat.

Eine der ersten große kommerziellen Anwendungen war „LogIn with PayPal“. Hier wird eine sehr einfache und schnelle Anbindung der OpenID in Kombination mit einer Zahlmethode angeboten.

OpenID ist gegenüber Phishing-Attacken anfällig. Der Betreiber einer Website erstellt einfach eine Weiterleitung auf eine Seite, die der Seite des OpenID Providers ähnelt, jedoch als Proxy dient und Benutzername und Passwort abfängt. Der Nutzer muss daher die OpenID Login-Seite immer auf Echtheit prüfen. Ein weiterer Kritikpunkt an OpenID ist die fehlende API-Unterstützung. Mittlerweile wird OpenID deshalb zunehmend von OAuth mit OpenID Connect verdrängt.

OAuth

OAuth ist ein Standard, der es nativen mobilen Anwendungen ermöglicht, auf Ressourcen im Namen des Benutzers zuzugreifen. OAuth 2.0 ist ein API-freundliches Protokoll, statt SOAP und XML wie bei SAML, werden hier REST und JSON wirksam eingesetzt. OAuth ist in vielen Software as a Service (SaaS) Anwendungen wie Facebook, Google, Yahoo sowie in Cloud-Infrastrukturen wie Azure Active Directory integriert. Der Kern des OAuth 2.0-Standards wurde von der Internet Engineering Task Force IETF genehmigt und fertiggestellt.

OAuth ist aber eben nur ein Autorisierungsprotokoll, für das Login stellt der OAuth-Autorisierungsserver dem Client keine Benutzer-ID oder andere Benutzerdaten zu Verfügung.

OpenID Connect

OAuth 2.0 hat sich also als Standard für die Autorisierung von API-Zugriffen im Web etabliert. Wer es auch zum Login einsetzen wollte, war auf anbieterspezifische Lösungen angewiesen. Für standardisiertes portalübergreifendes Single Sign-On (SSO) hatte man ansonsten die Wahl zwischen OpenID und SAML. Die Nachteile dieser Protokolle sind oben bereits beschrieben worden, dass beide nicht auf die Erfordernisse moderner Apps ausgelegt sind, überrascht nicht, schließlich entstanden sie vor deren Erfindung (2007 bzw. 2005).

OpenID Connect erweitert jetzt OAuth 2.0 um diese notwendigen Funktionen. Der Standard wurde im Februar 2014 von der OpenID Foundation verabschiedet und ist bereits von Anbietern wie Google, Microsoft und der Deutschen Telekom implementiert worden.

OpenID Connect ermöglicht Clients aller Art, einschließlich web-basierten, mobilen und JavaScript-Clients, Informationen über authentifizierte Sitzungen und Nutzer zu erhalten. Die Spezifikation ist erweiterbar um optionale Funktionen wie Verschlüsselung von Identitätsdaten, Finden von OpenID-Providern und Session-Management.

OpenID Connect optimiert also den OAuth-Authentifizierungsablauf und erweitert somit OAuth 2.0 um alle notwendigen Funktionen für Login und Single Sign-On.

eIDAS

Die EU Verordnung über elektronische Identifizierung und Vertrauensdienste oder besser bekannt als eIDAS (electronic IDentification, Authentication and trust Services) ist kein Protokoll oder Framework, sondern liefert den Rechtsrahmen für Dienstleistungen in diesem Bereich.

Aus diesem umfangreichen Rechtswerk sollen hier die 3 folgenden Punkte näher betrachtet werden:

1. ELEKTRONISCHE IDENTIFIZIERUNG – Gegenseitige Anerkennung und Notifizierung
Die gegenseitige Anerkennung von elektronischen Identitätsnachweisen der jeweiligen europäischen Länder ist ein wichtiger Teil der Verordnung. Im Rahmen einer sogenannten Notifizierung beschreibt ein Land die dort anerkannten elektronischen Identifizierungssysteme einschließlich deren Sicherheitsniveaus und des Ausstellers. Die Folge ist, dass alle anderen EU Länder diese elektronischen Identitäten im öffentlichen Bereich ebenfalls anerkennen müssen.

Die Privat-Wirtschaft kann solche Identitäten anerkennen, muss dies aber nicht machen. Der Vorteil der Notifizierung ist, dass die Haftung für die Sicherheit dieser Identität auf den notifizierenden Staat übergeht. Es ist übrigens auch möglich, dass ein Land eine privatwirtschaftliche elektronische Identität notifiziert.

Die Bundesrepublik Deutschland hat die Notifizierung des elektronischen Identitätsnachweises mit dem deutschen Personalausweis und dem elektronischen Aufenthaltstitel mittlerweile erfolgreich abgeschlossen. Wer mehr zum Thema Notifizierung wissen will, wird auf der folgenden Seite des Bundesamtes für Sicherheit in der Informationstechnik BSI fündig.
https://www.bsi.bund.de/eIDAS-Notifizierung

2. EU-Vertrauenssiegel für qualifizierte Vertrauensdiensteanbieter
Anbieter qualifizierter Dienste, die die Konformität mit den besonderen Anforderungen an solche Dienste nach eIDAS-Verordnung nachweisen und dafür den Qualifikationsstatus verliehen bekommen, können ihre Dienste mit dem neuen EU-Vertrauenssiegel für qualifizierte Vertrauensdiensteanbieter bewerben.

Die Bundesnetzagentur BNetzA ist Aufsichtsstelle für elektronische Signaturen, Siegel, Zeitstempel und elektronische Zustelldienste. Das BSI ist Aufsichtsstelle für die Ausgabe von Zertifikaten für Webseitenauthentisierung (TLS-Zertifikate). Das EU-Vertrauenssiegel darf von qualifizierten Vertrauensdiensten verwendet werden, die von der jeweiligen Aufsichtsstelle als qualifiziert anerkannt wurden.
Anbieter, die sich und ihre Dienste als qualifiziert bezeichnen dürfen, werden unter Angabe des jeweiligen Dienstes auf den Internetseiten der Bundesnetzagentur veröffentlicht.

Bestätigte Identifizierungsverfahren

Anbieterliste für das Ausstellen qualifizierter Zertifikate für elektronische Signaturen

3. Elektronische Signaturen
Die Verwendung elektronischer Signaturen war bisher durch die Signaturrichtlinie geregelt, die in Deutschland seit 2001 mit Signaturgesetz und Signaturverordnung umgesetzt wurde. Mit Einführung der eIDAS-Verordnung wurde die Signaturrichtlinie aufgehoben und das Signaturgesetz wurde durch das Vertrauensdienstegesetz abgelöst. Die Signaturverordnung trat damit ebenfalls außer Kraft.

Wenn nun z.B. ein Dienstleister eine qualifizierte Fernsignatur für Verträge mit Schriftformerfordernis anbieten will, benötigt er eine Zulassung der Bundesnetzagentur. Das Verfahren dazu wird in dem folgenden Dokument hier beschrieben.

Zusammenfassung

Für die Übermittlung von digitalen Identitäten und die delegierte Autorisierung (Login mit „you name it“), ist die Kombination von OAuth und OpenID Connect das Verfahren der Wahl. Wer also seinen Kunden ein einfacheres „Onboarding“ ermöglichen will, ist gut beraten, auf diese Standards zu setzen.
Das gilt natürlich auch für die Identitätsprovider. Wenn sie dazu noch hochwertige Identitätsprüfungen im Geldwäschebereich und Fernsignaturen für Verträge mit Schriftformerfordernis anbieten wollen, empfiehlt sich ein vertieftes Studium der eIDAS-Verordnung.

Was derzeit noch fehlt, ist ein durchgehender Standard für die Login-Auswahl. Account Chooser weist hier die Richtung, ist aber noch nicht ausreichend skalierbar. Hier bietet sich die Kombination dieses Verfahrens mit der Blockchain an. Wie das genau aussehen könnte und welche andere Lösungen die Blockchain in Zukunft für das Thema digitale Identität bereitstellen kann, wird im nächsten Artikel beleuchtet.Rudolf Linsenbarth

Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/69172