Dokumentation Identitäts-Protokolle für MOA-ID - E

Transcription

Dokumentation
Identitäts-Protokolle für
MOA-ID
Version 1.0, 26.09.2013
Bernd Zwattendorfer – bernd.zwattendorfer@egiz.gv.at
Zusammenfassung: Identitätsprotokolle dienen im Allgemeinen dem sicheren
Austausch von Identitäts- und Authentifizierungsdaten von Bürgerinnen bzw.
Bürgern zwischen Identity Provider und Service Provider, konkret zwischen MOAID und Online Applikation. Derzeit ist SAML 1.0 das verwendete Protokoll, in
Zukunft soll auf SAML 2.0 bzw. PVP 2.x gesetzt werden. Nachdem aber neben
SAML eine Reihe anderer Identitätsprotokolle existiert, wurde im Rahmen dieses
Projekts nebem SAML eine Analyse weiterer Identitätsprotokolle durchgeführt
(OAUth, OpenID Connect, OpenID, CAS, WS-Federation). Diese Protokolle
wurden anhand unterschiedlicher Kriterien miteinander verglichen und auf
deren Eignung für eine Verwendung in MOA-ID überprüft.
E-Government
Innovationszentrum
Inffeldgasse 16/a, A-8010 Graz
Tel.
+43 316 873 5514
Fax.
+43 316 873 5520
E-Mail post@egiz.gv.at
www.egiz.gv.at
Das E-Government Innovationszentrum ist eine gemeinsame
Einrichtung des Bundeskanzleramtes und der TU-Graz
Inhaltsverzeichnis
1 Einleitung .......................................................................................................................................6
1.1 Identitätsprotokoll für MOA-ID ............................................................................................6
1.2 Terminologie...........................................................................................................................8
1.3 Vergleichskriterien .................................................................................................................9
1.3.1 Funktionale Kriterien ..................................................................................................9
1.3.2 Organisatorische Kriterien ......................................................................................10
1.3.3 Technische Kriterien ................................................................................................11
2 SAML 1.0 ......................................................................................................................................12
2.1 Allgemeines..........................................................................................................................12
2.2 Authentifizierungsablauf ....................................................................................................12
2.3 Beispiel ..................................................................................................................................14
2.3.1 Authentifizierungsrequest (Schritt 2) .....................................................................14
2.3.3 Authentifizierungsresponse (Schritt 9) ..................................................................15
2.4 Diskussion ..............................................................................................................................16
2.4.1 Funktionale Kriterien ................................................................................................16
2.5 Fazit ........................................................................................................................................18
3 SAML 2.0 (PVP 2.x) ......................................................................................................................19
3.1 Allgemeines..........................................................................................................................19
3.3 Beispiel ..................................................................................................................................22
3.4 Diskussion ..............................................................................................................................25
3.5 Fazit ........................................................................................................................................27
Einleitung
2
4 OAuth 2.0 ....................................................................................................................................29
4.1 Allgemeines..........................................................................................................................29
4.3 Beispiel ..................................................................................................................................31
4.3.1 Authorization Request (Schritt 2)...........................................................................31
4.3.2 Authorization Response (Schritt 7) ........................................................................32
4.3.3 Access Token Request (Schritt 8) ..........................................................................32
4.3.4 Access Token Response (Schritt 9) .......................................................................32
4.3.5 UserInfo Request (Schritt 10) ..................................................................................32
4.3.6 UserInfo Response (Schritt 11) ...............................................................................32
4.4 Diskussion ..............................................................................................................................33
4.5 Fazit ........................................................................................................................................35
5 OpenID Connect .......................................................................................................................37
5.1 Allgemeines..........................................................................................................................37
5.3 Beispiel ..................................................................................................................................39
5.3.1 Authorization Request (Schritt 2)...........................................................................39
5.3.2 Authorization Response (Schritt 7) ........................................................................40
5.3.3 Access Token Request (Schritt 8) ..........................................................................40
5.3.4 Access Token Response (Schritt 9) .......................................................................40
5.3.5 UserInfo Request (Schritt 10) ..................................................................................41
5.3.6 UserInfo Response (Schritt 11) ...............................................................................41
5.4 Diskussion ..............................................................................................................................41
5.5 Fazit ........................................................................................................................................43
6 OpenID ........................................................................................................................................45
Einleitung
3
6.2 Beispiel ..................................................................................................................................47
6.2.1 OpenID Authentication Request (Schritt 6) ........................................................47
6.2.2 OpenID Authentication Response (Schritt 7)......................................................48
6.3 Diskussion ..............................................................................................................................49
6.4 Fazit ........................................................................................................................................52
7 CAS ...............................................................................................................................................53
7.2 Beispiel ..................................................................................................................................55
7.2.1 CAS Authentication Request (Schritt 2) ...............................................................55
7.2.2 Redirect with ticket (Schritt 6 und 7) ....................................................................55
7.2.4 Authentifizierungsresponse (Schritt 10) ................................................................56
7.3 Diskussion ..............................................................................................................................56
7.4 Fazit ........................................................................................................................................58
8 WS-Federation ............................................................................................................................60
8.2 Beispiel ..................................................................................................................................62
8.3 Diskussion ..............................................................................................................................63
8.4 Fazit ........................................................................................................................................65
Einleitung
4
9 Weitere Protkolle ........................................................................................................................66
9.1 STORK ....................................................................................................................................66
9.2 Mozilla Persona ....................................................................................................................66
10 Vergleich ...................................................................................................................................67
10.1 Bewertungsschemata ......................................................................................................67
10.1.1 Bewertungsschema Funktionale Kriterien .........................................................67
10.1.2
Bewertungsschema
Organisatorische
Kriterien ...............................................................................................................................68
10.1.3 Bewertungsschema Technische Kriterien .........................................................68
10.2 Vergleich anhand der Kriterien ......................................................................................69
10.2.1 Vergleich anhand funktionaler Kriterien ...........................................................69
10.2.2
Vergleich
anhand
organisatorischer
Kriterien ...............................................................................................................................70
10.2.3 Vergleich anhand technischer Kriterien ...........................................................71
11 Zusammenfassung ...................................................................................................................73
Abbildungsverzeichnis
Abbildung 1 - Bürgerkarten-Authentifizierung mittels MOA-ID ................................................6
Abbildung 2 - Prozessfluss einer SAML 1-Anmeldung mittels Browser/Artifact Profile .......13
Abbildung 3 - SAML Architektur [SAML2_Overview] ...............................................................19
Abbildung 4 - Prozessfluss einer SAML 2.0-Anmeldung gemäß PVP 2.x ..............................21
Abbildung 5 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von
OAuth 2.0........................................................................................................................................30
Abbildung 6 - OpenID Connect Protocol Suite .......................................................................37
OpenID Connect 1.0 ....................................................................................................................38
OpenID 2.0 .....................................................................................................................................46
Abbildung 9 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von CAS
1.0 ....................................................................................................................................................54
Abbildung 10 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von WSFederation ......................................................................................................................................61
Einleitung
5
1 Einleitung
Im Rahmen dieses Projekts werden unterschiedliche Identitätsprotokolle auf ihre
Tauglichkeit und ihre Praktikabilität für einen Einsatz in MOA-ID untersucht und anhand
unterschiedlicher Kriterien miteinander verglichen. In diesem einleitenden Kapitel wird
zuerst
kurz
allgemein
beschrieben,
welche
Funktionalität
ein
gewünschtes
Identitätsprotokoll für MOA-ID generell abbilden soll. Anschließend wird eine
Terminologie-Übersicht
gegeben,
da
in
den
einzelnen
Spezifikationen
der
Identitätsprotokolle unterschiedliche Begriffe für (fast) identische Komponenten
verwendet werden. Abschließend werden die Kriterien gelistet, mit denen die
individuellen Identitätsprotokolle miteinander verglichen werden.
1.1 Identitätsprotokoll für MOA-ID
Abbildung 1 zeigt im Überblick das allgemeine Anmeldeszenario unter Verwendung
der Bürgerkarte und MOA-ID. Die Bürgerin bzw. der Bürger kommuniziert sowohl mit der
Online Applikation als auch mit MOA-ID mittels Web Browser über das HTTP-Protokoll.
Um auf die Funktionalitäten der Bürgerkarten zuzugreifen, verwendet MOA-ID die
Security Layer-Schnittstelle [SL] und dessen Protokoll zur Kommunikation. Hat sich eine
Bürgerin bzw. ein Bürger bei MOA-ID mittels Bürgerkarte eindeutig und sicher
authentifiziert, werden die Anmeldedaten entsprechend über ein Identitätsprotokoll an
die Online Applikation weitergereicht. Die dabei übermittelten Anmeldedaten
enthalten neben persönlichen Daten der Bürgerin bzw. des Bürgers auch (technische)
Informationen zum durchgeführten Authentifizierungsprozess.
Abbildung 1 - Bürgerkarten-Authentifizierung mittels MOA-ID
Einleitung
6
Es existiert bereits eine Reihe von standardisierten Protokollen, die sich mit der sicheren
Übertragung von Identitäts- und Authentifizierungsdaten befassen. MOA-ID setzt derzeit
auf die Security Assertion Markup Language (SAML)1 in Version 1.0 für die Übermittlung
von Identitäts- und Authentifizierungsdaten an die Online Applikation. Im Rahmen
dieses
Projekts
werden
weitere
unterschiedliche
Protokolle
mit
diesem
Verwendungszweck analysiert und miteinander verglichen. Im Wesentlichen sollten die
analysierten Protokolle die folgenden funktionalen Eigenschaften erfüllen:

Transfer von Identitäts- und Authentifizierungsdaten

Sicherheit

Einfache Erweiterbarkeit
Im Rahmen einer ersten Analyse wurde eine Auswahl möglicher Identitätsprotokolle
getroffen, die diese funktionalen Eigenschaften erfüllen und somit für einen Einsatz für
den Datentransfer zwischen MOA-ID und der Online Applikation geeignet wären. Dies
wären im Wesentlichen die folgenden spezifizierten Protokolle:

SAML 1.0

SAML 2.0 bzw. PVP 2.x

OAuth 2.0

OpenID Connect

OpenID 2.0

CAS

