Identitäts-Protokolle für Dokumentation MOA-ID · OAuth 2.0 ist eigentlich ein Protokoll zur Autorisierung. Es wird im Rahmen dieses Dokuments jedoch trotzdem analysiert, da es

E-Government Innovationszentrum Inffeldgasse 16/a, A-8010 Graz Tel. +43 316 873 5514 Fax. +43 316 873 5520 E-Mail [email protected] www.egiz.gv.at

Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

Dok

umen

tatio

n

Identitäts-Protokolle für MOA-ID

Version 1.0, 26.09.2013

Bernd Zwattendorfer – [email protected]

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 MOA-ID 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.

Einleitung 2

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 3

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 4


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 5

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

Abbildung 7 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von OpenID Connect 1.0 .................................................................................................................... 38

Abbildung 8 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von 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 WS-Federation ...................................................................................................................................... 61

Einleitung 6

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 7

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 8

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 E-Government 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 9

Tabelle 1- Terminologie der unterschiedlichen Identitätsprotokolle

Komponente SAML 1.0

SAML 2.0

PVP 2.X OAuth 2.0

OpenID Connect

OpenID CAS WS-Federation

Online Applikation

Service Provider

Service Provider

Client Relying Party

Web Service

Resource Provider (Relying Party)

Bürgerin bzw. Bürger

Subject Principal Resource Owner

End User User Requestor (User)

MOA-ID Identity Provider

Identity Provider

Authorization Server UND

Resource Server

OpenID Provider

Central Authentication Server

Security Token Service (Identity Provider)

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 MOA-ID 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 10

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 11

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äts- und 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.

SAML 1.0 12

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 Standard-Identitä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 13

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 Online-Applikation 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 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 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 MOA-ID 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 14

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-id-auth/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.

2.3.2 Authentifizierungsrequest (Schritt 8) 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 15

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.e-government.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 16

</saml:Assertion> </samlp:Response>

2.4 Diskussion Dieser Abschnitt beinhaltet eine Diskussion von SAML 1.0 anhand der zuvor ausgewählten Kriterien.

2.4.1 Funktionale Kriterien Funktionales Kriterium Diskussion

Transfer von Identitäts- und Authentifizierungsdaten

Identitäts- und Authentifizierungsdaten können in XML und gemäß XML-Schema der SAML-Spezifikation strukturiert werden. Zahlreiche Use Cases können damit abgebildet werden.

Sicherheit SAML 1.0 bietet zwar die Möglichkeit, einzelne SAML-Nachrichten 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 XML-Formate 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. Benutzer-Zustimmung (User Consent)

SAML 1.0 unterstützt bzw. definiert keine expliziten Elemente oder Attribute für eine Benutzer-Zustimmung bei Anmeldung.

2.4.2 Organisatorische Kriterien Organisatorisches

Kriterium Diskussion

Format des Identifikators

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 Attribute

SAML 1.0 gibt keine Attribut-Namen oder –Formate vor. Attribute müssen jedoch einem entsprechenden Namespace zugeordnet werden.

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

SAML 1.0 17

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.

Applikations-Registrierung

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.

2.4.3 Technische Kriterien 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 Back-Channel-Binding auf Basis von SOAP und zwei Front-Channel-Bindings (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 Identitätsdienstleisters (IdP Disvocery)

SAML 1.0 bietet keine Möglichkeit zum IdP-Discovery.

Applikations-Authentifizierung

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 18

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 Schwächen

Hat sich als Protokoll für MOA-ID bewährt Nur IdP-initiierte Authentifizierung

Unterstützung bereits bestehender Online Applikationen

Keine Verschlüsselung auf Nachrichten-Ebene

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 2.0 (PVP 2.x) 19

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 nur Authentifizierungsinformationen zur erfolgreich durchgeführten Authentifizierung eines Subjects, Attribute Assertions enthalten zusätzliche Attribute eines Subjects, und Authorization 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) 20

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.

3.2 Authentifizierungsablauf 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 und der Bürgerkartenumgebung werden dabei wiederum nicht dargestellt. 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) 21

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 Online-Applikation 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 Bürgerin bzw. des Bürgers ausgelesen und die Erstellung einer qualifizierten Signatur angefragt.


5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOA-ID 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) 22

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.

3.3.1 Authentifizierungsrequest (Schritt 2) 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_moaid-2.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) 23

</ds:SignedInfo> <ds:SignatureValue>GhvpD+urP2BwEaejBW3Y3dmdIKdFDR9AikVn0TAyWBg3d/+gYxBQ0JHPn/XCoHP6QQHbNHjfqf8o2wJQrvX9WD/BPJHK2wwecbzPK2cCIco5bGqhGq+LKwHPesHu10nrIfj4T8lAHX4lPiYR5OEDMXtV1SvHfWIzXEBGh/MyJtk2qAFDT4OfglneNk8hYPjcwNb8MwMME+tlR97snFMzkXI5tHSKB8LzGIPq+K2A0c06AX2LJiT8xaDscJTqqeaub4zIm6haZ1LZX0qMH2jFJVVjAfYbV2BhdSs6aseTLSp+k2rlPJqvpds8PBN26I8KYbk/bwQIZ0hSSo//f+q2cw==</ds:SignatureValue> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>nEPzKMh3TovnfBnTyv+TMYFsGep8Uil7iNbfVyfLoBfqRdeGDOk4es2qWkgB6az+kM/9Js2H06m4 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>

3.3.2 Authentifizierungsresponse (Schritt 7) 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) 24

</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>jmajoi0Ar3FL1o43CG63UJypkzjThiqvsS4bBwg9COqlrjJYjgpfDPhLlexZxoWAbTZ2o1YyF229R8/mdimiQV0UO+BqbloddbfxloD64djdgr2xDCdnoNjOvFFZaxMxcaXtOfFzgmWTWy5sDVdqfyzT6L5ezJ81slapBzjgrZvcsBCLIVetU1qDMnM4LC0jmwe+12RBOL342O+Rg40fhBTk88z/mot8KfrvbM9kFrocf5ECB8Ry8iEAupAlZJw8xiphv8lRPTxevmwpSwdNqDqiW/a3twA8NxzE0YQEi0dgsa5YZXICrUPP9iFUyV7bu86TRqdpsdzoA98NcMCFTw==</ds:SignatureValue> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>mWrWy07+hO2VoMeOHpizN3qU2cL2e3EkzAkowmG+OpsR3UpI0dvolRuzaxDPUeANfE913KPempsT 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) 25

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">Mustermann</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="BPK" Name="urn:oid:1.2.40.0.10.2.1.1.149" 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">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" 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">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 ausgewählten Kriterien.



Identitäts- und Authentifizierungsdaten können in XML und gemäß XML-Schema der SAML-Spezifikation strukturiert werden. 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 XML-Encryption 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.


Die modulare SAML-Architektur sowie die entsprechenden XML-Formate von SAML-Assertions und Protokoll-Nachrichten wurden entsprechend für einfache Erweiterbarkeit entwickelt.

Single Sign-On (SSO) 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. Benutzer-Zustimmung

SAML 2.0 unterstützt bzw. definiert explizite, aber optionale Elemente für eine Benutzer-Zustimmung bei einer Anmeldung.

SAML 2.0 (PVP 2.x) 26

(User Consent) Der Service Provider erhält dadurch Informationen, ob ein Principal bzw. wie ein Principal seine Zustimmung zur Anmeldung gegeben hat.




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.


SAML 2.0 gibt keine Attribut-Namen vor. Formate können aber 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.


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


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) 27

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.


SAML 2.0 spezifiert das sogenannte „Identity Provider Discovery Profile“ [SAML2_Profiles] zum Auffinden bzw. zur Auswahl eines 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.