WS-Federation
SAML 1.0 wird in die Analyse miteinbezogen, da es derzeit von MOA-ID verwendet wird.
Bei allen anderen Protokollen werden keine älteren Versionen berücksichtigt.
SAML 2.0 bzw. PVP (Portalverbundprotokoll) 2.x, welches auf SAML 2.0 aufsetzt, ist von
besonderer Wichtigkeit, da dieses Protokoll in Zukunft eine wichtige Rolle im
behördlichen Bereich in Österreich spielen wird und das nationale Protokoll für den
Austausch von Identitäts- und Authentifizierungsdaten im E-Government sein wird.
OAuth 2.0 ist eigentlich ein Protokoll zur Autorisierung. Es wird im Rahmen dieses
Dokuments jedoch trotzdem analysiert, da es einerseits bereits von vielen Applikationen
breit eingesetzt wird und weil andererseits das OpenID Connect Protokoll darauf
aufbaut.
Obwohl OAuth 2.0 ursprünglich als Autorisierungsprotokoll entwickelt wurde, kann es
auch für Authentifizierungen eingesetzt werden. OpenID Connect erweitert OAuth 2.0
speziell um Funktionalitäten zur Authentifizierung.
1
http://saml.xml.org
Einleitung
7
OpenID 2.0 stellt im Wesentlichen ein dezentrales Authentifizierungssystem dar. Das
dazugehörige Protokoll verwendet das Konzept der URL-basierten Identität. OpenID 2.0
wird ebenfalls bereits von zahlreichen Applikationen zur Authentifizierung eingesetzt.
CAS ist ein sehr schlichtes, auf HTTP basierendes Protokoll, welches zumeist im
universitären Kontext zur Authentifzierung und für Single Sign-On eingesetzt wird.
WS-Federation ist ein Teil des WS-Trust Frameworks und ebenfalls speziell auf den
Austausch
von
Identitäts-
und
Authentifizierungsdaten
zur
Identitätsföderation
ausgerichtet.
1.2 Terminologie
Obwohl all die zuvor erwähnten Protokolle auf eine sichere Authentifizierung von
Benutzerinnen und Benutzern abzielen und somit den gleichen Anwendungsfall
abdecken, verwenden die meisten Protokolle unterschiedliche Begrifflichkeiten.
Innerhalb dieses Unterabschnitts wird nun versucht, ein gemeinsames Verständnis
dieser
Begrifflichkeiten
zu
erreichen,
um
einen
einfacheren
Vergleich
der
Identitätsprotokolle zu ermöglichen. Im Folgenden werden die in Abbildung 1
dargestellten, bei einer Authentifizierung beteiligten Parteien kurz beschrieben. Tabelle
1listet anschließend die entsprechend äquivalenten Begrifflichkeiten der einzelnen
Identitätsprotokolle.
Online Applikation: Bei der Online Applikation handelt es sich um eine web-basierte EGovernment Applikation oder um eine Applikation des privatwirtschaftlichen Bereichs,
welche durch eine Bürgerkartenauthentifizierung mittels MOA-ID geschützt ist.
Bürgerin bzw. Bürger: Eine natürliche Person, die sich via MOA-ID und Bürgerkarte an
einer Online Applikation authentifizieren möchte. Der Web Browser sowie die
Bürgerkartenumgebung können als Teil der Bürgerin bzw. des Bürgers betrachtet
werden.
MOA-ID: MOA-ID ist eine server-seitige Middleware, welche die Identifizierung und
Authentifizierung der Bürgerin bzw. des Bürgers mittels Bürgerkarte durchführt und der
Applikation die Identitäts- und Authentifizierungsdaten über ein entsprechendes
Identitätsprotokoll strukturiert zur Verfügung stellt.
Einleitung
8
Tabelle 1- Terminologie der unterschiedlichen Identitätsprotokolle
Komponente
SAML
1.0
PVP 2.X
Service
Provider
OpenID
CAS
WS-Federation
OpenID
Connect
SAML
2.0
Online
Applikation
OAuth 2.0
Service
Provider
Client
Relying
Party
Web
Service
Resource
Provider
(Relying Party)
Bürgerin bzw. Subject
Bürger
Principal
Resource
Owner
End User
User
Requestor
(User)
MOA-ID
Identity
Provider
Authorizati OpenID
on Server Provider
UND
Central
Authenti
cation
Server
Security Token
Service
(Identity
Provider)
Identity
Provider
Resource
Server
Im Gegensatz zu den anderen Identitätsprotokollen, zielt OAuth auf Autorisierung und
nicht rein auf Authentifizierung ab. Außerdem wird in OAuth eine Unterscheidung
zwischen der Entität, die die Entscheidung für eine Autorisierung durchführt
(Authorization Server), und jener Entität, welche die Ressource bzw. Identitätsdaten
speichert (Resource Server), getroffen. Im Gegensatz dazu übernimmt beispielsweise in
SAML der Identity Provider beide Funktionalitäten, sodass im Rahmen von OAuth MOAID als gemeinsamer Authorization Server und Resource Server betrachtet werden kann.
1.3 Vergleichskriterien
Die in den weiteren Kapiteln vorgestellten Identitätsprotokolle sollen auf deren Eignung
für einen Einsatz zwischen MOA-ID und Online Applikation hin untersucht werden. Um
diese Protokolle auch entsprechend vergleichen zu können, werden definierte Kriterien
herangezogen. Die einzelnen Kriterien werden nun kurz beschrieben.
1.3.1 Funktionale Kriterien
Dieser Abschnitt beschreibt die Kriterien für den Vergleich funktionaler Eigenschaften.
Transfer von Identitäts- und Authentifizierungsdaten: Das Protokoll soll einen einfachen
und strukturierten Transfer von Identitäts- und Authentifizierungsdaten zwischen MOA-ID
und der Online Applikation ermöglichen.
Sicherheit: Der Transfer von Identitäts- und Authentifizierungsdaten zwischen MOA-ID
und der Online Applikation muss sicher erfolgen und vor Angreifern geschützt sein.
Einleitung
9
Einfache Erweiterbarkeit: Das spezifizierte Protokoll soll die Möglichkeit einer einfachen
Erweiterbarkeit
bieten,
um
somit
auch
österreich-spezifische
Anwendungsfälle
einfacher abdecken bzw. österreich-spezifische Attribute übertragen zu können.
Single Sign-On (SSO): Das Identitätsprotokoll soll einen vereinfachten Anmeldeprozess
mittels Single Sign-On (SSO) unterstützen.
Single Logout (SLO): Das Identitätsprotokoll soll einen vereinfachten Abmeldeprozess
mittels Single Logout (SLO) unterstüzen.
Benutzerinnen bzw. Benutzer-Zustimmung (User Consent): Hiermit wird gecheckt, ob
das Identitätsprotokoll übertragen kann, dass die Bürgerin bzw. der Bürger einem
Datentransfer von MOA-ID zur Online Applikation zugestimmt hat.
1.3.2 Organisatorische Kriterien
Dieser Abschnitt beschreibt die Kriterien für den Vergleich von Eigenschaften auf
organisatorischer Ebene.
Format des Identifikators: Hier wird verglichen, ob das Format des Identifikators vom
Protokoll spezifiziert ist, oder ob auch eigene Formate für Identifikatoren verwendet
werden können.
Format/Name weiterer Attribute: Neben einem Identifikator werden üblicherweise noch
weitere Benuterzinnen- bzw. Benutzer-spezifische Attribute übertragen. Mit diesem
Kriterium wird untersucht, ob Name bzw. Format dieser Attribute durch die Spezifikation
bereits fix festgelegt sind oder ob eigene Werte definiert und in die Spezifikation
integriert werden können.
Verbreitungsgrad: Dieses Kriterium gibt an, seit wann beispielsweise die Spezifikation
zum Identitätsprotokoll bereits existiert bzw. wie häufig das entsprechende Protokoll
bereits in Applikationen implementiert ist (z.B. durch welche Big Player).
Open-Source
Bibliotheken:
Dieses
Kriterium
untersucht,
ob
zum
jeweiligen
Identitätsprotokoll Open-Source Bibliotheken frei zur Verfügung stehen.
Interoperabilität: Dieses Kriterium checkt, ob es aufgrund von unterschiedlichen
Implementierungen des Protokolls leicht zu Interoperabilitätsproblemen kommen kann
bzw. ob Interoperabilitätstests zwischen Produkten/Implementierungen durchgeführt
werden.
Metadaten: Mit diesem Kriterium wird überprüft, ob das Identitätsprotokoll Metadaten
spezifiziert.
Applikations-Registrierung: Dieses Kriterium untersucht, wie Applikationen bei MOA-ID
registriert werden können.
Einleitung
10
1.3.3 Technische Kriterien
Dieser Abschnitt beschreibt die Kriterien für den Vergleich technischer Eigenschaften.
Austausch-Format: Dieses Kriterium untersucht das Format, mit welchem die Identitätsund Authentifizierungsdaten ausgetauscht werden können (z.B. XML oder JSON).
Bindings: Hier wird unterschieden, welche verschiedenen Austauschmöglichkeiten der
Daten zwischen MOA-ID und Online Applikation auf Transportebene möglich sind. Eine
Unterscheidung kann beispielsweise getroffen werden, ob die Daten über die Bürgerin
bzw. den Bürger (Front-Channel) oder direkt von MOA-ID an die Online Applikation
(Back-Channel) übermittelt werden.
Transfer-Protokoll: Hier wird überprüft, welches unter dem Identitätsprotokoll liegende
Transfer-Protokoll (z.B. SOAP oder REST) verwendet wird.
Token-Größe:
Mit
diesem
Kriterium
wird
die
Token-
bzw.
Objekt-Größe
der
ausgetauschten Daten verglichen.
Auswahl des Identitätsdienstleisters (IdP Disvocery): Dabei wird verglichen, wie
entsprechende Identity Provider (z.B. MOA-ID-Zentral) aufgefunden werden können.
Dies kann z.B. über Metadaten, über ein eigenes Service, etc. erfolgen.
Applikations-Authentifizierung: Dieses Kriterium gibt an, wie sich Applikationen bei
MOA-ID
im
Rahmen
eines
Bürgerinnen-
bzw. Bürger-Authentifizierungsprozesses
authentifizieren.
SP-initiiert/IdP-initiiert: Dieses Kriterium gibt an, ob eine Authentifzierung zuerst bei der
Online Applikation oder direkt bei MOA-ID angestoßen wird.
Einleitung
11
2 SAML 1.0
2.1 Allgemeines
Die Security Assertion Markup Language (SAML) ist ein auf XML-basierender Standard
zum sicheren Austausch von Identitäts-, Authentifizierungs-, oder Autorisierungsdaten.
Der Standard SAML 1.0 wurde bereits im Jahr 2002 von OASIS2 (Organization for the
Advancement of Structured Information Standards) veröffentlicht und ist daher
vielmehr nur mehr von historischer Bedeutung. Österreich war jedoch eines der ersten
Länder, welche diesen Standard implementiert und breit eingesetzt haben. Nachdem
zum aktuellen Zeitpunkt dieses Berichts SAML 1.0 immer noch das StandardIdentitätsprotokoll von MOA-ID ist, wird es in die Analyse miteinbezogen. Eine neuere
Version von MOA-ID wird jedoch mit dem aktuellen SAML 2.0 Protokoll ausgestattet
werden. Auf eine detaillierte Beschreibung von SAML selbst wird an dieser Stelle aber
verzichtet und auf die neuere und aktuelle Version 2.0 in Abschnitt 3 verwiesen.
2.2 Authentifizierungsablauf
In diesem Unterabschnitt wird ein typischer Authentifizierungsablauf zwischen Service
Provider (Online Applikation) und Identity Provider (MOA-ID) skizziert. Details in der
Kommunikation zwischen MOA-ID und der Bürgerkartenumgebung werden dabei nicht
dargestellt. Abbildung 2 skizziert dabei einen Authentifizierungsablauf auf Basis des von
SAML 1.0 spezifizierten Browser/Artifact Profils, welches auch in der aktuellen MOA-ID
Implementierung zum Einsatz kommt.
2
https://www.oasis-open.org/
SAML 1.0
12
Abbildung 2 - Prozessfluss einer SAML 1-Anmeldung mittels Browser/Artifact Profile
Der Prozessfluss wird nun etwas genauer beschrieben.
1. Eine Bürgerin bzw. ein Bürger möchte auf eine geschützte Webseite der OnlineApplikation zugreifen. Die Online Applikation bettet dabei eine URL zur
Authentifizierung ein, die direkt auf den Identity Provider MOA-ID zeigt.
2. Mit Klicken auf diese URL wird der Authentifizierungsprozess bei MOA-ID gestartet.
Dabei werden MOA-ID entsprechende Parameter wie z.B. der staatliche
Tätigkeitsbereich bzw. die URL der Online-Applikation, an die die Bürgerin bzw.
der Bürger nach erfolgreicher Authentifizierung umgeleitet werden soll,
übergeben.
3. Die beiden Prozessschritte 3 und 4 sind nur schematisch dargestellt und Details
wurden ausgespart, da sie für das eigentliche Identitätsprotokoll zwischen MOAID und der Online-Applikation von keiner Relevanz sind. Im Wesentlichen wird im
Schritt 3 von MOA-ID bei der Bürgerkartenumgebung die Personenbindung der
Bürgerin bzw. des Bürgers ausgelesen und die Erstellung einer qualifizierten
Signatur angefragt.
4. In diesem Schritt ist vereinfacht dargestellt, dass sowohl die aus der Bürgerkarte
ausgelesene Personenbindung als auch die erstellte qualifizierte Signatur an
MOA-ID übermittelt wurden.
5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOAID erfolgreich überprüft werden konnten, wird eine SAML Assertion und ein SAML
Artifact von MOA-ID generiert. Die SAML Assertion enthält gemäß MOA-ID
SAML 1.0
13
Spezifikation alle notwendigen Anmeldedaten der Bürgerin bzw. des Bürgers wie
beispielsweise bPK oder Vorname und Nachname sowie allgemein Daten zum
Authentifizierungsprozess. Der SAML Artifact stellt im Wesentlichen eine Referenz
auf diese SAML Assertion dar.
6. In diesem Schritt wird die Bürgerin bzw. der Bürger an die Online Applikation
zurückgeleitet. Die URL dieser Weiterleitung enthält dabei den SAML Artifact. Die
Weiterleitung erfolgt dabei über die Bürgerkartenumgebung
7. Die Bürgerin bzw. der Bürger wird an die Online Applikation weitergeleitet.
8. Die Online Applikation extrahiert den mitgelieferten SAML Artifact und sendet
diesen via Web Service an MOA-ID.
9. MOA-ID extrahiert den Artifact und holt die dazugehörige SAML Assertion aus
dem internen Speicher. Die SAML Assertion wird als Web Service Antwort an die
Online Applikation übertragen.
10. Basierend auf den Daten der SAML Assertion kann die Online Applikation den
Zugriff auf die Applikation gewähren.
2.3 Beispiel
Dieser Unterabschnitt zeigt Beispiele für Request- und Response-Nachrichten im
gezeigten Szenario.
2.3.1 Authentifizierungsrequest (Schritt 2)
Die Authentifizierung beim Identity Provider MOA-ID erfolgt dabei über den Aufruf einer
einfachen URL. Nachdem der Identity Provider direkt aufgerufen wird, handelt es sich
um eine IdP-initierte Authentifizierung. Diese aufgerufene URL sieht beispielsweise
folgendermaßen aus:
https://moa-id.gv.at/moa-idauth/StartAuthentication?Target=BF&OA=http://online-applikation.gv.at
Der Parameter Target gibt dabei den staatlichen Tätigkeitsbereich an und der
Parameter OA die URL der Online Applikation, an die die Bürgerin bzw. der Bürger nach
einer erfolgreichen Authentifizierung zurückgeleitet werden soll.
Im Schritt 8 wird der SAML Artifact via Web Service an den Identity Provider zum
Abholen der Assertion übertragen. Dieser SAML-Protokoll-Request – eingebettet in
einen SOAP Web Service Request – sieht z.B. wie folgt aus:
<samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
IssueInstant="2009-02-24T13:38:32+01:00" MajorVersion="1" MinorVersion="0"
RequestID="6125563722598650316">
<samlp:AssertionArtifact>
AAH5hs8aaZSFYHya0/cmtJ3QAR7rf54uhIsEcDMZFmmZ1/Qldrdf4JSK
</samlp:AssertionArtifact>
</samlp:Request>
SAML 1.0
14
2.3.3 Authentifizierungsresponse (Schritt 9)
In diesem Schritt wird eine SAML-Response-Nachricht, die eine SAML Assertion mit den
Daten der Bürgerin bzw. des Bürgers enthält, von MOA-ID an die Online Applikation
innerhalb einer SOAP Web Service Response übertragen. Eine beispielhafte SAML
Response Nachricht sieht wie folgt aus:
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" InResponseTo="-525973270146282894"
IssueInstant="2009-02-24T13:38:32+01:00" MajorVersion="1" MinorVersion="0"
ResponseID="6125563722598650316">
<samlp:Status>
<samlp:StatusCode Value="samlp:Success"> </samlp:StatusCode>
<samlp:StatusMessage>Anfrage erfolgreich beantwortet</samlp:StatusMessage>
</samlp:Status>
<saml:Assertion xmlns:pr="http://reference.e-government.gv.at/namespace/persondata/20020228#"
xmlns:si="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" AssertionID="-1780069874206367983"
IssueInstant="2009-02-24T13:37:30+01:00" Issuer="http://localhost:8080/moa-id-auth/"
MajorVersion="1" MinorVersion="0" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:AttributeStatement>
<saml:Subject>
<saml:NameIdentifier NameQualifier="urn:publicid:gv.at:cdid+bpk"
>FyOkEWMooLy8L1zwNicKAhf/vPU=</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>http://reference.egovernment.gv.at/namespace/moa/20020822#cm</saml:ConfirmationMethod>
<saml:SubjectConfirmationData/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Attribute AttributeName="PersonData"
AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#">
<saml:AttributeValue>
<pr:Person
xmlns:pr="http://reference.e-government.gv.at/namespace/persondata/20020228#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="pr:PhysicalPersonType">
<pr:Identification>
<pr:Value/>
<pr:Type>urn:publicid:gv.at:baseid</pr:Type>
</pr:Identification>
<pr:Name>
<pr:GivenName>XXXKarin Stella</pr:GivenName>
<pr:FamilyName primary="undefined">XXXKunz</pr:FamilyName>
</pr:Name>
<pr:DateOfBirth>1900-01-01</pr:DateOfBirth>
</pr:Person>
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="isQualifiedCertificate"
AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#">
<saml:AttributeValue>false</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="bkuURL"
AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#">
<saml:AttributeValue>http://localhost:3495/http-security-layer-request</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
SAML 1.0
15
</saml:Assertion>
</samlp:Response>
2.4 Diskussion
Dieser Abschnitt beinhaltet eine Diskussion von SAML 1.0 anhand der zuvor
ausgewählten Kriterien.
Funktionales Kriterium
Diskussion
Transfer von Identitäts- Identitäts- und Authentifizierungsdaten können in XML und
und
gemäß XML-Schema der SAML-Spezifikation strukturiert werden.
Authentifizierungsdaten Zahlreiche Use Cases können damit abgebildet werden.
Sicherheit
SAML 1.0 bietet zwar die Möglichkeit, einzelne SAMLNachrichten
sowie
SAML-Assertions
zu
signieren,
Verschlüsselungsmöglichkeiten von SAML-Nachrichten waren
aber in dieser Version nicht vorgesehen. Eine Verschlüsselung ist
daher nur auf Transportebene z.B. via SSL/TLS möglich.
Eine detaillierte Analyse der Sicherheit von SAML 1.0 ist unter
[SAML1_SEC] abrufbar.
Einfache
Erweiterbarkeit
Die modulare Architektur sowie die entsprechenden XMLFormate von SAML-Assertions und Protokoll-Nachrichten
wurden entsprechend für einfache Erweiterbarkeit entwickelt.
Single Sign-On (SSO)
SAML 1.0 unterstützt SSO über Domängrenzen.
Single Logout (SLO)
In SAML 1.0 wird kein SLO unterstützt.
Benutzerinnen
bzw. SAML 1.0 unterstützt bzw. definiert keine expliziten Elemente
Benutzer-Zustimmung
oder Attribute für eine Benutzer-Zustimmung bei Anmeldung.
(User Consent)
Organisatorisches
Kriterium
Format
Identifikators
Diskussion
des SAML 1.0 spezifiziert sowohl Formate für einen Identifikator
(mailAddress,
X509SubjectName,
WindowsDomainQualifiedName) als auch lässt es die
Möglichkeit eigener Definitionen offen.
Format/Name weiterer SAML 1.0 gibt keine Attribut-Namen oder –Formate vor.
Attribute
Attribute müssen jedoch einem entsprechenden Namespace
zugeordnet werden.
Verbreitungsgrad
SAML 1.0
Aufgrund der Existenz der neueren SAML Version 2.0 bereits seit
2005 ist der Verbreitungsgrad von SAML 1.0, welche 2002
veröffentlicht wurde, nur mehr gering.
16
Open-Source
Bibliotheken
[SAML_Impl] listet eine Reihe von SAML Implementierungen.
SAML 1.0 wird im Wesentlichen aber nur mehr von OpenSAML3
unterstützt. Weiter verbreitet ist noch der SAML 1.0 Nachfolger
in Version 1.1.
Interoperabilität
Offiziell wurden keine Interoperabilitäts-Tests durchgeführt.
Nach [Internet2] wurden aber unterschiedliche Produkte
vereinzelt auf Interoperabilität getestet.
Metadaten
SAML 1.0 unterstützt keine Metadaten.
ApplikationsRegistrierung
Da SAML 1.0 keine Metadaten spezifiziert, muss die
Applikationsregistrierung außerhalb der Spezifikation erfolgen.
Im Rahmen von MOA-ID erfolgt dies durch eine Eintragung in
der MOA-ID-Konfiguration.
Technisches Kriterium
Diskussion
Austausch-Format
SAML 1.0 basiert auf XML und somit auch die ausgetauschten
Daten.
Bindings
SAML 1.0 unterstützt im Wesentlichen drei Bindings. Ein BackChannel-Binding auf Basis von SOAP und zwei Front-ChannelBindings (HTTP-POST und Artifact-Binding).
Transfer-Protokoll
Neben HTTP wird SOAP als Transfer-Protokoll angeboten.
Token-Größe
Aufgrund der Verwendung von XML sind SAML 1.0-Tokens groß.
Die SAML-Response aus Abschnitt 2.3.3 hat beispielsweise 3,14
KByte.
Auswahl
des SAML 1.0 bietet keine Möglichkeit zum IdP-Discovery.
Identitätsdienstleisters
(IdP Disvocery)
ApplikationsAuthentifizierung
SAML 1.0 unterstützt eigentlich keine SP-initiierte Anmeldung
und die Anmeldedaten werden direkt an den SP
weitergeleitet. Im Rahmen von MOA-ID erfolgt eine
Authentifizierung der Applikation über die Rücksprung-URL, an
die MOA-ID erfolgreich authentifizierte Bürgerinnen bzw. Bürger
weiterleitet. Diese URL ist bei MOA-ID (Identity Provider)
konfiguriert und nur konfigurierte Applikationen sind erlaubt
Anmeldedaten zu erhalten.
SP-initiiert/IdP-initiiert
SAML 1.0 unterstützt nur eine IdP-initiierte Authentifizierung
3
http://www.opensaml.org/
SAML 1.0
17
2.5 Fazit
Die folgende Tabelle 2 listet Stärken und Schwächen von SAML 1.0
Tabelle 2 - Stärken und Schwächen von SAML 1.0
Stärken
Hat sich als Protokoll für MOA-ID bewährt
Schwächen
Nur IdP-initiierte Authentifizierung
Unterstützung bereits bestehender Online Keine Verschlüsselung
Applikationen
Ebene
auf
Nachrichten-
Kein Single Logout
Keine breite Unterstützung mehr, da abgelöst
von SAML 2.0
Eine wesentliche Stärke von SAML 1.0 ist, dass es bereits von vielen Online
Applikationen im E-Government-Umfeld unterstützt wird. Aufgrund der langen Existenz
hat sich das Protokoll im Einsatz entsprechend bewährt.
SAML 1.0 hat sich zwar als Protokoll bewährt, sollte aber in Zukunft nicht mehr im breiten
Kontext eingesetzt werden, da es bereits schon vor einigen Jahren von der
Nachfolgeversion SAML 2.0 abgelöst wurde. SAML 2.0 enhält wesentlich mehr
Funktionalität und neue Implementierungen setzen nur mehr auf SAML 2.0. Fehlende
Funktionalität von SAML 1.0 im Gegensatz zu SAML 2.0 ist beispielsweise das Fehlen
einer möglichen Verschlüsselung oder eines Single Logouts.
SAML 1.0
18
3 SAML 2.0 (PVP 2.x)
3.1 Allgemeines
SAML 2.0 ist die aktuellste Version des SAML Standards und wurde bereits im Jahr 2005
veröffentlicht [SAML_20]. Zu den veröffentlichen Spezifikationen existieren daher auch
einige Errata-Dokumente, deren Änderungen auch in eine aktualisierte SAML 2.1
Version einfließen sollen [SAML_21].
Die Architektur von SAML ist sehr modular gestaltet, sodass einzelne Komponenten
miteinander kombiniert werden können. Abbildung 3 veranschaulicht die modulare
Architektur von SAML.
Abbildung 3 - SAML Architektur [SAML2_Overview]
SAML Assertions sind das Kernelement von SAML und enthalten Identitäts- und
Authentifizierungsdaten einer authentifizierten Bürgerin bzw. eines authentifizierten
Bürgers. Prinzipiell werden drei Arten von Assertions unterschieden: Authentication
Assertion, Attribute Assertion, Authorization Assertion. Die Authentication Assertion
enthält
im
Wesentlichen
durchgeführten
zusätzliche
nur
Authentifizierung
Attribute
eines
Authentifizierungsinformationen
eines
Subjects,
Subjects,
und
Attribute
Authorization
zur
erfolgreich
Assertions
enthalten
Assertions
enthalten
Autorisierungsinformationen zu einem authentifizierten Subject. Am häufigsten werden
Authentication und Attribute Assertions eingesetzt.
SAML Protocols spezifizieren Protokolle zum Nachrichtenaustausch von SAML Assertions.
Mit Hilfe von SAML-Request Nachrichten werden SAML Assertions angefragt, mit Hilfe
von SAML-Response Nachrichten werden SAML Assertions nach einer erfolgreichen
Authentifizierung und Error-Meldungen im Fehlerfall übertragen.
SAML 2.0 (PVP 2.x)
19
Um SAML Protokollnachrichten zu transportieren, werden sogenannte SAML Bindings
definiert. SAML Bindings mappen quasi SAML Protokollnachrichten auf existierende und
standardisierte Nachrichten- und Kommunikationsprotokolle wie beispielsweise SOAP
oder HTTP.
Letztendlich werden in den sogenannten SAML Profiles einzelne Bindings, Protocols, und
Assertions so zusammengefügt, dass entsprechende Identitätsmanagement-Use Cases
abgebildet werden können.
Abgerundet wird die modulare SAML Architektur von der SAML Metadata und SAML
Authentication
Context
Spezifikation.
SAML
Metadata
beschreibt
dabei
Konfigurationsdaten für SAML Service und Identity Provider, SAML Authentication
Context
gibt
spezifizierte
Informationen
zu
Typ
und
Stärke
eines
Authentifizierungsmechanismus an.
SAML 2.0 ist ein sehr mächtiger Standard, der das Abbilden von zahlreichen
Identitätsmanagement-Use Cases erlaubt. Auch aufgrund der hiermit mitgebrachten
Komplexität
kann
es
trotz
Spezifizierung
von
Profilen
immer
wieder
zu
Interoperabilitätsproblemen kommen. Um ein gewisses Maß an Interoperabilität
zwischen unterschiedlichen Implementierungen gewährleisten zu können, hat die
Kantara
Initiative
4
ein
spezielles
Interoperabilitätsprogramm
für
SAML
2.0
Implementierungen ins Leben gerufen, welches interoperable Lösungen auflistet
[Kantara_IOP]. Zusätzlich bietet Kantara auch ein SAML standardkonformes Profil an,
das speziell auf E-Government Anwendungen abzielt [Kantara_eGov]. Dieses Profil
wurde für das Portalverbund-Protokoll (PVP) [PVP2] als Basis herangezogen und
entsprechend den Anforderungen im österreichischen E-Government erweitert bzw.
restriktiert. Nachdem das PVP-Protokoll rein auf SAML 2.0 aufbaut wird auf eine
detaillierte Analyse hier verzichtet und rein SAML 2.0 diskutiert.
In diesem Unterabschnitt wird ein typischer Authentifizierungsablauf zwischen Service
Provider (Online Applikation) und Identity Provider (MOA-ID) auf Basis von SAML 2.0
skizziert.
Details
in
der
Kommunikation
zwischen
MOA-ID
Bürgerkartenumgebung werden dabei wiederum nicht dargestellt.
und
der
Abbildung 4
skizziert dabei einen Authentifizierungsablauf auf Basis von PVP 2.X (SAML 2.0), welches
auch
in der neuesten MOA-ID Implementierung zum Einsatz kommen wird. Dabei
kommt für eine Authentifizierungs-Anfrage das HTTP-Redirect Binding und für eine
Authentifizierungs-Antwort das HTTP-POST Binding zur Anwendung.
4
http://kantarainitiative.org/
SAML 2.0 (PVP 2.x)
20
Abbildung 4 - Prozessfluss einer SAML 2.0-Anmeldung gemäß PVP 2.x
1. Eine Bürgerin bzw. ein Bürger möchte auf eine geschützte Webseite der OnlineApplikation zugreifen.
2. Die Online Applikation übermittelt einen SAML AuthnRequest via Redirect an
den affiliierten Identity Provider (MOA-ID).
3. Die Prozessschritte 3 und 4 sind nur schematisch dargestellt und Details wurden
ausgespart, da sie für das eigentliche Identitätsprotokoll zwischen MOA-ID und
der Online-Applikation von keiner Relevanz sind. Im Wesentlichen wird im Schritt
3 von MOA-ID bei der Bürgerkartenumgebung die Personenbindung der
Signatur angefragt.
5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOAID erfolgreich überprüft werden konnten, wird eine SAML Assertion von MOA-ID
generiert. Die SAML Assertion enthält gemäß SAML 2.0 Spezifikation und PVP 2.x
Spezifikation alle für die Online Applikation notwendigen Anmeldedaten der
Bürgerin bzw. des Bürgers wie beispielsweise bPK oder Vorname und Nachname
sowie allgemein Daten zum Authentifizierungsprozess. Welche Attribute von
SAML 2.0 (PVP 2.x)
21
MOA-ID an die Applikation übertragen werden, werden in den Metadaten der
Online Applikation (Service Provider) definiert.
6. In diesem Schritt wird die Bürgerin bzw. der Bürger vom Fokus mit der
Bürgerkartenumgebung nochmals auf den Identity Provider umgeleitet, um
wieder dort den Fokus des Browsers zu erhalten.
7. Die SAML Response, welche die erstellte SAML Assertion inkludiert, wird mittels
HTTP-POST an den Service Provider übermittelt
3.3 Beispiel
Dieser Unterabschnitt zeigt Beispiele für Request- und Response Nachrichten im
gezeigten Szenario.
Der SAML AuthnRequest zum Starten einer Authentifizierung wird dabei im dargestellten
Szenario vom Service Provider an den Identity Provider mittels HTTP-Redirect Binding
übermittelt. Dabei wird der SAML Request entsprechend in der URL kodiert. Ein Beispiel
für so eine Übermittlung sieht wie folgt aus:
https://demo.egiz.gv.at/demoportal_moaid2.0/pvp2/redirect?SAMLRequest=nZX...fb9&SigAlg=http%3A%2F%2Fwww.w3.org
%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=I%...%3D
Der Parameter SAMLRequest enthält den XML-Request in Base64-kodierter Form, der
Parameter SigAlg gibt den verwendeten Signaturalgorithmus an, und der Parameter
Signature enthält den Signaturwert.
Ein Beispiel eines dekodierten SAML AuthnRequests ist hier zu finden:
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceIndex="1" AttributeConsumingServiceIndex="0"
Destination="https://demo.egiz.gv.at/demoportal_moaid-2.0/pvp2/post"
ID="_e1ecdd2d80062991f8f0f489dfc49441" IssueInstant="2013-08-13T14:13:29.392Z" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">demologin-pvp2-sso/main/</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_e1ecdd2d80062991f8f0f489dfc49441">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>qGqkR6stEnKFS04DQ6yx44CDzzo=</ds:DigestValue>
</ds:Reference>
SAML 2.0 (PVP 2.x)
22
</ds:SignedInfo>
<ds:SignatureValue>GhvpD+urP2BwEaejBW3Y3dmdIKdFDR9AikVn0TAyWBg3d/+gYxBQ0JHPn/XCoHP6QQ
HbNHjfqf8o2wJQrvX9WD/BPJHK2wwecbzPK2cCIco5bGqhGq+LKwHPesHu10nrIfj4T8lAHX4lPiYR5OEDMX
tV1SvHfWIzXEBGh/MyJtk2qAFDT4OfglneNk8hYPjcwNb8MwMME+tlR97snFMzkXI5tHSKB8LzGIPq+K2A0
c06AX2LJiT8xaDscJTqqeaub4zIm6haZ1LZX0qMH2jFJVVjAfYbV2BhdSs6aseTLSp+k2rlPJqvpds8PBN26I8KY
bk/bwQIZ0hSSo//f+q2cw==</ds:SignatureValue>
<ds:KeyInfo>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>nEPzKMh3TovnfBnTyv+TMYFsGep8Uil7iNbfVyfLoBfqRdeGDOk4es2qWkgB6az+kM/9Js2H06
m4
pjEY7/RIjd0lMWqgi8eqdjilMmbFQykkYYQhlZbvi8KqoBcCKzj5N3GY4qh8A5qN4y85Q3sZj23T
iiIY1rphE+ZTOHCm6CKeRso9jj409YHP1xAXfPvtIYx2TA1uuagxOmL75OC/hr7gcUm0tmuKiSeq
+TO4VZw2Q7K7YESZ1WkiBoG2i4cHdcBFKnVrGNtyxl6UkjWxXRJSU9aNLs5QxsE6iFwCvFoIO+IU
cVWxfFHqOGbRtAcRUb4fk+KFHE2o1DLmfwZaUQ==</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:NameID>demologin-pvp2-sso/main/</saml2:NameID>
</saml2:Subject>
<saml2p:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
<saml2p:RequestedAuthnContext>
<saml2:AuthnContextClassRef comparison=”minimum”
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://www.stork.gov.eu/1.0/citizenQAALevel/4</saml2:
AuthnContextClassRef>
</saml2p:RequestedAuthnContext>
</saml2p:AuthnRequest>
Im dargestellten Szenario wird die SAML Assertion – eingepackt in einer SAML Response
– mittels HTTP-POST vom Identity Provider an den Service Provider übertragen. Die SAML
Response wird dabei vom Browser der Bürgerin bzw. des Bürgers automatisch mittels
JavaScript übermittelt.
Eine beispielhafte SAML Response sieht folgendermaßen aus:
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://demo.egiz.gv.at/demologin-pvp2-sso/securearea.action"
InResponseTo="_e1ecdd2d80062991f8f0f489dfc49441" Version="2.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">MOA-ID 2.0 Demo IDP</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="xs"/>
SAML 2.0 (PVP 2.x)
23
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>fCIPTTSFEpAfyygpSiZ6cBEhPEI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>jmajoi0Ar3FL1o43CG63UJypkzjThiqvsS4bBwg9COqlrjJYjgpfDPhLlexZxoWAbTZ2o1YyF
229R8/mdimiQV0UO+BqbloddbfxloD64djdgr2xDCdnoNjOvFFZaxMxcaXtOfFzgmWTWy5sDVdqfyzT6L5ezJ81
slapBzjgrZvcsBCLIVetU1qDMnM4LC0jmwe+12RBOL342O+Rg40fhBTk88z/mot8KfrvbM9kFrocf5ECB8Ry8iE
AupAlZJw8xiphv8lRPTxevmwpSwdNqDqiW/a3twA8NxzE0YQEi0dgsa5YZXICrUPP9iFUyV7bu86TRqdpsdzoA
98NcMCFTw==</ds:SignatureValue>
<ds:KeyInfo>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>mWrWy07+hO2VoMeOHpizN3qU2cL2e3EkzAkowmG+OpsR3UpI0dvolRuzaxDPUeANfE913KP
empsT
3cOKGS5IIBmxPgZM1H7EcEPVS2PYimMr1HztBMJMGAdFVFeVFsgdYP4cbwPUs03/E6kVmN7/C+vM
yRPMD7i83YL8/IHChymZ5aJTsRXUpM0TjQQPBQbnnHVWzjcUJ9z9KataS/KpUUM8iSWk73u/gWOs
3vbQLoro80xjLsSdXyJ9dVTCTwCpdP5UJPlsNLg1F7AU+OHwem76rezI0JJZhHUMg6v1xWzh8Xyc
I6CizpD6RmkMXfICbFD8TR5zcNBieH/yNQeAEw==</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_44cd6604c7a58fff4f5df402310902ad" IssueInstant="2013-08-13T14:18:15.647Z" Version="2.0">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">MOA-ID 2.0 Demo
IDP</saml2:Issuer>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="urn:publicid:gv.at:cdid+BF">BF:fkK+ZDGFNrasdfsWdsnS4fkt5Yc=</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="_e1ecdd2d80062991f8f0f489dfc49441"
NotOnOrAfter="2013-08-13T14:38:15.647Z" Recipient="demologin-pvp2-sso/main/"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2013-08-13T14:18:15.647Z"
NotOnOrAfter="2013-08-13T14:38:15.647Z">
<saml2:AudienceRestriction>
<saml2:Audience>demologin-pvp2-sso/main/</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2013-08-13T14:18:15.636Z"
SessionIndex="_45945f7d295bf27f8847eb81e88c09c8">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>http://www.stork.gov.eu/1.0/citizenQAALevel/4</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="PVP-VERSION" Name="urn:oid:1.2.40.0.10.2.1.1.261.10"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">2.1</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="PRINCIPAL-NAME" Name="urn:oid:1.2.40.0.10.2.1.1.261.20"
SAML 2.0 (PVP 2.x)
24
xsi:type="xs:string">Mustermann</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="BPK" Name="urn:oid:1.2.40.0.10.2.1.1.149"
xsi:type="xs:string">BF:fkK+ZDGFNrasdfsWdsnS4fkt5Yc=</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="EID-SECTOR-FOR-IDENTIFIER"
Name="urn:oid:1.2.40.0.10.2.1.1.261.34"
xsi:type="xs:string">urn:publicid:gv.at:cdid+BF</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</saml2p:Response>
3.4 Diskussion
Dieser Abschnitt beinhaltet eine Diskussion von SAML 2.0 anhand der zuvor
Diskussion
und
gemäß XML-Schema der SAML-Spezifikation strukturiert werden.
Authentifizierungsdaten Zahlreiche Use Cases können damit abgebildet werden.
Sicherheit
SAML 2.0 bietet die Möglichkeit einzelne SAML-Nachrichten,
aber auch SAML Assertions mit XML -Signaturen zu versehen.
Um Vertraulichkeit zu gewährleisten, können ganze Assertions,
aber auch nur einzelne Teile wie Attribute, mittels XMLEncryption verschlüsselt werden. Nebenbei wird der Einsatz von
sicheren Protokollen auf Transportebene, wie z.B. SSL/TLS oder
IPsec empfohlen.
Eine detaillierte Analyse der Sicherheit von SAML 2.0 ist unter
[SAML2_SEC] abrufbar.
Einfache
Erweiterbarkeit
Die modulare SAML-Architektur sowie die entsprechenden
XML-Formate von SAML-Assertions und Protokoll-Nachrichten
wurden entsprechend für einfache Erweiterbarkeit entwickelt.
SAML 2.0 unterstützt SSO über Domängrenzen.
Single Logout (SLO)
SAML 2.0 unterstützt SLO über Domängrenzen. Es wurden
einzelne Protokolle und Profile dafür spezifiziert.
Benutzerinnen
bzw. SAML 2.0 unterstützt bzw. definiert explizite, aber optionale
Benutzer-Zustimmung
Elemente für eine Benutzer-Zustimmung bei einer Anmeldung.
SAML 2.0 (PVP 2.x)
25
(User Consent)
Der Service Provider erhält dadurch Informationen, ob ein
Principal bzw. wie ein Principal seine Zustimmung zur
Anmeldung gegeben hat.
Organisatorisches
Kriterium
Format
Identifikators
Diskussion
des SAML 2.0 spezifiziert mehrere Formate für den Identifikator, z.B.
ob dieser persistent oder nur temporär ausgestellt wurde.
Nebenbei lässt SAML 2.0 aber auch die Möglichkeit eigener
Definitionen offen.
Format/Name weiterer SAML 2.0 gibt keine Attribut-Namen vor. Formate können aber
Attribute
beispielsweise als String oder URI definiert sein.
Verbreitungsgrad
Nachdem die Version 2.0 bereits seit 2005 spezifiziert ist, gibt es
auch schon zahlreiche Implementierungen [SAML_Impl].
[SAML_Kant_Impl]
listet
weitere
interoperable
Implementierugen. [ZZA12] gibt einen Überblick über die
Verbreitung von SAML innerhalb der Europäischen Union.
Open-Source
Bibliotheken
[SAML_Impl] und [SAML_Kant_Impl] listen zahlreiche SAML 2.0
Implementierungen, darunter gibt es auch einige Open-Source
Implementierungen.
Interoperabilität
Die Kantara Initiative testete in 2010 zahlreiche Produkute auf
deren Interoperabilität. Eine Liste von interoperablen Produkten
kann unter [SAML_Kant_Impl] gefunden werden.
Metadaten
SAML 2.0 unterstützt eigene Metadaten, die auch in einem
entsprechendem Dokument [SAML2_Metadata] spezifiziert
sind.
Applikationen bzw. Service Provider werden beim Identity
Provider über den Austausch von Metadaten registriert. Der
Identity Provider überprüft dabei die Struktur sowie Signatur der
Service Provider-Metadaten.
Diskussion
Austausch-Format
SAML 2.0 basiert auf XML und somit auch die ausgetauschten
Daten.
Bindings
SAML 2.0 unterstützt zahlreiche Bindings. Die bekanntesten und
am häufigsten verwendeten Bindings sind das HTTP-Recirect-,
HTTP-Post-, Artifact- und SOAP-Binding. Es existieren also sowohl
Front-Channel als auch Back-Channel Bindings. Details zu
SAML 2.0 (PVP 2.x)
26
diesen und weiteren Bindings können unter [SAML2_Bindings]
gefunden werden.
Transfer-Protokoll
Neben HTTP wird SOAP als Transfer-Protokoll angeboten.
Token-Größe
Aufgrund der Verwendung von XML sind SAML 2.0-Tokens
ebenfalls sehr groß. Die SAML-Response aus Abschnitt 3.3.2 hat
beispielsweise 5,7 KByte.
Auswahl
des SAML 2.0 spezifiert das sogenannte „Identity Provider Discovery
Profile“ [SAML2_Profiles] zum Auffinden bzw. zur Auswahl eines
(IdP Disvocery)
Identity Providers.
Applikationen werden über ihre zuvor konfigurierten
Metadaten beim Identity Provider authentifiziert. Während
eines Authentifizierungsprozesses wird einerseits die Signatur der
Authentifizierungsanfrage überprüft und andererseits das für
die Signatur verwendete Zertifikat mit den Metadaten
abgeglichen.
SAML 2.0 unterstützt sowohl eine IdP-initiierte als auch eine SPinitiierte Authentifizierung.
3.5 Fazit
Die folgende Tabelle 3 listet Stärken und Schwächen von SAML 2.0
Tabelle 3 - Stärken und Schwächen von SAML 2.0
Stärken
Schwächen
Weit verbreitet
„Schwergewichtig“, da XML-basierend
Zahlreiche Implementierungen
Profile
müssen
meist
konkretisiert werden.
Modularer Aufbau
Umfangreiche Spezifikation
Unterstützung zahlreicher Use Cases
Schlechte Integration mit mobilen Clients
trotzdem
noch
Metadaten-Spezifikation
IdP-Discovery
Unterstützung Single Logout
SAML 2.0 existiert bereits seit dem Jahr 2005 und es existieren bereits zahlreiche
Implementierungen in unterschiedlichen Programmiersprachen. Viele Identätslösungen
sowohl im behördlichen als auch im privatwirtschaftlichen Bereich setzen SAML 2.0 ein.
Ein Kernaspekt von SAML 2.0 ist, dass sehr viele Anwendungsfälle damit abgedeckt
werden können. SAML 2.0 spezifiziert beispielswese IdP-Discovery oder Single Logout. Es
SAML 2.0 (PVP 2.x)
27
ist aber auch möglich – aufgrund des modularen Aufbaus von SAML 2.0 – SAML 2.0 für
nicht in SAML spezifizierte Anwendungsfälle einzusetzen.
Die Ausführlichkeit der Spezifzikation hat aber auch den Nachteil, dass die
Verwendung manchmal sehr komplex erscheint und durch die offene Gestaltung
bereits spezifizierte Profile trotzdem noch konkretisiert werden müssen. Aufgrund der
Verwendung von XML sind die übertragenenen Datenmengen größer als bei anderen
Identitäsprotokollen. Dadurch eignet sich SAML auch nicht so gut für die Verwendung
in mobilen Clients.
Nichtsdestotrotz ist SAML 2.0 ein sehr ausgereifter und weit verbreiteter Standard, für
den zahlreiche Implementierungen existieren.
Deswegen und aufgrund der
Unterstützung zahlereicher Anwendungsfälle ist SAML 2.0 sehr gut für einen Einsatz in
MOA-ID geeignet.
SAML 2.0 (PVP 2.x)
28
4 OAuth 2.0
4.1 Allgemeines
Die erste Version von OAuth5 (Version 1.0) wurde im Jahre 2007 als finale Draft Version
veröffentlicht, die finale Version dann drei Jahre später als RFC 5849 [OAuth1] im Jahr
2010. Die aktuelle und nachfolgende Version 2.0, die in diesem Kapitel behandelt wird,
wurde als RFC 6749 [OAuth2][OAuth2][OAuth2] im Oktober 2012 veröffentlicht. Version
2.0 ist jedoch nicht zu Version 1.0 abwärtskompatibel.
Die prinzipielle Idee von OAuth ist es, unterschiedlichen Client-Applikationen wie z.B.
Web-, Desktop-, oder mobilen Applikationen Zugriff auf geschützte Endnutzer-Daten zu
gewähren. OAuth zielt dabei viel mehr auf Autorisierung anstatt Authentifizierung ab,
da eine Applikation von einer Benutzerin bzw. einem Benutzer berechtigt werden kann,
auf ihre bzw. seine Daten zugreifen zu dürfen.
Die aktuelle OAuth-Spezifikation besteht im Wesentlichen aus dem Kern-RFC 6749. Wie
bei den meisten anderen Spezifikationen existiert aber auch hier eine Reihe von
anderen Begleit-Dokumenten, die die Funktionalität von OAuth in gewissen Bereichen
erweitert bzw. einschränkt. In den folgenden Unterabschnitten wird genauer auf die
Eigenschaften von OAuth 2.0 eingegangen.
In diesem Unterabschnitt wird skizziert, wie eine MOA-ID Anmeldung mittels Bürgerkarte
bei einer Online Applikation unter Verwendung von OAuth 2.0 aussehen könnte. Der
Authentifizierungsprozess ist dabei abstrakt gehalten und lehnt sich an den typischen
OAuth Use Case an. Die Verwendung von OAuth für eine Bürgerkartenauthentifzierung
bedarf aber einer genaueren Analyse. Im Besonderen würde sich OpenID Connect
dafür eignen, da es auf Authentifizierung und nicht Autorisierung abzielt, jedoch auf
OAuth aufbaut.
5
http://oauth.net/
OAuth 2.0
29
Abbildung 5 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von OAuth 2.0
2. Die Online Applikation (Client) sendet einen Authorization Request, welcher die
ID der Online Applikation sowie eine Rücksprung-URL (Redirection URI) beinhaltet,
an den Authorization Server, in diesem Fall MOA-ID.
Signatur angefragt.
5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOAID erfolgreich überprüft werden konnten, wird ein Authorization Code von MOAID generiert. In diesem Schritt bzw. mit der qualifizierten Signatur stimmt auch die
OAuth 2.0
30
Bürgerin bzw. der Bürger der Weitergabe der Identitätsdaten an die Online
Applikation zu, was die Generierung des Authorization Codes auslöst.
Bürgerkartenumgebung nochmals auf MOA-ID umgeleitet, um wieder dort den
Fokus des Browsers zu erhalten.
7. Der Authorization Code wird mittels Redirect an die Online Applikation
übermittelt. Der Endpoint der Online Applikation entspricht dabei der in Schritt 2
an MOA-ID übermittelten Redirection URI.
8. Die Online Applikation frägt bei MOA-ID um ein sogenanntes Access Token an.
Die Anfrage enthält dabei den Authorization Code sowie nochmals dieselbe
Redirection URI, welche in Schritt 2 zur Abfrage des Authorization Codes
verwendet wurde. Das Access Token wird in weiterer Folge für den Zugriff auf die
Identitätsdaten der Bürgerin bzw. des Bürgers benötigt.
9. MOA-ID authentifiziert die Online Applikation, verifiziert den Authorization Code
und überprüft die Redirection URI. Bei Erfolg wird ein Access Token an die Online
Applikation übermittelt.
10. Nachdem
in
diesem
dargestellten
Szenario
MOA-ID
die
Funktion
des
Authorization und des Resource Servers übernimmt, wird das Access Token von
der Online Applikation wieder an MOA-ID übermittelt.
11. Abhängig vom Typ des Access Tokens sowie dessen Anforderungen überprüft
MOA-ID die Gültigkeit des zuvor übermittelten Access Tokens. Ist das Token gültig,
so kann entsprechende Identitätsinformation an die Online Applikation
übermittelt werden.
12. Die Online Applikation überprüft die übermittelten Identitätsdaten und gewährt
oder verweigert den Zugriff auf das Service.
4.3 Beispiel
Dieser Unterabschnitt zeigt Beispiele für ausgewählte Request- und ResponseNachrichten im gezeigten Szenario.
4.3.1 Authorization Request (Schritt 2)
In diesem Schritt übermittelt die Online Applikation einen Authorization Request an
MOA-ID. Ein Request sieht beispielsweise wie folgt aus:
GET /authorize?response type=code&client id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fonline%2Eapplikation%2Egv%2Eat%2Fcb HTTP/1.1
Host: moa-id.gv.at
Der HTTP-Parameter response_type gibt dabei an, dass für die Zustimmung zur
Autorisierung von MOA-ID an die Online Applikation ein Authorization Code übermittelt
werden soll. Der Parameter client_id definiert einen von der Online Applikation für
OAuth 2.0
31
MOA-ID eindeutigen Identifikator und redirect_uri gibt die Rücksprung-URL der
Applikation an.
4.3.2 Authorization Response (Schritt 7)
Eine beispielhafte Authorization Response sieht wie folgt aus:
HTTP/1.1 302 Found
Location: https://online-applikation.gv.at/cb?code=SplxlOBeZQQYbYS6WxSbIA
Der Parameter code enthält dabei den Authorization Code.
4.3.3 Access Token Request (Schritt 8)
Ein beispielhafter Access Token Request sieht wie folgt aus:
POST /token HTTP/1.1
Host: moa-id.gv.at
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fonline%2Eapplikation%2Egv%2Eat%2Fcb
Der Parameter grant_type spezifiziert den Typ der Autorisierung (in diesem Beispiel
mittels Authorization Token), code gibt den Wert des Authorization Tokens direkt an,
und redirect_uri definiert nochmals die Rücksprung-URL.
4.3.4 Access Token Response (Schritt 9)
Eine beispielhafte Access Token Response sieht wie folgt aus:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"Bearer",
"expires_in":3600,
}
Der Wert access_token enthält dabei das eigentliche Access Token, der Parameter
token_type spezifiziert den Typ des Tokens, wie z.B. in [OAuth2_Bearer] definiert, und
expires_in gibt die Gültigkeit des Tokens an.
4.3.5 UserInfo Request (Schritt 10)
Ein beispielhafter Request, welcher ein Access Token beinhaltet, sieht wie folgt aus:
POST /resource HTTP/1.1
Host: server.example.com
access_token=2YotnFZFEjr1zCsicMWpAA
Der Parameter access_token enthält dabei das eigentliche Access Token.
4.3.6 UserInfo Response (Schritt 11)
Eine beispielhafte Response der Identitätsdaten sieht wie folgt aus:
OAuth 2.0
32
HTTP/1.1 200 OK
Pragma: no-cache
{
"bpk":"12345==",
"given_name":"Max",
"family_name":,"Mustermann"
}
Die in der Response beinhalteten Parameter und Werte enthalten dabei die
Identitätsdaten der Bürgerin bzw. des Bürgers.
4.4 Diskussion
Dieser Abschnitt beinhaltet eine Diskussion von OAuth 2.0 anhand der zuvor
Diskussion
Transfer von Identitäts- Identitäts- und Authentifizierungsdaten können mittels URLund
Parameter bzw. JSON zwischen den einzelnen beteiligten
Authentifizierungsdaten Parteien ausgetauscht werden.
Sicherheit
Standardmäßig unterstützt OAuth weder Signaturen noch
Verschlüsselung. Für den sicheren Datenaustausch setzt OAuth
komplett auf SSL/TLS und dessen Funktion für ServerAuthentifizierung und Gewährung der Vertraulichkeit. Die
Möglichkeit von Signaturen ist zwar teilweise gegeben, wird
aber nicht näher spezifiziert.
Die Sicherheit von OAuth 2.0 wird generell ausführlich in der
eigenen Spezifikation, aber auch unter [OAuth2_SEC] diskutiert.
Weitere Möglichkeiten, die Sicherheit von OAuth zu erhöhen,
wäre die Verwendung von SAML 2.0 Assertions [OAuth_SAML]
bzw. von JSON Web Tokens (JWT) [JWT], welche Signaturen und
Verschlüsselung anbieten. Beide Spezifikationen sind aber
derzeit noch im Draft-Status.
Einfache
Erweiterbarkeit
OAuth ist im Wesentlichen ein Rahmenwerk und nicht nur ein
spezifisches Protokoll. Somit erlaubt es viel Raum für eigene
Spezifizierungen und Erweiterungen. Die OAuth 2.0 Spezifikation
sagt sogar explizit, dass einzelne Komponenten teilweise oder
komplett undefiniert sind und entsprechende Profile dazu
erwartet werden.
SSO-Funktionalität wird von OAuth selbst nicht konkret
spezifiziert. Aufgrund der Verwendung desselben Authorization
Servers für mehrere Clients kann aber SSO erreicht werden.
Single Logout (SLO)
SLO wird von OAuth nicht unterstützt.
Benutzerinnen
bzw. OAuth spezifiziert keine Details, wie eine Benutzerin bzw. ein
Benutzer-Zustimmung
Benutzer dem Datenzugriff eines Clients auf Ressourcen
zugestimmt hat. Der Client erhält nur über unterschiedliche
OAuth 2.0
33
(User Consent)
Bestätigungsmöglichkeiten die Information, dass die Benutzerin
bzw. der Benutzer den Datenzugriff autorisiert hat.
Organisatorisches
Kriterium
Format
Identifikators
Diskussion
des OAuth spezifiziert
Identifikator.
kein
Format
für
einen
übertragenen
Format/Name weiterer OAuth spezifiziert keine Attribut-Namen und lässt die Definition
Attribute
offen.
Verbreitungsgrad
Obwohl erst seit 2012 final, ist OAuth 2.0 bereits weit verbreitet,
da viele namhafte Anbieter von Social Network-Content wie
z.B. Google, Facebook, Twitter, etc. auf diesem Protokoll
aufbauen. Eine Liste von Service Providern, die OAuth
unterstützen, kann unter [OAuth_Wiki] gefunden werden.
Open-Source
Bibliotheken
Für OAuth existiert ebenfalls eine Menge an Open SourceImplementierungen.
Eine Liste von Implementierungen in
unterschiedlichen
Programmiersprachen
ist
unter
[OAuth2_Code]abrufbar.
Interoperabilität
OAuth spezifiziert im Wesentlichen ein Rahmenwerk zur
einfachen Autorisierung. In der OAuth 2.0 Spezifikation sind
bewusst Teile nicht ausspezifiziert. Hinsichtlich Interoperabilität
ist das natürlich ein großer Nachteil, da Implementierungen auf
bestimmte Server zugeschnitten werden. Die Autoren der
Spezifikation gehen jedoch schon davon aus, dass zusätzliche
Profilierungen
der
Spezifikation
notwendig
sind,
um
Interoperabilität zu erreichen [OAuth2].
Metadaten
OAuth unterstützt keine expliziten Metadaten. Auffinden von
Endpoints beispielsweise ist zwar notwendig aber out-of-scope
der Spezifikation.
Wie Applikationen sich beim Authorization Server registrieren,
wird in der OAuth-Spezifikation nicht beschrieben. Es wird aber
angedeutet, dass eine Benutzer-Interaktion mittels HTML-Seite
typisch ist. Prinzipiell ist keine direkte Interaktion zwischen
Applikation und Authorization Server notwendig. Die
Spezifikation schließt auch generell keine nicht-registrierten
Applikationen aus, lässt Details dazu jedoch offen.
Austausch-Format
OAuth 2.0
Diskussion
OAuth verwendet für den Datenaustausch einfache HTTP34
Nachrichten, welche auch JSON-Objekte beinhalten können.
Bindings
Für die Übertragung von OAuth-Parametern
stehen
unterschiedliche Möglichkeiten des HTTP-Protokolls zur
Verfügung, wie z.B. als Body in einer HTML-Form oder als URI
Query Parameter. Prinzipiell wird sowohl Front- als auch BackChannel-Kommunikation verwendet.
Transfer-Protokoll
Prinzipiell wird nur HTTP unterstützt, andere Transfer-Protokolle
werden jedoch nicht ausgeschlossen, sind aber in OAuth 2.0
selbst nicht spezifiziert.
Token-Größe
Nachdem nur HTTP-Parameter bzw. JSON-Objekte verwendet
werden, ist die Token-Größe gering. Das Token aus dem Beispiel
aus Abschnitt 4.3.6 hat beispielsweise nur 77 Byte.
Auswahl
des OAuth 2.0 lässt ein IdP-Discovery vollkommen unspezifiziert.
(IdP Disvocery)
Der Authorization Server ordnet jeder Applikation einen für ihn
eindeutigen Identifikator zu, der für eine ApplikationsAuthentifizierung genutzt werden kann. Generell wird in der
OAuth
2.0
Spezifikation
die
Art
der
ApplikationsAuthentifizierung offen gelassen, sie muss nur den festgelegten
Sicherheitsanforderungen des Authorization Servers genügen.
OAuth 2.0 unterstützt nur eine SP-initiierte Authentifizierung.
4.5 Fazit
Die folgende Tabelle 4 listet Stärken und Schwächen von OAuth 2.0.
Tabelle 4 - Stärken und Schwächen von OAuth 2.0
Stärken
Schwächen
Weit verbreitet
Sehr offene Spezifikation
Zahlreiche Implementierungen
Notwendigkeit von Profilierung
Leichtgewichtig, da HTTP und JSON
Höhere Sicherheit nur mittels erweiterter
Spezifikation
Gute Integration mit mobilen Clients
Hautptsächlich für Autorisierung
Kein Single Logout
OAuth besitzt bereits eine weite Verbreitung und es existieren auch zahlreiche
Implementierungen. Besonders im Cloud- und Web 2.0-Kontext findet OAuth breiten
Anklang. Im Gegensatz zu SAML ist OAuth leichtgewichtiger, da im Gegensatz zu XML
OAuth 2.0
35
nur HTTP-Werte bzw. JSON-Tokens ausgetauscht werden. Dadurch eignet sich OAuth
auch eher für einen Einsatz in mobilen Clients.
Ein wesentlicher Nachteil von OAuth im Zusammenhang mit MOA-ID ist, dass es
eigentlich auf Autorisierung und nicht auf Authentifizierung abzielt. Für einen Einsatz in
MOA-ID müsste die Spezifikation quasi auf den Use Case der Authentifizierung
„umgebogen“ werden. Dies benötigt insofern einen erhöhten Arbeitsaufwand, da die
Spezifikation sehr offen gestaltet ist und entsprechend profiliert und so auf die
Anforderungen von MOA-ID angepasst werden muss. In der Spezifikation von OAuth
werden weiters einige wichtige Punkte, wie z.B. Single Logout vermisst. Außerdem
werden entsprechende Sicherheitsmechanismen nur mittels erweiterter Spezifikationen
und nicht Out-Of-the-Box unterstützt.
Obwohl OAuth eine weite Verbreitung findet, ist es ohne weitere Profilierung für einen
Einsatz in MOA-ID ungeeignet, da es primär auf die Autorisierung von Applikationen
abzielt.
OAuth 2.0
36
5 OpenID Connect
5.1 Allgemeines
OpenID Connect6 ist noch eine junge Spezifikation und aktuell in der Version 1.0 noch
im Draft Status. Obwohl der Name dazu verleiten mag, anzunehmen dass OpenID
Connect nur eine Erweiterung von OpenID ist, so setzt die Spezifikation viel mehr auf
den zuvor beschriebenen OAuth 2.0 Protokoll auf. Im Wesentlichen handelt es sich
dabei aber um eine leichtgewichtige Spezifikation und ein Rahmenwerk für den
Austausch von Identitätsdaten via REST-API. Die Funktionalität von OAuth 2.0 ist
vollständig inkludiert, OpenID 2.0-Funktionalitäten können jedoch mittels Erweiterungen
integriert werden.
OpenID Connect unterstützt unterschiedliche Arten von Clients für den Austausch von
Identitätsdaten, z.B. Browser-basierte, mobile, oder JavaScript-Clients. Prinzipiell wird bei
OpenID Connect wie bei OAuth 2.0 auf SSL/TLS für den sicheren Datenaustausch
gesetzt,
die
Spezifikation
kann
jedoch
erweitert
werden,
um
beispielsweise
Verschlüsselung, IdP-Discovery, oder Logout zu unterstützen.
Die aktuelle Spezifikation 1.0 ist in sechs Dokumente aufgeteilt, die komplette ProtokollSuite und die einzelnen Komponenten sind in Abbildung 6 dargestellt.
Abbildung 6 - OpenID Connect Protocol Suite
Dieser Unterabschnitt skizziert einen möglichen Authentifizierungsablauf für eine
Bürgerkartenauthentifizierung
6
unter
Verwendung
von
OpenID
Connect.
http://openid.net/connect/
OpenID Connect
37
Der
Authentifizierungsablauf ist jenem von OAuth sehr ähnlich, OpenID Connect spezifiziert
den Prozessablauf jedoch schon etwas genauer. Die Verwendung von OpenID
Connect für eine MOA-ID Authentifizierung bedarf jedoch noch einer etwas
genaueren Analyse und einer weiteren Profilierung, um den Anforderungen einer
Bürgerkartenauthentifizierung gerecht zu werden.
Abbildung 7 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von OpenID Connect 1.0
2. Die Online Applikation (Client) sendet einen Authorization Request, welcher die
ID der Online Applikation, den Scope der Authentifizierung, sowie eine
Rücksprung-URL (Redirection URI) beinhaltet, an den Authorization Server, in
diesem Fall MOA-ID. Der Request kann über HTTP-GET oder HTTP-POST erfolgen
und ist mittels SSL/TLS geschützt.
OpenID Connect
38
Signatur angefragt.
5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOAID erfolgreich überprüft werden konnten, wird ein Authorization Code von MOAID generiert. In diesem Schritt bzw. mit der qualifizierten Signatur stimmt auch die
Bürgerin bzw. der Bürger der Weitergabe der Identitätsdaten an die Online
Applikation zu, was die Generierung des Authorization Codes auslöst.
7. Der Authorization Code wird mittels Redirect an die Online Applikation
übermittelt. Der Endpoint der Online Applikation entspricht dabei der in Schritt 2
an MOA-ID übermittelten Redirection URI.
8. Die Online Applikation frägt bei MOA-ID um ein sogenanntes Access Token an.
Die Anfrage enthält dabei den Authorization Code sowie nochmals dieselbe
Redirection URI, welche in Schritt 2 zur Abfrage des Authorization Codes
verwendet wurde. Das Access Token wird in weiterer Folge für den Zugriff auf die
Identitätsdaten der Bürgerin bzw. des Bürgers benötigt.
9. MOA-ID authentifiziert die Online Applikation, verifiziert den Authorization Code
und überprüft die Redirection URI. Bei Erfolg wird ein Access Token an die Online
Applikation übermittelt.
10. Nachdem
in
diesem
dargestellten
Szenario
MOA-ID
die
Funktion
des
Authorization und des Resource Servers übernimmt, wird das Access Token von
der Online Applikation wieder an MOA-ID übermittelt.
11. Abhängig vom Typ des Access Tokens sowie dessen Anforderungen überprüft
MOA-ID die Gültigkeit des zuvor übermittelten Access Tokens. Ist das Token gültig,
so kann entsprechende Identitätsinformation an die Online Applikation
übermittelt werden.
5.3 Beispiel
5.3.1 Authorization Request (Schritt 2)
In diesem Schritt übermittelt die Online Applikation einen Authorization Request an
MOA-ID. Ein Request sieht beispielsweise wie folgt aus:
OpenID Connect
39
https://moa-id.gv.at/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%online.applikation.gv.at%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
Der HTTP-Parameter response_type gibt dabei an, dass für die Zustimmung zur
Autorisierung von MOA-ID an die Online Applikation ein Authorization Code übermittelt
werden soll. Der Parameter client_id definiert einen von der Online Applikation für
MOA-ID eindeutigen Identifikator und redirect_uri gibt die Rücksprung-URL der
Applikation an. Der Scope scope gibt beispielsweise an, welche Attribute angefragt
werden sollen. Der Parameter state dient zum State-Management beim Client.
5.3.2 Authorization Response (Schritt 7)
HTTP/1.1 302 Found
Location: https://online.applikation.gv.at/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
Der Parameter code enthält dabei den Authorization Code und der Parameter state
den im Request übermittelten State der Applikation (des Clients).
5.3.3 Access Token Request (Schritt 8)
Ein beispielhafter Access Token Request sieht wie folgt aus:
POST /token HTTP/1.1
Host: moa-id.gv.at
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fonline%2Eapplikation%2Egv%2Eat%2Fcb
Der Parameter grant_type spezifiziert den Typ der Autorisierung (in diesem Beispiel
mittels Authorization Token), code gibt den Wert des Authorization Tokens direkt an,
und redirect_uri definiert nochmals die Rücksprung-URL.
5.3.4 Access Token Response (Schritt 9)
Eine beispielhafte Access Token Response sieht wie folgt aus:
HTTP/1.1 200 OK
Content-Type: application/json
Pragma: no-cache
{
"access_token":"SlAV32hkKG",
"token_type":"Bearer",
"expires_in":3600,
OpenID Connect
40
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
}
Der Wert access_token enthält dabei das eigentlich Access Token, der Parameter
token_type spezifiziert den Typ des Tokens, wie z.B. in [OAuth2_Bearer] definiert, und
expires_in definiert die Gültigkeit des Tokens. Der Wert refresh_token wurde bis
jetzt noch nicht genauer erwähnt und dient zum Erneuern eines abgelaufenen Access
Tokens. Der Parameter id_token stellt ein JSON Web Token (JWT) dar und ist im Prinzip
ein Security Token, welches Claims über die Authentifizierung beinhaltet (z.B.
Identifikator
der
Benutzerin
bzw.
des
Benutzers,
Zeit
der
Authentifzierung,
Authentifzierungs-Kontext, etc).
5.3.5 UserInfo Request (Schritt 10)
Ein beispielhafter Request, welcher ein Access Token beinhaltet, sieht wie folgt aus:
GET /userinfo HTTP/1.1
Host: moa-id.gv.at
Authorization: Bearer SlAV32hkKG
Der Parameter access_token enthält dabei das Access Token.
5.3.6 UserInfo Response (Schritt 11)
Eine beispielhafte Response der Identitätsdaten sieht wie folgt aus:
HTTP/1.1 200 OK
Pragma: no-cache
{
"sub":"12345==",
"given_name":"Max",
"family_name":,"Mustermann"
"birthdate":,"01-01-1990"
"gender":,"M"
}
Die in der Response beinhalteten Parameter und Werte enthalten dabei die
Identitätsdaten der Bürgerin bzw. des Bürgers. OpenID Connect hat teilweise AttributNamen schon vordefiniert, wie z.B. die im Beispiel dargestellten Namen. Der Wert sub
enthält üblicherweise den Identifikator der Benutzerin bzw. des Benutzers und könnte
somit das bPK aufnehmen.
5.4 Diskussion
Dieser Abschnitt beinhaltet eine Diskussion von OpenID Connect 1.0 anhand der zuvor
Diskussion
Transfer von Identitäts- Identitäts- und Authentifizierungsdaten können mittels URLund
Parameter bzw. JSON zwischen den einzelnen beteiligten
Authentifizierungsdaten Parteien ausgetauscht werden.
OpenID Connect
41
Sicherheit
Standardmäßig unterstützen OpenID Connect sowie OAuth
weder Signaturen noch Verschlüsselung. Für den sicheren
Datenaustausch setzt OpenID Connect komplett auf SSL/TLS.
Weitere Möglichkeiten, die Sicherheit von OpenID Connect zu
erhöhen, wäre die Verwendung von JSON Web Tokens (JWT)
[JWT], welche Signaturen und Verschlüsselung anbieten. Beide
Spezifikationen sind aber derzeit noch im Draft-Status.
Einfache
Erweiterbarkeit
OpenID Connect ist so wie OAuth ein Rahmenwerk und nicht
nur ein spezifisches Protokoll. Somit erlaubt es ebenfalls viel
Raum für eigene Spezifizierungen und Erweiterungen. Es
existieren bereits einzelne Draft-Spezifikationen für die
Erweiterung von OpenID Connect, wie z.B. für das Signieren
oder Verschlüsseln von Daten, IdP-Discovery, oder Logout.
SSO-Funktionalität wird von OpenID Connect selbst nicht
konkret spezifiziert. Aufgrund der Verwendung desselben
Authorization Servers für mehrere Clients kann aber SSO über
diese Clients erreicht werden.
Single Logout (SLO)
Für Single Logout existiert eine eigene Draft-Spezifikation
[OIDCon_Session].
Benutzerinnen
bzw. OpenID Connect gibt Möglichkeiten vor, wie Benutzerinnen
Benutzer-Zustimmung
bzw. Benutzer zu einer Daten-Übertragung zustimmen können.
(User Consent)
Organisatorisches
Kriterium
Format
Identifikators
Diskussion
des Nach OpenID Connect muss der Identifikator ein case-sensitive
String mit max. 255 ASCII Zeichen sein. Er muss beim
Authorization Server eindeutig sein.
Format/Name weiterer OpenID Connect definiert für weitere Attribute wie z.B. Name,
Attribute
Geburtsdatum, etc. deren Name und Format.
Verbreitungsgrad
Nachdem die Spezifikation von OpenID Connect derzeit immer
noch im Draft-Status ist, existieren vorerst nur vereinzelt
Implementierungen. Google z.B. bietet schon eine Möglichkeit
zur OpenID Connect Authentifizierung.
Open-Source
Bibliotheken
Einzelne Open Source-Implementierungen stehen bereits zur
Verfügung.
Interoperabilität
Derzeit ist es noch schwer eine Aussage zur Interoperabilität zu
treffen, da sich die Spezifikation noch im Draft-Status befindet
OpenID Connect
42
und Änderungen zu erwarten sind. OSIS7 (Open Source Identity
Systems) testet jedoch bereits die Interoperabilität von
aktuellen Implementierungen.
Metadaten
Metadaten-Dateien werden von OpenID Connect nicht direkt
unterstützt, jedoch werden Metadaten der Applikation in einer
entsprechenden Erweiterung zu OpenID Connect spezifiziert
[OIDCon_Reg].
Die Erweiterung von OpenID Connect zur dynamischen ClientRegistrierung [OIDCon_Reg] beschreibt, welche Daten für eine
Applikations-Registrierung notwendig sind.
Diskussion
Austausch-Format
OpenID
Connect
verwendet
wie
OAuth
für
den
Datenaustausch einfache HTTP-Nachrichten, welche auch
JSON-Objekte beinhalten können.
Bindings
Für die Übertragung von OpenID Connect-Nachrichten stehen
unterschiedliche Möglichkeiten des HTTP-Protokolls zur
Verfügung, wie z.B. GET oder POST. Prinzipiell wird sowohl Frontals auch Back-Channel-Kommunikation verwendet.
Transfer-Protokoll
OpenID Connect
Transferprotokoll.
Token-Größe
Nachdem nur HTTP-Parameter bzw. JSON-Objekte wie bei
OAuth verwendet werden, ist die Token-Größe ebenfalls
gering. Das Token aus dem Beispiel aus Abschnitt 5.3.6 hat
beispielsweise 121 Byte.
unterstützt
nur
HTTP
über
SSL/TLS
als
Auswahl
des Eine Erweiterung von OpenID Connect erlaubt die Aufsuche
von Identity Providern. [OIDCon_Disc]
(IdP Disvocery)
Die Applikations-Authentifizierung erfolgt wie bei OAuth, z.B.
mittels Client-Identifier.
OpenID
Connect
Authentifizierung.
unterstützt
nur
eine
SP-initiierte
5.5 Fazit
Die folgende Tabelle 5 listet Stärken und Schwächen von OpenID Connect.
7
http://osis.idcommons.net/wiki/Main_Page
OpenID Connect
43
Tabelle 5 - Stärken und Schwächen von OpenID Connect
Stärken
Schwächen
Unterstützung Authentifizierung
Spezifikation noch Draft-Status
Leichtgewichtig, da HTTP und JSON
Wenig Implementierungen
Gute Integration mit mobilen Clients
Keine IdP-initiierte Authentifzierung
Erhöhte Sicherheit durch
Verwendung von JWT
mögliche Fehlende Erfahrungswerte
Im Gegensatz zur reinen Verwendung von OAuth setzt OpenID Connect nur auf OAuth
auf und verwendet das Protokoll zur Authentifzierung und nicht zur Autorisierung. Wie
OAuth selbst ist OpenID Connect leichtgewichtig, da nur HTTP-Werte bzw. JSON-Token
ausgetauscht werden. Es ergibt sich somit eine einfachere Verwendung in mobilen
Clients. Durch die Verwendung von JWT kann auch die Sicherheit entsprechend erhöht
werden.
Wesentlicher Nachteil von OpenID Connect ist der Umstand, dass sich die Spezifikation
immer noch im Draft-Status befindet und somit fehlende Erfahrungswerte gegeben sind.
Aus diesem Grund fehlen auch noch die entsprechenden Implementierungen zu
OpenID Connect.
Zusammenfassend kann aber gesagt werden, dass OpenID Connect ein viel
versprechender Standard für die Zukunft ist, da er auf OAuth aufsetzt und zu SAML eine
leichtgewichtige Alternative bietet.
OpenID Connect
44
6 OpenID
OpenID8 ist aktuell in der Version 2.0 spezifiziert, dessen Spezifikation bereits im Jahr 2007
verabschiedet wurde. Generell ist OpenID ein dezentrales Authentifizierungssystem, um
die Authentifizierung über Web-basierte Dienste zu vereinfachen.
Das Grundprinzip von OpenID basiert auf einer URL-basierten Identität, welche von
einem OpenID Provider, welcher einem Identity Provider entspricht, zur Verfügung
gestellt wird. Bei Bekanntgabe dieser Identität bzw. dieses Identifikators bei einer
Applikation wird die Benutzerin bzw. der Benutzer zum jeweiligen OpenID Provider zur
Authentifizierung weitergeleitet. Der Ort bzw. Endpunkt des OpenID Providers kann
dabei aus dem bekanntgegebenen Identifikator extrahiert werden. Anschließend
authentifiziert
(üblicherweise
sich
mit
die
Benutzerin
bzw.
Benutzername
und
der
Benutzer
Passwort)
beim
und
die
OpenID
Provider
Identitäts-
und
Authentifizierungsdaten werden an die Online Applikation (Relying Party) übertragen.
Möchte die Benutzerin bzw. der Bürger sich bei einer anderen Online Applikation über
denselben OpenID Provider anmelden, so ist nur die Bekanntgabe des Identifikators
nötig, und eine Anmeldung erfolgt ohne erneute Authentifizierung, was einem Single
Sign-On entspricht.
Wesentliches Merkmal des OpenID-Konzept ist, dass aufgrund der Dezentralisierung
und der Open Source-Lizenzen jede Nutzerin bzw. jeder Nutzer seinen eigenen OpenID
Provider aufsetzen und für eine Authentifizierung nutzen kann. Die Spezifikation ist auch
dahingehend so gestaltet, dass zusätzliche Services leicht auf diese Spezifikation
aufgesetzt werden können. Nachdem die OpenID-Spezifikation schon vor einiger Zeit
verabschiedet wurde, wird OpenID auch bereits recht breit eingesetzt. So gab es nach
dem Bericht von Kissel [OpenID_Rev] aus dem Jahre 2009 damals bereits 9 Millionen
Websites, die OpenID nutzen, und 1 Milliarde aktivierte Accounts.
Bürgerkartenauthentifizierung unter Verwendung von OpenID 2.0. Die explizite
Verwendung von OpenID zur Bürgerkartenauthentifizierung bedarf aber noch einer
genaueren Analyse des Protokolls bzw. eine etwaige Profilierung.
8
http://openid.net/
OpenID
45
Abbildung 8 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von OpenID 2.0
2. Um sich bei der Online Applikation anmelden zu können, muss die Bürgerin bzw.
der Bürger ihren bzw. seinen OpenID Identifikator z.B. in eine Login-Maske
eingeben. Die Bürgerin bzw. der Bürger kann dabei aussuchen, welchen
Identifikator sie bzw. er verwenden will und somit, bei welchem OpenID Provider
sie bzw. er sich authentifizieren möchte.
3. Die
Online
Applikation
(Relying
Party)
verwendet
den
eingegebenen
Identifikator zum Auffinden des OpenID Providers der Bürgerin bzw. des Bürgers.
4. Die Online Applikation stellt einen direkten Request zum OpenID Provider zum
Aushandeln einer sogenannten Association, was der Generierung eines
gemeinsamen Secrets dient. Dieses Secret wird in weiterer Folge zum Signieren
und Verifizieren von OpenID Authentication Messages verwendet.
OpenID
46
5. Der OpenID Provider antwortet mit entsprechenden Secret-Informationen.
6. Die Online Applikation sendet einen OpenID Authentication Request via HTTPRedirect an den OpenID Provider. In diesem Beispiel wird weiters angenommen,
dass die OpenID Attribute Exchange Extension [OpenID_AX] verwendet wird,
sodass später neben dem Identifikator noch mehrere Attribute ausgetauscht
werden können.
Signatur angefragt.
9. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOAID erfolgreich überprüft werden konnten, wird eine OpenID Assertion von MOAID generiert, welche die Identitätsdaten und Authentifizierungsdaten beinhaltet.
11. MOA-ID übermittelt die erstellte Assertion wiederum mittels HTTP-Redirect an die
Online Applikation.
12. Die Gültigkeit der Assertion wird von der Online Applikation überprüft.
6.2 Beispiel
6.2.1 OpenID Authentication Request (Schritt 6)
In diesem Schritt übermittelt die Online Applikation einen OpenID Authentication
Request an MOA-ID. Ein Request sieht beispielsweise wie folgt aus:
GET /moa-id.gv.at/accounts/o8/ud?
openid.assoc_handle=1.AMlYA9VMPYAFT
&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select
&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select
&openid.mode=checkid_setup
&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
&openid.return_to=http%3A%2F%2Fonline.applikation.gv.at
&openid.ns.ax=http://openid.net/srv/ax/1.0
&openid.ax.mode=fetch_request
&openid.ax.type.fname=http://example.com/schema/fullname
OpenID
47
HTTP/1.1
Die HTTP-Parameter haben dabei die folgende Bedeutung:
openid.assoc_handle: Ein Identifikator für das zuvor ausgetauschte Secret zum
Signieren von Nachrichten.
openid.claimed_id und openid.identity: In dem Beispiel wird angegeben, dass
der OpenID Provider einen Identifikator für die Benutzerin bzw. den Benutzer wählen soll.
openid.mode: Gibt den Mode an, in diesem Fall, dass die Benutzerin bzw. der Benutzer
mit dem OpenID Provider interagieren kann.
openid.ns: Der Namespace, der diese Version der Spezifikation repräsentiert.
openid.return_to: Rücksprung-URL der Online Applikation nach Authentifizierung.
openid.ns.ax: Namespace für die Attribute Exchange Extension
openid.ax.mode: Gibt den Mode an, dass Attribut-Daten vom OpenID Provider
abgefragt werden.
openid.ax.type.fname: Gibt an, dass der Name der Benutzerin bzw. des Benutzers
abgefragt wird.
6.2.2 OpenID Authentication Response (Schritt 7)
http://online.applikation.gv.at/openid_finish?
&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
&openid.mode=id_res
&openid.op_endpoint=https%3A%2F%2Fmoa-id.gv.at%2Faccounts%2Fo8%2Fud
&openid.response_nonce=2013-08-23T15%3A56%3A58Zzeh9h37pFQHkMg
&openid.return_to=http%3A%2F% online.applikation.gv.at
&openid.assoc_handle=1.AMlYA9VMPYAFT
&openid.signed=op_endpoint%2Cclaimed_id%2Cidentity%2Creturn_to%2Cresponse_nonce%2
Cassoc_handle
&openid.sig=y8jJ5Je2YlEekXYcKxRCubYP19E%3D
&openid.identity=12345==
&openid.claimed_id=12345==
openid.ax.mode=fetch_response
openid.ax.type.fname=http://example.com/schema/fullname
openid.ax.value.fname=Max Mustermann
Die HTTP-Parameter haben dabei die folgende Bedeutung:
openid.ns: Der Namespace, der diese Version der Spezifikation repräsentiert.
openid.mode: Ist laut Spezifikation auf „id_res“ festgelegt.
openid.op_endpoint: Der Endpoint des OpendID Providers.
openid.response_nonce: String, welcher einzigartig für diese Response ist.
OpenID
48
openid.return_to: Rücksprung-URL der Online Applikation, muss mit jener im Request
übereinstimmen.
openid.assoc_handle: Ein Identifikator für das zuvor ausgetauschte Secret, welches
zum Signieren der Nachrichten verwendet wurde.
openid.signed: Liste der Parameter, welche signiert wurden.
openid.sig: Signatur-Wert in Base64-Kodierung.
openid.identity: Der Identifikator des OpenID Providers.
openid.claimed_id: Der Identifikator der Benutzerin bzw. des Benutzers nach
erfolgreicher Authentifzierung. Im Falle einer Bürgerkartenauthentifzierung das bPK.
openid.ax.mode: Gibt den Mode des Attribute Exchange an, in diesem Fall, dass
Attribute angefragt wurden.
openid.ax.type.fname: Gibt den Typ des übermittelten Attributs an, in diesem Fall der
Name der Benutzerin bzw. des Benutzers.
openid.ax.value.fname: Der Attributwert, der übertragen wird. In diesem Fall der
Name der Benutzerin bzw. des Benutzers.
6.3 Diskussion
Dieser Abschnitt beinhaltet eine Diskussion von OpenID 2.0 anhand der zuvor
Diskussion
Transfer von Identitäts- Identitäts- und Authentifizierungsdaten werden mittels
und
einfacher URL-Paramter zwischen den einzelnen beteiligten
Authentifizierungsdaten Parteien ausgetauscht werden. Die Hauptspezifikation definiert
nur den Austausch eines Identifikators, die Erweiterung mittels
Attribute Exchange Spezifikation [OpenID_AX] ermöglicht auch
den Austausch mehrerer Attribute.
Sicherheit
OpenID 2.0 setzt nicht standardmäßig auf SSL/TLS zur
Absicherung
der
Nachrichtenübertragungen,
eine
Verwendung wird nur empfohlen. Wird SSL/TLS nicht verwendet,
ist OpenID anfällig gegen Phishing-Attacken. Optional bietet
OpenID die Möglichkeit, ausgetauschte Nachrichten zu
signieren. Details dazu sind in [OpenID_Auth] spezifiziert.
[OpenID_Auth]
beschreibt
auch
eine
Reihe
von
Sicherheitsbetrachtungen zur Vermeidung von Angriffen.
Einfache
Erweiterbarkeit
Die Spezifikation besteht bereits aus mehreren Teilen, die unter
anderem Erweiterungen zur Kernspezifikation [OpenID_Auth]
beinhalten.
Die
Möglichkeit
zur
Definition
eigener
OpenID
49
Erweiterungen ist einfach gegeben, da auch in der
Kernspezifikation die entsprechende Vorgangsweise für eine
Erweiterung gegeben ist.
SSO-Funktionalität wird von OpenID selbst nicht konkret
spezifiziert. Aufgrund der Verwendung desselben OpenID
Providers für mehrere Applikationen kann aber SSO über diese
Applikationen erreicht werden.
Single Logout (SLO)
Single Logout wird von OpenID 2.0 nicht unterstützt.
Benutzerinnen
bzw. Möglichkeiten zur Benutzerinnen- bzw. Benutzerzustimmung
Benutzer-Zustimmung
werden in OpenID nicht explizit festgelegt. Die Online
(User Consent)
Applikation kann aber in ihrem Request festlegen, ob die
Benutzerin bzw. der Benutzer mit dem OpenID Provider
interagieren kann.
Organisatorisches
Kriterium
Format
Identifikators
Diskussion
des Prinzipiell gibt die OpenID Spezifikation das Format des
Identifikators vor. Der Identifikator ist entweder eine URL oder
ein XRI (Extensible Resource Identifier) [XRI]. Bei Verwendung
von gewissen Parametern im Authentifizierungsrequest kann
jedoch festgelegt werden, dass der OpenID Provider einen
entsprechenden Identifikator für die Benutzerin bzw. den
Benutzer auswählen soll.
Format/Name weiterer Die Kernspezifikation von OpenID definiert nur eine Anmeldung
Attribute
mittels Identifikator. Die Attribute Exchange Erweiterung
[OpenID_AX] hingegen definiert eigene Namespaces sowie
Attributenamen für gängige persönliche Attribute.
Verbreitungsgrad
Die OpenID 2.0 Spezifikation ist bereits im finalen Status seit
2007. Nach [OpenID_Rev] gab es im Jahr 2009 über 9 Millionen
Websites, die OpenID integriert hatten. Große Provider wie z.B.
Google bieten auch eine Schnittstelle zur OpenIDAuthentifzierung an.
Open-Source
Bibliotheken
Für OpenID 2.0 existieren eine Reihe von Bibliotheken, darunter
auch zahlreiche in Open Source. Bibliotheken stehen dabei in
unterschiedlichen Programmiersprachen zur Verfügung, eine
Liste ist unter [OpenID_Lib] abrufbar.
Interoperabilität
Zu OpenID 2.0 gibt es keine offiziellen Conformance Tests auf
Interoperabilität. Das openid-test Project9 hat jedoch das Ziel,
Interoperabilitätstests zwischen beliebigen OpenID Bibliotheken
9
http://code.google.com/p/openid-test/
OpenID
50
durchzuführen. Zusätzlich gibt es aus vergangenen Jahren eine
Interoperabilitätsmatrix von OSIS [OSIS_I3].
Metadaten
Eine Metadaten-Spezifikation ist in OpenID nicht notwendig, da
z.B. der OpenID Provider und dessen Endpunkt über den von
der Benutzerin bzw. den Benutzer eingegeben Identifier
ermittelt wird.
Applikationen müssen sich nicht explizit beim OpenID Provider
registrieren. Durch die Eingabe des OpenID Identifikators bei
Authentifizierungsbeginn wird der gewünschte OpenID Provider
ausgewählt, es ist daher keine vorherige Registrierung zwischen
Service Provider und OpenID Provider notwendig.
Diskussion
Austausch-Format
OpenID verwendet
Datenaustausch.
einfache
URL-Parameter
für
den
Bindings
OpenID unterstützt nur den Datenaustausch via http und einem
Front-Channel-Binding.
Transfer-Protokoll
OpenID unterstützt nur den Datenaustausch via HTTP.
Token-Größe
Nachdem nur URL-Parameter ausgetauscht werden, ist die
Token-Größe gegenüber XML-basierten Lösungen ebenfalls
geringer. Die URL aus dem Beispiel aus Abschnitt 6.2.2 hat
beispielsweise 682 Byte.
Auswahl
des Das Auffinden des Identity Providers ist ein Kernbestandteil des
OpenID Protokolls und dessen Spezifikation. Ein beispielsweise
(IdP Disvocery)
von OpenID verwendetes Protokoll ist Yadis [Yadis].
Nachdem keine Applikations-Registrierung notwendig ist, ist
auch keine Applikations-Authentifizierung notwendig. OpenID
Provider können jedoch die Authentizität einer Applikation
überprüfen, indem die im Request enthaltene Return-URL mit
Hilfe eines Relying Party-Discovery Services auf dessen Existenz
geprüft wird.
OpenID unterstützt nur eine SP-initiierte Authentifizierung.
OpenID
51
6.4 Fazit
Die folgende Tabelle 6 listet Stärken und Schwächen von OpenID.
Tabelle 6 - Stärken und Schwächen von OpenID
Stärken
Schwächen
Weit verbreitet
Keine IdP-initiierte Authentifzierung
Leichtgewichtig, da URL-Parameter
Trotz
weiter
Verbreitung
gewünschte Akzeptanz
Viele Implementierungen
Notwendige Sicherheit nicht Out-of-the-Box
spezifiziert
nicht
die
Keine aktuellen Interop-Tests
Keine explizite Applikations-Registrierung bzw.
-Authentifizierung
Die eklatanteste Stärke einer Verwendung von OpenID ist zweifelsohne dessen weite
Verbreitung. Es existieren auch zahlreiche Implementierungen in unterschiedlichen
Programmiersprachen. Vorteil gegenüber XML-basierten Protokollen ist hier, dass nur
URL-Parameter zur Übertragung von Daten verwendet werden.
Obwohl OpenID bereits weit verbreitet ist, genießt es nicht die gewünschte Akzeptanz
sowohl bei Benutzerinnen bzw. Benutzern als auch bei Service Providern. Notwendige
Sicherheitsmechanismen
sind
nicht
Out-of-the-Box
spezifiziert
und
müssen
entsprechend vor deren Verwendung angepasst werden. Aus diesem Grund ist für eine
Verwendung in MOA-ID noch eine genauere Analyse und eine darauffolgende
Anpassung notwendig. Ein Nachteil ist auch, dass der standard-mäßige Identifikator
dem DNS-Format folgt.
OpenID
52
7 CAS
Das Central Authentication Service (CAS)10 wurde ursprünglich von der Yale Universität
entwickelt, später jedoch von Jasig (Java Architectures Special Interest Group) 11
übernommen. Wie auch die meisten der anderen zuvor vorgestellten Protokolle zielt
CAS auf die Verwendung von Single Sign-On über mehrere Online Applikationen ab.
Die Funktionalität von SSO ist im Wesentlichen in der Protokollversion 1.0 [CAS_Prot]
spezifiziert, die Version 2.0 spezifiziert Proxy-Authentifizierung über mehrere Ebenen. CAS
2.0 ist jedoch völlig rückwärtskompatibel zu CAS 1.0. Nachdem Proxy-Authentifizierung
im Rahmen von MOA-ID keine Rolle spielt, wird in diesem Dokument nur die CAS
Version 1.0 genauer betrachtet, welche im Jahr 2005 final veröffentlicht wurde.
Bürgerkartenauthentifizierung unter Verwendung von CAS 1.0 [CAS_Arch]. [TZZ+10]
beschreiben bereits eine Implementierung auf CAS 1.0 unter Verwendung von MOA-ID
und der existierenden SAML 1.0 Schnittstelle. In dieser Implementierung wird der CASServer um ein Authentifizierungsplugin erweitert, welches die Kommunikation mit MOAID
und
somit
auch
die
österreischische
Bürgerkarte
unterstützt.
In
dieser
Implementierung wird aber in weiterer Folge davon ausgegangen, dass ein Mapping
zwischen dem bPK der Bürgerin bzw. des Bürgers auf einen Benutzernamen, welcher
beim Service Provider zur Identifizierung benötigt wird, erfolgt. Diese Vorgehensweise
entspricht im Wesentlichen einer Authentifizierung mittels MOA-ID Proxy.
In dem in Abbildung 9 dargestellten Authentifizierungsablauf wird aber davon
ausgegangen, dass das CAS-Protokoll insofern erweitert bzw. profiliert werden kann,
dass anstatt eines Benutzernamens auch mehrere Daten der Benutzerin bzw. Benutzers
übertragen werden können.
10
11
http://www.jasig.org/cas/
http://www.jasig.org
CAS
53
Abbildung 9 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von CAS 1.0
1. Eine Bürgerin bzw. ein Bürger möchte auf eine geschützte Webseite der OnlineApplikation zugreifen. Die Online Applikation bettet dabei eine URL zur
Authentifizierung ein, die direkt auf den CAS Server MOA-ID zeigt.
2. Mit Klicken auf diese URL wird der Authentifizierungsprozess bei MOA-ID gestartet.
Dabei werden MOA-ID entsprechende Parameter wie z.B. der staatliche
Tätigkeitsbereich bzw. die URL der Online-Applikation, an die die Bürgerin bzw.
der Bürger nach erfolgreicher Authentifizierung umgeleitet werden soll,
übergeben.
3. Die beiden Prozessschritte 3 und 4 sind nur schematisch dargestellt und Details
wurden ausgespart, da sie für das eigentliche Identitätsprotokoll zwischen MOAID und der Online-Applikation von keiner Relevanz sind. Im Wesentlichen wird im
Schritt 3 von MOA-ID bei der Bürgerkartenumgebung die Personenbindung der
Signatur angefragt.
ausgelesen Personenbindung als auch die erstellte qualifizierte Signatur an
5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOAID erfolgreich überprüft werden konnten, wird ein sogenanntes Ticket erstellt,
CAS
54
welches einer langen, zufälligen Zahl entspricht. Dieses Ticket ist der zuvor
erfolgreich authentifizierten Person zugeordnet.
6. In diesem Schritt wird die Bürgerin bzw. der Bürger an die Online Applikation
zurückgeleitet. Die URL dieser Weiterleitung enthält dabei das Ticket. Die
Weiterleitung erfolgt dabei über die Bürgerkartenumgebung
7. Die Bürgerin bzw. der Bürger wird an die Online Applikation weitergeleitet.
8. Die Online Applikation extrahiert das mitgelieferte Ticket und sendet dieses via
HTTP Request an MOA-ID.
9. MOA-ID extrahiert das Ticket und überprüft die Existenz und Gültigkeit dieses
Tickets
10. MOA-ID holt die zum Ticket gehörigen Daten der Bürgern bzw. des Bürgers aus
dem internen Speicher. Die Daten der Bürgerin bzw. des Bürgers werden als
HTTP- Response an die Online Applikation übertragen.
11. Basierend auf diesen Daten kann die Online Applikation den Zugriff auf die
Applikation gewähren.
7.2 Beispiel
7.2.1 CAS Authentication Request (Schritt 2)
Die Authentifizierung beim CAS Server MOA-ID erfolgt dabei über den Aufruf einer
einfachen URL. Nachdem MOA-ID direkt aufgerufen wird, handelt es sich um eine IdPinitiierte Authentifizierung. Diese aufgerufene URL sieht beispielsweise folgendermaßen
aus:
https://moa-id.gv.at/cas/login?service=http://onlineapplikation.gv.at
Der Parameter service gibt die URL der Online Applikation, an die die Bürgerin bzw.
der Bürger nach einer erfolgreichen Authentifizierung zurückgeleitet werden soll. Wie
bei der Verwendung von SAML 1.0 , kann es nötig sein, dass CAS-Protokoll zu erweitern,
um z.B. Parameter zur Übermittlung des staatlichen Tätigkeitsbereichs zu übertragen.
7.2.2 Redirect with ticket (Schritt 6 und 7)
In diesem Schritt wird die Bürgerin bzw. der Bürger nach erfolgreicher Authentifizierung
an die Online Applikation umgeleitet. Der Redirect enthält ein sogenanntes Ticket
ticket.
http://online-applikation.gv.at?ticket=ST-123456789
CAS
55
Im Schritt 8 wird das Ticket via HTTP-Request Parameter von der Online Applikation an
MOA-ID übertragen. Dieser Request sieht beispielsweise wie folgt aus:
https://moa-id.gv.at/cas/validate?
service= http://online-applikation.gv.at
&ticket=ST-123456789
Die Parameter service und ticket enthalten die Werte wie zuvor beschrieben.
Die Response auf den Authentifizierungsrequest aus Schritt 8 ist vollkommen
unstrukturiert und enthält ein yes oder no, welche angeben, ob die Authentifizierung
erfolgreich oder nicht war. In der Originalversion von CAS 1.0 wird hier noch zusätzlich
nur der Benutzername übergeben, mit dem sich die Benutzerin bzw. der Benutzer am
CAS-Server angemeldet hat. Damit hier mehrere Daten übertragen werden können,
muss eine entsprechende Vereinbarung sowie erweiterte Spezifikation zwischen MOAID und der Online Applikation getroffen werden. In dem folgenden Beispiel wird davon
ausgegangen, dass mehrere Daten der Benutzerin bzw. des Benutzers übertragen
werden können.
yes
bpk1234==
Max
Mustermann
7.3 Diskussion
Dieser Abschnitt beinhaltet eine Diskussion von CAS 1.0 anhand der zuvor
Diskussion
Transfer von Identitäts- Identitäts- und Authentifizierungsdaten werden mittels
und
einfacher URL- bzw. HTTP-Parameter zwischen den einzelnen
Authentifizierungsdaten beteiligten Parteien ausgetauscht. Die CAS Spezifikation
definiert im Wesentlichen nur den Austausch zweier Attribute,
einem boolschen Wert, ob die Authentifizierung erfolgreich war
oder nicht, und dem Benutzernamen, welcher bei der
Authentifizierung verwendet wurde.
Sicherheit
CAS
In der CAS Spezifikation wird von einer notewendigen
Verwendung von SSL/TLS für den sicheren Datenaustausch
nichts erwähnt. Der einzige Sicherheitsmechanismus ist im
Wesentlichen neben der eigentlichen Benutzerauthentifizierung
die Validierung des Tickets.
56
Einfache
Erweiterbarkeit
Die explizite Möglichkeit zur Erweiterung ist in der CAS
Spezifikation nicht festgeschrieben. Prinzipiell spricht aber nichts
dagegen, die Spezifikation durch Hinzufügen von Parametern
zu erweitern und so beispielsweise zu ermöglichen, dass
mehrere Benutzerinnen-Daten bzw. Benutzerdaten übertragen
werden können. Erweitert kann aber einfach der eigentliche
Authentifizierungsprozess werden. Hier gibt es unter anderem
schon unterschiedliche Plugins z.B. für Active Directory, LDAP,
Radius, etc. [Jasig_Wiki]
Ein wesentlicher Grund der Entwicklung von CAS war SSO. SSO
wird mit Hilfe eines Browser-Cookies (sogenanntes TicketGranting-Cookie) erreicht.
Single Logout (SLO)
Single Logout wird von CAS unterstützt. Es werden dabei aber
nicht alle Online Applikationen benachrichtigt, sondern nur die
Sitzung beim CAS Server beendet.
Benutzerinnen
bzw. Die Möglichkeit zur Benutzerinnen- bzw. Benutzerzustimmung ist
Benutzer-Zustimmung
nur insofern gegeben, dass optional im Protokoll festgelegt
(User Consent)
werden kann, ob eine Benutzerin bzw. ein Benutzer aktiv einer
SSO-Anmeldung zustimmen soll.
Organisatorisches
Kriterium
Format
Identifikators
Diskussion
des Als Identifikator wird im Standard-CAS-Protokoll eine
Benutzername (NetID) verwendet. Das Format dieses
Benutzernamens wird aber nicht spezifiziert.
Format/Name weiterer Die Kernspezifikation sieht keine Übetragung weiterer Attribute
Attribute
außer dem Benutzernamen vor.
Verbreitungsgrad
CAS existiert seit 2005 und wird hauptsächlich im universitären
Bereich zur Vernetzung eingesetzt. Im Jahr 2006 existierten über
100 Universitäten von dieser Implementierung [Wiki_CAS].
Nebenbei setzt auch die Europäische Kommission auf dieses
Protokoll (ECAS).
Open-Source
Bibliotheken
CAS wird von Jasig als Open Source zur Verfügung gestellt. Die
Server-Komponente ist in Java implementiert, ClientBibliotheken stehen in Java, .Net, Perl, etc. zur Verfügung
[CAS].
Interoperabilität
Da sowohl CAS Server als auch zahlreiche Client-Libraries von
Jasig angeboten werden, sollten bei deren Verwendung keine
Interoperabilitätsprobleme auftreten.
Metadaten
CAS spezifiziert keine Metadaten.
CAS
57
Wie Applikationen am CAS Server registriert werden, wird in der
Spezifikation nicht beschrieben.
Diskussion
Austausch-Format
OpenID verwendet einfache URL- bzw. HTTP-Parameter für den
Datenaustausch.
Bindings
CAS unterstützt nur den Datenaustausch via HTTP, es wird aber
sowohl für Front-Channel als auch für Back-ChannelKommunikation eingesetzt.
Transfer-Protokoll
CAS unterstützt nur den Datenaustausch via HTTP.
Token-Größe
Bei CAS werden nur URL-Parameter für den Datenaustauch
verwendet, die Token-Größe aus Abschnitt 7.2.4 ist 35 Byte
Auswahl
des IdP Discovery wird von CAS nicht unterstützt. Die Applikation
legt mittels URL bereits den gewünschten Identity Provider fest.
(IdP Disvocery)
Die Authentifizierung von Applikationen am CAS Server erfolgt
mittels
Rücksprung-URL,
an
die
nach
erfolgreicher
Authentifizierung umgeleitet wird.
CAS unterstützt nur eine IdP-initiierte Authentifizierung.
7.4 Fazit
Die folgende Tabelle 7 listet Stärken und Schwächen von CAS 1.0.
Tabelle 7 - Stärken und Schwächen von CAS 1.0
Stärken
Schwächen
Eingermaßen stark verbreitet
Nur IdP-initiierte Authentifzierung
Leichtgewichtig, da URL-Parameter
Keine explizite Applikations-Registrierung
Viele
Implementierungen
Authentifizierungsplugins
Einfache Spezifikation
bzw. Notwendige Sicherheit nicht Out-of-the-Box
spezifiziert
Übertragene
limitiert.
Daten
auf
Benutzername
Einfaches Protokoll
Single Logout spezifiziert
CAS
58
Das Central Authentication Service ist relativ – speziell im universitären Umfeld – weit
verbreitet.
Es
existieren
zahlreiche
Implementierungen
in
unterschiedlichen
Programmiersprachen. Wesentlichster Vorteil ist vermutlich, dass die Spezifikation und
das dazugehörige Protokoll sehr einfach gehalten und somit leicht zu implementieren
ist. Durch die Verwendung von URL-Parametern zur Datenübertragung ist es auch sehr
leichtgewichtig.
Aufgrund der Einfachheit des Protokolls sind die Anwendungsfälle auch limitiert. So sind
die übertragenen Daten in der Spezifikation auf einen Benutzernamen beschränkt.
Sollen mehrere Attribute übertragen werden, so muss die Spezifikation enstprechend
erweitert werden. Außerdem ist die Sicherheit des Protokolls limitiert, da z.B. weder
Signaturen noch Verschlüsselung unterstützt wird.
CAS ist zwar ein einfach zu implementierendes Protokoll aber aufgrund der
mangelnden Sicherheitsmechanismen Out-of-the-Box und ohne Erweiterung oder
Anpassung der Spezifikation (z.B. zwingende Verwendung von SSL/TLS) nicht für einen
Einsatz in MOA-ID geeignet.
CAS
59
8 WS-Federation
WS-Federation [WS-Fed] in der aktuellen Version 1.2 aus dem Jahre 2009 ist Teil der WS-*
Spezifikation, welche ein Framework für den sicheren Austausch von Web ServiceNachrichten bereitstellt. WS-Federation erweitert dabei WS-Trust um die Möglichkeit
einer flexiblen föderierten Identitätsmanagement-Architektur. Dabei wird das in WS-*
durchgängig verwendete Modell eines Security Token Services (STS) um die
Anforderungen für ein Identitäsmanagement erweitert, sodass diese Spezifikation
sowohl von Web Services als auch von Web Browsern verwendet werden kann. Die WSFederation Spezifikation beschreibt dabei Vertrauensverhältnisse, das Format von
auszutauschenden Security Tokens, und Protokolle für deren Transfer.
WS-* bzw. WS-Federation zielt generell auf den sicheren Austausch von Web ServiceNachrichten über unterschiedliche Domains bzw. Bereiche ab. Die Verwendung eines
Web Browsers (Passive Requestor) als Client ist eher ein Sonderfall. Vom generellen
Aufbau ist WS-Federation ähnlich zu SAML, da es z.B. einerseits auch auf XML und SOAP
aufsetzt, und andererseits für bestimmte Anwendungsfälle standardisierte Profile
definiert
werden.
Der
für
MOA-ID
notwendige
Anwendungsfall
des
sicheren
Datenaustauschs, wobei einer Bürgerin bzw. ein Bürger über einen Web Browser agiert,
wird im WS-Federation Passive Requestor Profile [WS-Fed] abgebildet. Dieses Profil bildet
auch die Basis für die weitere Beschreibung in den folgenden Unterabschnitten.
In diesem Unterabschnitt wird ein typischer Authentifizierungsablauf zwischen Resource
Provider (Online Applikation) und Security Token Service/Identity Provider (MOA-ID) auf
Basis von WS-Federation skizziert. Details in der Kommunikation zwischen MOA-ID und
der Bürgerkartenumgebung werden dabei wiederum nicht dargestellt. Abbildung 10
skizziert dabei einen Authentifizierungsablauf auf Basis von WS-Federation. In WSFederation wird nicht streng in Bindings unterschieden wie bei SAML, deswegen wird
auch bei der weiteren Beschreibung keine besondere Unterscheidung getroffen.
Nachrichten können dabei unter Verwendung von HTTP Redirects (HTTP GET) oder
mittels HTTP POST übertragen werden.
WS-Federation
60
Abbildung 10 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von WS-Federation
2. Die Online Applikation übermittelt einen Security Token Request via Redirect und
URL-Parameter an den affiliierten Identity Provider (MOA-ID).
Signatur angefragt.
5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOAID erfolgreich überprüft werden konnten, wird eine Security Token von MOA-ID
generiert. Das Security Token ist im Regelfall eine SAML Assertion (siehe Abschnitt
2 bzw. 3), die die Identitätsdaten der Bürgerin bzw. des Bürgers enthält.
Bürgerkartenumgebung nochmals auf den Identity Provider umgeleitet, um
wieder dort den Fokus des Browsers zu erhalten.
WS-Federation
61
7. Das
Security
Token
(<wst:RequestSecurityTokenResponse>
inkl.
SAML
Assertion) wird üblicherweise aufgrund dessen Größe mittels HTTP POST an den
Service Provider übermittelt.
8.2 Beispiel
Dieser Unterabschnitt zeigt Beispiele für Request- und Response-Nachrichten im
gezeigten Szenario.
Der Request zum Starten einer Authentifizierung wird dabei im dargestellten Szenario
vom Resource Provider an MOA-ID mittels HTTP-Redirect übermittelt.
https://moa-id.gv.at?
wa=wsignin1.0
&wtrealm=online-applikation.gv.at
&wsreply=https://online-applikation.gv.at
Der Parameter wa gibt dabei an, dass es sich um einen Login-Request handelt, und der
Parameter wtrealm definiert dabei den Bereich bzw. Domain des Resource Providers,
um diesen beim Security Token Service identifizieren zu können. Der Parameter
wsreply gibt die Rücksprung-URL des Resource Providers an.
Im dargestellten Szenario wird das Security Token mittels HTTP-POST von MOA-ID an den
Resource Provider übertragen.
Der Parameter wa gibt wiederum die Art der
Kommunikation an und wresult enthält dabei das Security Token.
https://online-applikation.gv.at?
wa=wsignin1.0
&wresult=<wst:RequestSecurityTokenResponse>…</wst:RequestSecurityToken
Response>
Eine beispielhaftes Security Token sieht folgendermaßen aus. Das Security Token enthält
im Wesentlichen nur eine SAML Assertion der Version 1.1 oder 2.0. In diesem Beispiel
wird daher der Inhalt der SAML Assertion nur angedeutet und für Details auf den
Abschnitt 3.3.2 verwiesen.
<wst:RequestSecurityTokenResponse xmlns:wst=" http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_44cd6604c7a58fff4f5df402310902ad" IssueInstant="2013-08-13T14:18:15.647Z" Version="2.0">
…
</saml2:Assertion>
</wst:RequestSecurityTokenResponse>
WS-Federation
62
8.3 Diskussion
Dieser Abschnitt beinhaltet eine Diskussion von WS-Federation anhand der zuvor
Diskussion
und
gemäß XML-Schema der WS-Federation- und WS-TrustAuthentifizierungsdaten Spezifikation strukturiert werden. Zahlreiche Use Cases können
damit abgebildet werden.
Sicherheit
WS-Federation bietet die Möglichkeit Security Tokens mit XML
Signaturen zu versehen und bei Bedarf auch zu verschlüsseln.
Für die Absicherung der Transport-Kanäle schreibt WSFederation die Verwendung von SSL/TLS vor. Artifact/Cookies
bei der Verwendung von SSO sollten verschlüsselt werden.
Vorallem hat [Groß05] das Passive Requester Profile überprüft
und formal bewiesen, dass es kryptographisch sicher ist.
Einfache
Erweiterbarkeit
Die Autoren der WS-Federation Spezifikation erwarten sich
sogar die Definition neuer Profile, damit neue Anwendungsfälle
abgedeckt werden können [WS-Fed]. Weiters besitzen die XMLSchema-Spezifikationen
einfache
Möglichkeiten
und
Mechanismen der Erweiterung auf Nachrichtenebene.
WS-Federation unterstützt SSO über Domängrenzen. Nach [WSFed] können Artifacts/Cookies dafür verwendet werden.
Single Logout (SLO)
WS-Federation unterstützt SLO sowohl am Identity Provider als
auch bei den einzelnen Resource Providern.
Benutzerinnen
bzw. WS-Federation sieht die Möglichkeit einer
Benutzer-Zustimmung
Benutzerinnen- bzw. Benutzerzustimmung vor.
(User Consent)
optionalen
Organisatorisches
Kriterium
Format
Identifikators
Diskussion
des WS-Federation verwendet den allgemeinen Ausdruck
„Claims“ für übertragene Werte wie Identifikatoren oder
Attribute. Als Identifikatoren sind beispielsweise die E-mail
Adresse oder ein „Common Name“ spezifiziert.
Format/Name weiterer WS-Federation spezifiziert weitere Claims, wie z.B. Group. Die
Attribute
Spezifikation erlaubt aber auch die Definition eigener Claims.
Verbreitungsgrad
WS-Federation
Speziell Anbieter im Microsoft und IBM-Umfeld, welche
wesentlich an der Entwicklung der WS-Federation –Spezifikation
63
beteiligt waren, bieten entsprechende Implementierungen der
seit 2009 existierenden Spezifikation an. Besonders in der .NETWelt ist WS-Federation weiter verbreitet [Höll10], erreicht im
Allgemeinen aber nicht den Verbreitungsgrad von SAML
[SecTank].
Open-Source
Bibliotheken
Die Anzahl von Open Source-Bibliotheken ist überschaubar,
meist sind WS-Federation-Implementierungen als zusätzliche
Unterstützung bei SAML-Implementierungen zu finden. Beispiele
für Open Source Implementierungen sind: SourceID 12 , ZXID 13 ,
Open-WSFed11 14 , und Apache CXF Fediz 15 . Einige der
Implementierungen unterstützen jedoch nur die ältere WSFederation Version 1.1.
Interoperabilität
Minimale Anforderungen zur Unterstützung der Interoperabilität
von Implementierungen werden in der Spezifikation (z.B. zum
Passsive Requestor Profile) festgeschrieben.
Namhafte Unternehmen wie z.B. Microsoft oder IBM haben
Interoperability Tests auf Basis von OASIS spezifizierten Interop
Szenarien [WS-Fed-Interop] durchgeführt.
Metadaten
WS-Federation unterstützt eigene
entsprechend spezifiziert sind.
Metadaten,
die
auch
Applikationen bzw. Resource Provider werden beim Identity
Provider über den Austausch von Metadaten registriert.
Diskussion
Austausch-Format
WS-Federation basiert
ausgetauschten Daten.
auf
XML
und
somit
auch
die
Bindings
WS-Federation unterscheidet nicht direkt zwischen Bindings. Es
besteht aber die Möglichkeit, Nachrichten via HTTP GET oder
HTTP POST über Front-Channel zu übertragen.
Transfer-Protokoll
WS-Federation bietet nur HTTP als Transportprotokoll an.
Token-Größe
WS-Federation ist XML-basiert und daher ist die Token-Größe
dementsprechend groß. Das Beispiel-Token aus Abschnitt 8.2.2
hat ca. 3,3 KByte.
Auswahl
des WS-Federation bietet in seiner Spezifikation die Möglichkeit zum
Auffinden bzw. zur Auswahl eines Identity Providers.
http://www.sourceid.org/
http://www.zxid.org/
14 http://code.google.com/p/open-wsfed11/
15 http://cxf.apache.org/fediz.html
12
13
WS-Federation
64
(IdP Disvocery)
Applikationen werden über ihre zuvor konfigurierten
Metadaten und eine im Request enhaltene Reply-URL beim
Identity Provider authentifiziert.
WS-Federation unterstützt nur eine SP-initiierte Authentifizierung.
8.4 Fazit
Die folgende Tabelle 8 listet Stärken und Schwächen von WS-Federation.
Tabelle 8 - Stärken und Schwächen von WS-Federation
Stärken
Schwächen
Unterstützung zahlreicher Use Cases
„Schwergewichtig“, da XML-basierend
Metadaten-Spezifikation
Profile
müssen
meist
konkretisiert werden.
IdP-Discovery
Umfangreiche Spezifikation
trotzdem
noch
Schlechte Integration mit mobilen Clients
Geringe Verbreitung
Wenige Implementierungen
WS-Federation ist ein sehr umfangreicher Standard der auf den Spezifikationen von WSTrust setzt. Dadurch lassen sich sehr gut zahlreiche Anwendungsfälle abbilden.
Der große Umfang der Spezifikation ist aber auch ein Nachteil, da Profile meist trotzdem
noch konkretisiert werden müssen. WS-Federation hat nicht den Verbreitungsgrad wie
SAML, somit gibt es auch nur vereinzelt Implementierungen. Nachdem WS-Federation
auch auf XML basiert, sind die übertragenen Nachrichten um einiges größer als bei
Protokollen, die nur auf z.B. reine URL-Parameter setzen.
WS-Federation ähnelt sehr stark der Spezifikation von SAML und verwendet teilweise
sogar SAML, hat aber nicht den selben Verbreitungsgrad. Ein Einsatz in MOA-ID wäre
denkbar, doch dürfte sich die Anzahl der Service Provider, die WS-Federation
implementieren, in Grenzen halten.
WS-Federation
65
9 Weitere Protkolle
Dieser Abschnitt enthält weitere Protokolle, die sich unter Umständen für einen Einsatz in
MOA-ID eignen könnten, aber im Rahmen dieses Projekts nicht detaillierter analysiert
wurden.
9.1 STORK
STORK (Secure Identity Across Borders Linked) 16 beschreibt im Wesentlichen ein
Framework für den sicheren Austausch von Identitäts- und Authentifizierungsdaten über
Landesgrenzen hinweg in Europa. Für den Austausch der Daten setzt das STORKProtokoll auf den etablierten Standard SAML 2.0. SAML 2.0 wurde dabei auf die
Anforderungen von STORK angepasst und entsprechend profiliert. Nachdem aber
STORK so wie PVP 2.x beide auf SAML 2.0 aufbauen, wurde im Rahmen dieser Arbeit
auf eine detaillierte Analyse verzichtet.
9.2 Mozilla Persona
Mozilla Persona17 basiert auf dem BrowserID-Protkoll und ist ein von Mozilla propagierter
Standard. Wesentliches Merkmal ist, dass Mozilla Persona speziell auf die Verwendung
von E-Mail-Adressen als Identifikator und Passwort-Authentifzierungen abzielt. Dadurch
ist es für einen Einsatz im Kontext von MOA-ID nicht unbedingt geeignet. Aus diesem
Grund wird ebenfalls auf eine genauere Analyse im Rahmen dieses Projekts verzichtet.
16
17
http://eid-stork.eu/
http://www.mozilla.org/en-US/persona
Weitere Protkolle
66
10 Vergleich
Im Rahmen dieses Abschnitts werden die einzelnen Protokolle untereinander anhand
der ausgewählten Kriterien verglichen. Die Bewertung erfolgt jeweils anhand einer
enstsprechenden Bewertungsskala, deren Bewertungskriterien bzw. Legende nun wie
folgt beschrieben werden. Es wird bei der Bewertung jeweils von existierenden
Spezifikationen bzw. der Standard-Spezifikation ausgegangen. Einige Eigenschaften
lassen sich bei einzelnen Protokollen durchaus verbessern, sofern die Spezifikation
profiliert bzw. entsprechend erweitert wird.
X
...
L, M, H ...
Kriterium wird unterstützt
L (Low), M (Medium), H (High)
10.1 Bewertungsschemata
Die weiteren Unterabschnitte enthalten die entsprechenden Bewertungsschemata für
die einzelnen Kriterien.
10.1.1 Bewertungsschema Funktionale Kriterien
Kriterium
Bewertung
Transfer von Identitäts- X ... Der Transfer von Identitäts- und Authentifizierungsdaten
und
wird unterstützt.
Authentifizierungsdaten
Sicherheit
Sicherheitsvorkehrungen (Verwendung
etc.) sind in der Spezifikation
SSL/TLS,
Signaturen,
L ... Nicht vorgeschrieben
M ... Optional vorhanden
H ... Verpflichtend vorgeschrieben
Einfache
Erweiterbarkeit
Erweiterbarkeit der Spezifikation ist
L ... Nicht vorgesehen
M ... Möglich
H ... Ausdrücklich erwünscht
X ... Single Sign-On wird unterstützt.
Single Logout (SLO)
X ... Single Logout wird unterstützt.
Benutzerinnen
bzw. Die Zustimmung von Benutzerinnen bzw. Benutzern ist
Benutzer-Zustimmung
L ... Nicht möglich
(User Consent)
M ... Optional möglich
H ... Verpflichtend
Vergleich
67
10.1.2 Bewertungsschema Organisatorische Kriterien
Kriterium
Format
Identifikators
Bewertung
des Das Format des Identifikators ist
L … Nicht vorgegeben
M … Teilweise vorgegeben
H … Fix vorgegeben
Format/Name weiterer Das Format/Name weiterer Attribute ist
Attribute
L … Nicht vorgegeben
M … Teilweise vorgegeben
H … Fix vorgegeben
Verbreitungsgrad
Die Spezifikation ist
L ... Wenig verbreitet
M ... Vereinzelt verbreitet
H ... Weit verbreitet
Open-Source
Bibliotheken
Open Source Bibliotheken sind
L … Nicht vorhanden
M … Vereinzelt vorhanden
H … In mehreren Programmiersprachen vorhanden
Interoperabilität
X ... Die Interoperabilität wird getestet.
Metadaten
X… Metadaten sind spezifiziert.
Applikations-Registrierung ist
L … Nicht notwendig
M … Nicht genau spezifziert
H … Spezifiziert
10.1.3 Bewertungsschema Technische Kriterien
Kriterium
Bewertung
Austausch-Format
Das Austausch-Format wird qualitativ angegeben.
Bindings
Mögliche Bindings werden qualitativ angegeben.
Transfer-Protokoll
Mögliche Trasnfer-Protokolle werden qualitativ angegeben.
Token-Größe
Ungefähre Token-Größen werden quantitativ angegeben.
Auswahl
des X ... Die Auswahl des Identitätsdienstleisters (IdP Disvocery) wird
Vergleich
68
(IdP Disvocery)
unterstützt.
Applikations-Authentifizierung ist
L … Nicht notwendig
M … Nicht genau spezifziert
H … Spezifiziert
Das Protokoll unterstützt folgende Arten der AuthentifizierungInitiierung:
SP … SP-initiiert
IdP … IdP-initiiert
10.2 Vergleich anhand der Kriterien
Die folgenden Unterabschnitte enthalten den Vergleich bzw. die Bewertung der
einzelnen Identitätsprotokolle.
10.2.1 Vergleich anhand funktionaler Kriterien
Protokoll
SAML
1.0
SAML
2.0
OAuth 2.0
OpenID
Connect
OpenI
D 2.0
CAS 1.0
WSFederati
on 1.2
Transfer
von
Identitäts- und
Authentifizierun
gsdaten
X
X
X
X
X
X
X
Sicherheit
L
H
M
H
M
L
H
Einfache
Erweiterbarkeit
H
H
H
H
H
M
H
Single
(SSO)
Sign-On
X
X
X
X
X
X
X
Single
(SLO)
Logout
X
X
M
M
/
Kriterium
Benutzerinnen
bzw. BenutzerZustimmung
(User Consent)
X
L
M
M
M
M
Funktional eignen sich alle Protokolle für einen Einsatz in MOA-ID, aufgrund der
Sicherheit sind jedoch SAML 2.0, OpenID Connect bzw. WS-Federation bei Verwendung
der
jeweiligen
Out-of-the-Box-Spezifikation
zu
bevorzugen.
Bei
entsprechender
Profilierung oder Erweiterung kann auch bei den anderen Protokollen ein höheres
Vergleich
69
Sicheheitsmaß erreicht werden. Alle Protokolle sind einfach erweiterbar, außer CAS, wo
eine Erweiterung des Protokolls nicht unbedingt vorgesehen ist. SSO wird auch von
allen Protokollen explizit bzw. implizit unterstützt, SLO jedoch nur von SAML 2.0, CAS, und
WS-Federation. Eine Benutzerinnen- bzw. Benutzer-Zustimmung ist bei den meisten
Protokollen optional möglich, außer bei SAML 1.0, wo dies nicht vorgesehen ist.
10.2.2 Vergleich anhand organisatorischer Kriterien
Protokoll
SAML
1.0
SAML
2.0
OAuth 2.0
OpenID
Connect
OpenI
D 2.0
CAS 1.0
WSFederati
on 1.2
Format
des
Identifikators
M
M
L
M
M
M
M
Format/Name
weiterer
Attribute
L
L
L
M
H
L
M
Verbreitungsgra
d
L
H
H
L
H
M
L
Open-Source
Bibliotheken
M
H
H
L
H
H
M
/
Kriterium
Interoperabilität
X
Metadaten
X
M
H
X
X
X
M
H
L
M
H
Das Format des Identifikators ist bis auf OAuth bei allen Protokollen zum Teil
vorgegeben. OAuth zielt aber speziell auf Autorisierung ab, und daher ist das Format
ziemlich offen, weil die übertragenen Daten nicht unbedingt Identitätsdaten sein
müssen. Formate oder Namen von weiteren Attributen ist zumeist offen gestaltet, nur
OpenID Connect, OpenID, und WS-Federation spezifizieren neben Identifikatoren auch
weitere Attribute genauer. Der Verbreitungsgrad ist bei SAML 2.0, OAuth, und OpenID
hoch. SAML 1.0 ist bereits veraltet, OpenID Connect erst noch im Draft-Status, CAS
hauptsächlich im universitären Umfeld zu finden, und WS-Federation hat sich nicht
wirklich durchgesetzt. Der Verbreitungsgrad spiegelt sich daher auch ein wenig bei der
Verfügbarkeit von Open Source-Bibliotheken nieder, so existieren bei den gängigen
Protokollen auch meist Implementierungen in unterschiedlichen Programmiersprachen.
Die Interoperabilität zwischen Implementierungen wird nur bei vereinzelten Protokollen
explizit getestet, nämlich bei SAML 2.0, OpenID, und WS-Federation. Metadaten sind
überhaupt nur bei zwei Protokollen spezifiziert, nämlich bei den aktuelleren XML-
Vergleich
70
basierten Protokollen SAML 2.0 und WS-Federation. Dies spiegelt sich auch in der
Spezifzierung der Applikations-Registrierung wider, welche neben SAML 2.0 und WSFederation auch bei OpenID Connect explizit spezifiziert ist. Bei den anderen
Protokollen ist entweder keine Registrierung notwendig (OpenID) bzw. ist diese nicht
genau spezifiziert (SAML 1.0, OAuth, CAS).
10.2.3 Vergleich anhand technischer Kriterien
Protokoll
/
SAML
1.0
SAML
2.0
OAuth 2.0
OpenID
Connect
OpenI
D 2.0
XML
CAS 1.0
XML
URLParameter,
JSON
URLParameter,
JSON
URLParamete
r
URLParameter
XML
SOAP,
HTTPRedirect,
HTTP-POST
SOAP,
HTTPRedirec
t, HTTPPOST,
etc.
URLParameter
(GET und
POST)
URLParameter
(GET und
POST)
URLParamete
r
URLParameter
URLParameter
(GET und
POST)
HTTP,
SOAP
HTTP,
SOAP
HTTP
HTTP
HTTP
HTTP
HTTP
3,14 KB
5,7KB
77 Byte
121 Byte
682
Byte
35 Byte
3,3 KB
X
X
Kriterium
AustauschFormat
Bindings
TransferProtokoll
Token-Größe
Auswahl
des
Identitätsdienstl
eisters
(IdP
Disvocery)
X
WSFederati
on 1.2
X
ApplikationsAuthentifizierun
g
H
H
M
M
L
H
H
SP-initiiert/IdPinitiiert
IdP
SP,
IDP
SP
SP
SP
IdP
SP
Das Austauschformat ist bei SAML 1.0, 2.0 und WS-Federation XML, während bei den
anderen Protokollen nur URL-Parameter bzw. bei OAuth und OpenID Connect auch
noch zusätzlich JSON eingesetzt wird. Dies spiegelt sich auch in der Größe der jeweils
übertragenen Daten wider, wo zu Schwankungen zwischen einigen Bytes bis zu einigen
KBytes kommen kann. Beim Transferprotokoll kommt im Wesentlichen nur HTTP zum
Einsatz, SOAP wird nur bei SAML noch verwendet. Bei den Bindings sind sowohl Front- als
auch Back-Channel-Bindings im Einsatz, rein Front-Channel wird nur bei OpenID und
WS-Federation verwendet. Die Auswahl des Identity Providers ist nur bei SAML 2.0,
OpenID Connect, OpenID, und WS-Federation möglich, wobei diese Funktionalität bei
Vergleich
71
OpenID zum Standard-Protokoll gehört. Eine Applikations-Authentifizierung ist bei den
meisten Protokollen spezifiziert, bei OAuth bzw. OpenID Connect ist dies nicht genau
geregelt, OpenID benötigt nicht unbedingt eine Authentifizierung der Applikation.
Vergleich
72
11 Zusammenfassung
Viele Identitätsprotokolle haben sich bereits über die letzten Jahre für einen sicheren
Austausch von Identitäts- und Authentifizierungsinformationen etabliert, einige sind
gerade erst dabei den Markt zu erobern. Im Rahmen dieses Projekts wurden
unterschiedliche Identitätsprotokolle auf deren Eignung für einen Einsatz im Rahmen
von
MOA-ID
untersucht
und
anhand
unterschiedlicher
Kriterien
(funktional,
organisatorisch, technisch) miteinander verglichen.
Von den analysierten Protokollen eignen sich besonders SAML 2.0 bzw. OpenID
Connect für einen Einsatz in MOA-ID. SAML 2.0 wird bereits in PVP 2.x verwendet und
hat aufgrund der Veröffentlichung der Spezifikation im Jahr 2005 eine weite
Verbreitung. SAML ist sehr mächtig und es können unterschiedliche Anwendungsfälle
abgebildet werden. Aufgrund der möglichen Verwendung von Signaturen bzw.
Verschlüsselung ist auch ein hohes Maß an Sicherheit gegeben.
Eine leichtgewichtigere Alternative zu SAML 2.0, die nicht auf XML sondern auf URLParameter und JSON setzt, ist OpenID Connect. OpenID Connect setzt auf OAuth auf,
welches ebenfalls bereits weit verbreitet eingesetzt wird. Vorteil von OpenID Connect
gegenüber OAuth ist jedoch, dass OpenID Connect das Ziel der Authentifizierung und
nicht der Autorisierung besitzt. Entsprechende Sicherheitsmechanismen sind gegeben,
da bei entsprechender Erweiterung auch Signaturen und Verschlüsselung eingesetzt
werden kann. OpenID Connect ist jedoch derzeit nur im Draft-Status, womit mit einer
weiteren Verbreitung erst in Zukunft zu rechnen ist. Aufgrund dessen weiter Verbreitung
ist auch OpenID 2.0 eine Alternative, dessen Verwendbarkeit jedoch noch einer
genaueren Analyse bedarf.
Bei den weiteren Protokollen könnte zwar WS-Federation 1.2 im Rahmen von MOA-ID
Verwendung finden, die geringe Verbreitung von WS-Federation lassen jedoch an
deren Einsatztauglichkeit zweifeln. Eine Verwendung von CAS 1.0 wäre rein technisch
bei entsprechender Erweiterung auch möglich, jedoch ist aufgrund geringerer
Sicherheitsvorkehrungen im Standard-Protokoll von einer Verwendung abzuraten.
Zusammenfassung
73
Dokumentenhistorie
Version
Datum
Autor(en)
Anmerkung
0.1
10.04.2013
Bernd
Zwattendorfer
Grobstruktur,
Protokolle
0.2
24.04.2013
Bernd
Zwattendorfer
Auswahl der Kriterien
0.3
06.08.2013
Bernd
Zwattendorfer
SAML 1.0, SAML 2.0
0.4
27.08.2013
Bernd
Zwattendorfer
OAuth, OpenID Connect, OpenID
0.5
03.09.2013
Bernd
Zwattendorfer
CAS, WS-Federation
0.6
20.09.2013
Bernd
Zwattendorfer
Finalisierung vollständiger Draft
0.7
24.09.2013
Arne Tauber
Kommentare
1.0
26.09.2013
Bernd
Zwattendorfer
Finalisierung
Zusammenfassung
Auswahl
der
74
Referenzen
[CAS]
Jasig: CAS, http://www.jasig.org/cas
[CAS_Arch]
Jasig: CAS 1 Architecture, 2009, http://www.jasig.org/cas/cas1architecture
[CAS_Prot]
Jasig
(Drew
Mazurek):
http://www.jasig.org/cas/protocol
[Groß05]
T. Groβ, B. Pfitzmann, und A. Sadeghi: “Proving a WS-federation
passive requestor profile with a browser model”, Proceedings of
the 2005 Workshop on Secure Web Services 2005, pp. 54-64
[Höll10]
Thorsten
Höllrigl:
Informationskosistenz
Identitätsmanagement, 2010, Dissertation
[Internet2]
Internet2 Mailing List Service: Interoperability tests with 9 SAML
products, https://lists.internet2.edu/sympa/arc/mace-opensamlusers/2005-04/msg00007.html
[Jasig_Wiki]
Jasig
Wiki:
Authentication,
https://wiki.jasig.org/display/CASUM/Authentication
[JWT]
OAuth Working Group: JSON Web Token (JWT), Internet-Draft , Juli
2013,
http://self-issued.info/docs/draft-ietf-oauth-json-webtoken.html
[Kantara_eGov]
Kantara Initiative: eGovernment
CAS
Protocol,
im
2005,
föderativen
2009,
Implementation
Profile
of
SAML
V2.0,
Juni
2010,
http://kantarainitiative.org/confluence/download/attachments/4
2139782/kantara-egov-saml2-profile-2.0.pdf
[Kantara_IOP]
Kantara Initiative: SAML Interoperable Implementations, Tools,
Libraries
and
Services,
2010,
http://kantarainitiative.org/programs/iop-saml/
[OAuth1]
IETF:
The
OAuth
1.0
http://tools.ietf.org/html/rfc5849c
[OAuth2]
IETF: The OAuth 2.0 Authorization
http://tools.ietf.org/html/rfc6749
[OAuth2_Bearer]
IETF: The OAuth 2.0 Authorization Framework: Bearer Token Usage,
RFC 6750, http://tools.ietf.org/html/rfc6750
[OAuth2_Code]
OAuth.net: Code, http://oauth.net/code/
[OAuth_SAML]
OAuth Working Group: SAML 2.0 Profile for OAuth 2.0 Client
Authentication and Authorization Grants, Internet-Draft 17, Juli
2013, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-17
[OAuth2_SEC]
IETF: OAuth 2.0 Threat Model and Security Considerations,
RFC6819, http://tools.ietf.org/html/rfc6819
[OAuth_Wiki]
Wikipedia: OAuth, http://en.wikipedia.org/wiki/OAuth
Zusammenfassung
Protocol,
RFC
Framework,
RFC
75
5849,
6749,
[OIDCon_Disc]
OpenID Foundation: OpenID Connect Discovery 1.0, Draft 17,
http://openid.net/specs/openid-connect-discovery-1_0.html
[OIDCon_Reg]
OpenID Foundation: OpenID Connect Dynamic Client
Registration 1.0, Draft 19, http://openid.net/specs/openidconnect-registration-1_0.html
[OIDCon_Session]
OpenID Foundation: OpenID Connect Session Management 1.0,
Draft
15,
http://openid.net/specs/openid-connect-session1_0.html
[OpenID_Auth]
OpenID
Foundation:
OpenID
Authentication
http://openid.net/specs/openid-authentication-2_0.html
[OpenID_AX]
OpenID
Foundation:
OpenID
Attribute
Exchange
1.0,
http://openid.net/specs/openid-attribute-exchange-1_0.html
[OpenID_Lib]
OpenID Foundation: Libraries,
http://openid.net/developers/libraries/
[OpenID_Rev]
B. Kissel: OpenID 2009 Year in Review, Dezember
http://openid.net/2009/12/16/openid-2009-year-in-review/
[OSIS_I3]
OSIS: I3:Cross Solution OpenID Identity Provider x Relying Party
Results,
http://osis.idcommons.net/wiki/I3:Cross_Solution_OpenID_Identity_
Provider_x_Relying_Party_Results
[PVP2]
BLSG: Portalverbundprotokoll (PVP)
government.gv.at/PVP2.2761.0.html
[SAML_20]
OASIS: SAML 2.0, http://saml.xml.org/saml-specifications#samlv20
[SAML2_Overview]
OASIS: Security Assertion Markup Language
2.0,
2.0,
2009,
http://reference.e-
(SAML) V2.0 Technical Overview, März 2008
[SAML_21]
OASIS: SAML 2.1, https://wiki.oasis-open.org/security/SAML21
[SAML_Impl]
http://saml.xml.org/wiki/saml-open-source-implementations
[SAML_Kant_Impl]
Kantara Initiative: SAML Interoperable Implementations, Tools,
Libraries and Services, http://kantarainitiative.org/programs/iopsaml/
[SAML1_SEC]
OASIS: Security and Privacy Considerations for the OASIS Security
Assertion Markup Language (SAML), OASIS Standard, November
2002,
http://www.oasisopen.org/committees/download.php/2290/oasis-sstc-saml-1.0.zip
[SAML2_Bindings]
OASIS: Bindings for the OASIS Security Assertion Markup Language
(SAML) V2.0, OASIS Standard, März 2005
[SAML2_Metadata] OASIS: Metadata for the OASIS Security Assertion Markup
Language (SAML) V2.0, OASIS Standard, März 2005
[SAML2_Profiles]
OASIS: Profiles for the OASIS Security Assertion Markup Language
(SAML) V2.0, Standard, März 2005
[SAML2_SEC]
OASIS: Security and Privacy Considerations for the OASIS Security
Assertion Markup Language (SAML) V2.0, OASIS Standard, März
Zusammenfassung
76
2005
[SecTank]
Wolfram Funk: Identity Federation Standards für Cloud Services,
SecTank - Das IT-Security Blog, http://sectank.net/?p=837
[SL]
Arno Hollosi, Gregor Karlinger, Thomas Rössler, Martin Centner, et
al.:
Die
österreichische
Bürgerkarte,
Version
1.2,
http://www.buergerkarte.at/konzept/securitylayer/spezifikation/a
ktuell/
[TZZ+10]
Arne Tauber, Bernd Zwattendorfer, Thomas Zefferer, Yasmin
Mazhari, Eleftherios Chamakiotis: Towards Interoperability: An
Architecture for Pan-European eID-based Authentication
Services, Electronic Government and the Information Systems
Perspective, 2010, pp. 120-133
[Wiki_CAS]
Wikipedia:
Central
Authentication
Service,
http://en.wikipedia.org/wiki/Central_Authentication_Service
[WS-Fed]
OASIS: Web Service Federation Language (WS-Federation)
Version
1.2,
2009,
http://docs.oasisopen.org/wsfed/federation/v1.2/ws-federation.pdf
[WS-Fed-Interop]
OASIS: WSFED TC Interop Scenarios, 2007, https://www.oasisopen.org/committees/download.php/25931/WSFED-TCInteropScenarios-ED01.doc
[XRI]
OASIS: OASIS Extensible
Resource Identifier
https://www.oasisopen.org/committees/tc_home.php?wg_abbrev=xri
[Yadis]
Infogrid: Yadis, http://infogrid.org/trac/wiki/Yadis
[ZZA12]
Bernd Zwattendorfer, Thomas Zefferer, Arne Tauber: The
Prevalence of SAML within the European Union - An Empirical
Study, WEBIST 2012, pp. 571-576
Zusammenfassung
(XRI)
77
TC,

Dokumentation Identitäts-Protokolle für MOA-ID - E

Transcription

Similar documents

Titel der Arbeit - Lehrstuhl für Netz- und Datensicherheit

D okum e nta tion PDF-AS Webanwendung Dokumentation

Warum ist Social Media wichtig für die

ELGA- Gesamtarchitektur