SP-initiiert/IdP-initiiert SAML 2.0 unterstützt sowohl eine IdP-initiierte als auch eine SP-initiierte 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 trotzdem noch konkretisiert werden.

Modularer Aufbau Umfangreiche Spezifikation

Unterstützung zahlreicher Use Cases Schlechte Integration mit mobilen Clients

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) 28

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.

OAuth 2.0 29

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.

4.2 Authentifizierungsablauf 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 30

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.



5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOA-ID erfolgreich überprüft werden konnten, wird ein Authorization Code von MOA-ID generiert. In diesem Schritt bzw. mit der qualifizierten Signatur stimmt auch die

OAuth 2.0 31

Bürgerin bzw. der Bürger der Weitergabe der Identitätsdaten an die Online Applikation zu, was die Generierung des Authorization Codes auslöst.

6. In diesem Schritt wird die Bürgerin bzw. der Bürger vom Fokus mit der 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 Response- Nachrichten 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 32

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 Content-Type: application/x-www-form-urlencoded 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 33

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store 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 ausgewählten Kriterien.



Identitäts- und Authentifizierungsdaten können mittels URL-Parameter bzw. JSON zwischen den einzelnen beteiligten 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 Server-Authentifizierung 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.


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.

Single Sign-On (SSO) 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. Benutzer-Zustimmung

OAuth spezifiziert keine Details, wie eine Benutzerin bzw. ein Benutzer dem Datenzugriff eines Clients auf Ressourcen zugestimmt hat. Der Client erhält nur über unterschiedliche

OAuth 2.0 34

(User Consent) Bestätigungsmöglichkeiten die Information, dass die Benutzerin bzw. der Benutzer den Datenzugriff autorisiert hat.




OAuth spezifiziert kein Format für einen übertragenen Identifikator.


OAuth spezifiziert keine Attribut-Namen und lässt die Definition 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.


Für OAuth existiert ebenfalls eine Menge an Open Source-Implementierungen. 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 verwendet für den Datenaustausch einfache HTTP-

OAuth 2.0 35

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 Back-Channel-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.


OAuth 2.0 lässt ein IdP-Discovery vollkommen unspezifiziert.


Der Authorization Server ordnet jeder Applikation einen für ihn eindeutigen Identifikator zu, der für eine Applikations-Authentifizierung genutzt werden kann. Generell wird in der OAuth 2.0 Spezifikation die Art der Applikations-Authentifizierung offen gelassen, sie muss nur den festgelegten Sicherheitsanforderungen des Authorization Servers genügen.

SP-initiiert/IdP-initiiert 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 36

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.

OpenID Connect 37

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 Protokoll-Suite und die einzelnen Komponenten sind in Abbildung 6 dargestellt.

Abbildung 6 - OpenID Connect Protocol Suite

5.2 Authentifizierungsablauf Dieser Unterabschnitt skizziert einen möglichen Authentifizierungsablauf für eine Bürgerkartenauthentifizierung unter Verwendung von OpenID Connect. Der

6 http://openid.net/connect/

OpenID Connect 38

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.

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

OpenID Connect 39

Bürgerin bzw. des Bürgers ausgelesen und die Erstellung einer qualifizierten Signatur angefragt.


5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOA-ID erfolgreich überprüft werden konnten, wird ein Authorization Code von MOA-ID 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.

12. Die Online Applikation überprüft die übermittelten Identitätsdaten und gewährt oder verweigert den Zugriff auf das Service.


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 40

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) Eine beispielhafte Authorization Response sieht wie folgt aus:

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

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

Cache-Control: no-store Pragma: no-cache { "access_token":"SlAV32hkKG", "token_type":"Bearer", "expires_in":3600,

OpenID Connect 41

"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 Content-Type: application/json;charset=UTF-8 Cache-Control: no-store 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 Attribut-Namen 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 ausgewählten Kriterien.



Identitäts- und Authentifizierungsdaten können mittels URL-Parameter bzw. JSON zwischen den einzelnen beteiligten Parteien ausgetauscht werden.

OpenID Connect 42

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.


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.

Single Sign-On (SSO) 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].


OpenID Connect gibt Möglichkeiten vor, wie Benutzerinnen bzw. Benutzer zu einer Daten-Übertragung zustimmen können.




Nach OpenID Connect muss der Identifikator ein case-sensitive String mit max. 255 ASCII Zeichen sein. Er muss beim Authorization Server eindeutig sein.


OpenID Connect definiert für weitere Attribute wie z.B. Name, 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.


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 43

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 Client-Registrierung [OIDCon_Reg] beschreibt, welche Daten für eine Applikations-Registrierung notwendig sind.


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 Front- als auch Back-Channel-Kommunikation verwendet.

Transfer-Protokoll OpenID Connect unterstützt nur HTTP über SSL/TLS als 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.


Eine Erweiterung von OpenID Connect erlaubt die Aufsuche von Identity Providern. [OIDCon_Disc]


Die Applikations-Authentifizierung erfolgt wie bei OAuth, z.B. mittels Client-Identifier.

SP-initiiert/IdP-initiiert OpenID Connect unterstützt nur eine SP-initiierte Authentifizierung.

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 44

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 mögliche Verwendung von JWT

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 45

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 sich die Benutzerin bzw. der Benutzer beim OpenID Provider (üblicherweise mit Benutzername und Passwort) und die 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.

6.1 Authentifizierungsablauf Dieser Unterabschnitt skizziert einen möglichen Authentifizierungsablauf für eine 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 46

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 47

5. Der OpenID Provider antwortet mit entsprechenden Secret-Informationen. 6. Die Online Applikation sendet einen OpenID Authentication Request via HTTP-

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



9. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOA-ID erfolgreich überprüft werden konnten, wird eine OpenID Assertion von MOA-ID 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. 13. Die Online Applikation überprüft die übermittelten Identitätsdaten und gewährt

oder verweigert den Zugriff auf das Service.


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 48

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) Eine beispielhafte Authorization Response sieht wie folgt aus:

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%2Cassoc_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 49

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 ausgewählten Kriterien.



Identitäts- und Authentifizierungsdaten werden mittels einfacher URL-Paramter zwischen den einzelnen beteiligten 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.


Die Spezifikation besteht bereits aus mehreren Teilen, die unter anderem Erweiterungen zur Kernspezifikation [OpenID_Auth] beinhalten. Die Möglichkeit zur Definition eigener

OpenID 50

Erweiterungen ist einfach gegeben, da auch in der Kernspezifikation die entsprechende Vorgangsweise für eine Erweiterung gegeben ist.

Single Sign-On (SSO) 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.


Möglichkeiten zur Benutzerinnen- bzw. Benutzerzustimmung werden in OpenID nicht explizit festgelegt. Die Online Applikation kann aber in ihrem Request festlegen, ob die Benutzerin bzw. der Benutzer mit dem OpenID Provider interagieren kann.




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.


Die Kernspezifikation von OpenID definiert nur eine Anmeldung 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 OpenID-Authentifzierung an.


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 51

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.


Austausch-Format OpenID verwendet einfache URL-Parameter für den Datenaustausch.

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.


Das Auffinden des Identity Providers ist ein Kernbestandteil des OpenID Protokolls und dessen Spezifikation. Ein beispielsweise 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.

SP-initiiert/IdP-initiiert OpenID unterstützt nur eine SP-initiierte Authentifizierung.

OpenID 52

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 nicht die gewünschte Akzeptanz

Viele Implementierungen Notwendige Sicherheit nicht Out-of-the-Box spezifiziert

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.

CAS 53

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.

7.1 Authentifizierungsablauf Dieser Unterabschnitt skizziert einen möglichen Authentifizierungsablauf für eine 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 CAS-Server um ein Authentifizierungsplugin erweitert, welches die Kommunikation mit MOA-ID 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 http://www.jasig.org/cas/ 11 http://www.jasig.org

CAS 54

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 Online-Applikation 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 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 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 ausgelesen Personenbindung als auch die erstellte qualifizierte Signatur an MOA-ID übermittelt wurden.

5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOA-ID erfolgreich überprüft werden konnten, wird ein sogenanntes Ticket erstellt,

CAS 55

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.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 IdP-initiierte Authentifizierung. Diese aufgerufene URL sieht beispielsweise folgendermaßen aus:

https://moa-id.gv.at/cas/login?service=http://online-applikation.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 56

7.2.3 Authentifizierungsrequest (Schritt 8) 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.

7.2.4 Authentifizierungsresponse (Schritt 10) 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 MOA-ID 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 ausgewählten Kriterien.



Identitäts- und Authentifizierungsdaten werden mittels einfacher URL- bzw. HTTP-Parameter zwischen den einzelnen 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 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.

CAS 57


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]

Single Sign-On (SSO) Ein wesentlicher Grund der Entwicklung von CAS war SSO. SSO wird mit Hilfe eines Browser-Cookies (sogenanntes Ticket-Granting-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.


Die Möglichkeit zur Benutzerinnen- bzw. Benutzerzustimmung ist nur insofern gegeben, dass optional im Protokoll festgelegt werden kann, ob eine Benutzerin bzw. ein Benutzer aktiv einer SSO-Anmeldung zustimmen soll.




Als Identifikator wird im Standard-CAS-Protokoll eine Benutzername (NetID) verwendet. Das Format dieses Benutzernamens wird aber nicht spezifiziert.


Die Kernspezifikation sieht keine Übetragung weiterer 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).


CAS wird von Jasig als Open Source zur Verfügung gestellt. Die Server-Komponente ist in Java implementiert, Client-Bibliotheken 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 58


Wie Applikationen am CAS Server registriert werden, wird in der Spezifikation nicht beschrieben.


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-Channel-Kommunikation 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


IdP Discovery wird von CAS nicht unterstützt. Die Applikation legt mittels URL bereits den gewünschten Identity Provider fest.


Die Authentifizierung von Applikationen am CAS Server erfolgt mittels Rücksprung-URL, an die nach erfolgreicher Authentifizierung umgeleitet wird.

SP-initiiert/IdP-initiiert 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 bzw. Authentifizierungsplugins

Notwendige Sicherheit nicht Out-of-the-Box spezifiziert

Einfache Spezifikation Übertragene Daten auf Benutzername limitiert.

Einfaches Protokoll

Single Logout spezifiziert

CAS 59

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.

WS-Federation 60

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 Service-Nachrichten 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 WS-Federation 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 Service-Nachrichten ü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.

8.1 Authentifizierungsablauf 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 WS-Federation 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 61

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



5. Nachdem sowohl Personenbindung als auch die qualifizierte Signatur von MOA-ID 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.

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.

WS-Federation 62

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.

8.2.1 Authentifizierungsrequest (Schritt 2) 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.

8.2.2 Authentifizierungsresponse (Schritt 7) 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:RequestSecurityTokenResponse>

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 63

8.3 Diskussion Dieser Abschnitt beinhaltet eine Diskussion von WS-Federation anhand der zuvor ausgewählten Kriterien.



Identitäts- und Authentifizierungsdaten können in XML und gemäß XML-Schema der WS-Federation- und WS-Trust-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 WS-Federation 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.


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 XML-Schema-Spezifikationen einfache Möglichkeiten und Mechanismen der Erweiterung auf Nachrichtenebene.

Single Sign-On (SSO) WS-Federation unterstützt SSO über Domängrenzen. Nach [WS-Fed] 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.


WS-Federation sieht die Möglichkeit einer optionalen Benutzerinnen- bzw. Benutzerzustimmung vor.




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.


WS-Federation spezifiziert weitere Claims, wie z.B. Group. Die Spezifikation erlaubt aber auch die Definition eigener Claims.

Verbreitungsgrad Speziell Anbieter im Microsoft und IBM-Umfeld, welche wesentlich an der Entwicklung der WS-Federation –Spezifikation

WS-Federation 64

beteiligt waren, bieten entsprechende Implementierungen der seit 2009 existierenden Spezifikation an. Besonders in der .NET-Welt ist WS-Federation weiter verbreitet [Höll10], erreicht im Allgemeinen aber nicht den Verbreitungsgrad von SAML [SecTank].


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: SourceID12, ZXID13, Open-WSFed11 14 , und Apache CXF Fediz 15 . Einige der Implementierungen unterstützen jedoch nur die ältere WS-Federation 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 Metadaten, die auch entsprechend spezifiziert sind.


Applikationen bzw. Resource Provider werden beim Identity Provider über den Austausch von Metadaten registriert.


Austausch-Format WS-Federation basiert auf XML und somit auch die ausgetauschten Daten.

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 Identitätsdienstleisters

WS-Federation bietet in seiner Spezifikation die Möglichkeit zum Auffinden bzw. zur Auswahl eines Identity Providers.

12 http://www.sourceid.org/ 13 http://www.zxid.org/ 14 http://code.google.com/p/open-wsfed11/ 15 http://cxf.apache.org/fediz.html

WS-Federation 65

(IdP Disvocery)


Applikationen werden über ihre zuvor konfigurierten Metadaten und eine im Request enhaltene Reply-URL beim Identity Provider authentifiziert.

SP-initiiert/IdP-initiiert 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 trotzdem noch konkretisiert werden.

IdP-Discovery Umfangreiche Spezifikation

Schlechte Integration mit mobilen Clients

Geringe Verbreitung

Wenige Implementierungen

WS-Federation ist ein sehr umfangreicher Standard der auf den Spezifikationen von WS-Trust 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.

Weitere Protkolle 66

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 STORK-Protokoll 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 http://eid-stork.eu/ 17 http://www.mozilla.org/en-US/persona

Vergleich 67

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 ... Kriterium wird unterstützt

L, M, H ... 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


X ... Der Transfer von Identitäts- und Authentifizierungsdaten wird unterstützt.

Sicherheit Sicherheitsvorkehrungen (Verwendung SSL/TLS, Signaturen, etc.) sind in der Spezifikation

L ... Nicht vorgeschrieben

M ... Optional vorhanden

H ... Verpflichtend vorgeschrieben


Erweiterbarkeit der Spezifikation ist

L ... Nicht vorgesehen

M ... Möglich

H ... Ausdrücklich erwünscht

Single Sign-On (SSO) X ... Single Sign-On wird unterstützt.

Single Logout (SLO) X ... Single Logout wird unterstützt.


Die Zustimmung von Benutzerinnen bzw. Benutzern ist

L ... Nicht möglich

M ... Optional möglich

H ... Verpflichtend

Vergleich 68

10.1.2 Bewertungsschema Organisatorische Kriterien Kriterium Bewertung


Das Format des Identifikators ist

L … Nicht vorgegeben

M … Teilweise vorgegeben

H … Fix vorgegeben


Das Format/Name weiterer Attribute ist

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 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 Identitätsdienstleisters

X ... Die Auswahl des Identitätsdienstleisters (IdP Disvocery) wird

Vergleich 69

(IdP Disvocery) unterstützt.


Applikations-Authentifizierung ist

L … Nicht notwendig

M … Nicht genau spezifziert

H … Spezifiziert

SP-initiiert/IdP-initiiert Das Protokoll unterstützt folgende Arten der Authentifizierung-Initiierung:

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

/ Kriterium

SAML 1.0

SAML 2.0

OAuth 2.0 OpenID Connect

OpenID 2.0

CAS 1.0 WS-Federation 1.2


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 Sign-On (SSO) X X X X X X X

Single Logout (SLO) X X X


L M M 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 70

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

/ Kriterium

SAML 1.0

SAML 2.0


OpenID 2.0


Format des Identifikators M M L M M M M


L L L M H L M

Verbreitungsgrad L H H L H M L

Open-Source Bibliotheken M H H L H H M

Interoperabilität X X X

Metadaten X X

Applikations-Registrierung M H 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 71

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 WS-Federation 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

/ Kriterium

SAML 1.0

SAML 2.0


OpenID 2.0


Austausch-Format XML XML

URL-Parameter,

JSON

URL-Parameter,

JSON

URL-Paramete

r

URL-Parameter XML

Bindings SOAP, HTTP-

Redirect, HTTP-POST

SOAP, HTTP-

Redirect, HTTP-POST, etc.

URL-Parameter (GET und

POST)


POST)

URL-Paramete

r

URL-Parameter


POST)

Transfer-Protokoll

HTTP, SOAP

HTTP, SOAP HTTP HTTP HTTP HTTP HTTP

Token-Größe 3,14 KB 5,7KB 77 Byte 121 Byte 682 Byte 35 Byte 3,3 KB


X X X X


H H M M L H H

SP-initiiert/IdP-initiiert 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 72

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.

Zusammenfassung 73

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 URL-Parameter 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 74

Dokumentenhistorie Version Datum Autor(en) Anmerkung

0.1 10.04.2013 Bernd Zwattendorfer

Grobstruktur, Auswahl der Protokolle


Auswahl der Kriterien


SAML 1.0, SAML 2.0


OAuth, OpenID Connect, OpenID


CAS, WS-Federation


Finalisierung vollständiger Draft

0.7 24.09.2013 Arne Tauber Kommentare


Finalisierung

Zusammenfassung 75

Referenzen [CAS] Jasig: CAS, http://www.jasig.org/cas

[CAS_Arch] Jasig: CAS 1 Architecture, 2009, http://www.jasig.org/cas/cas1-architecture

[CAS_Prot] Jasig (Drew Mazurek): CAS Protocol, 2005, 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 im föderativen Identitätsmanagement, 2010, Dissertation

[Internet2] Internet2 Mailing List Service: Interoperability tests with 9 SAML products, https://lists.internet2.edu/sympa/arc/mace-opensaml-users/2005-04/msg00007.html

[Jasig_Wiki] Jasig Wiki: Authentication, 2009, 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-web-token.html

[Kantara_eGov] Kantara Initiative: eGovernment

Implementation Profile of SAML V2.0, Juni 2010, http://kantarainitiative.org/confluence/download/attachments/42139782/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 Protocol, RFC 5849, http://tools.ietf.org/html/rfc5849c

[OAuth2] IETF: The OAuth 2.0 Authorization Framework, RFC 6749, 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 76

[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/openid-connect-registration-1_0.html

[OIDCon_Session] OpenID Foundation: OpenID Connect Session Management 1.0, Draft 15, http://openid.net/specs/openid-connect-session-1_0.html

[OpenID_Auth] OpenID Foundation: OpenID Authentication 2.0, 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 2009, 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) 2.0, http://reference.e-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

(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/iop-saml/

[SAML1_SEC] OASIS: Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML), OASIS Standard, November 2002, http://www.oasis-open.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 77

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/aktuell/

[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.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf

[WS-Fed-Interop] OASIS: WSFED TC Interop Scenarios, 2007, https://www.oasis-open.org/committees/download.php/25931/WSFED-TC-InteropScenarios-ED01.doc

[XRI] OASIS: OASIS Extensible Resource Identifier (XRI) TC, https://www.oasis-open.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

Documents

Identitäts-Protokolle für Dokumentation MOA-ID · OAuth 2.0 ist eigentlich ein Protokoll zur Autorisierung. Es wird im Rahmen dieses Dokuments jedoch trotzdem analysiert, da es