Identitäts-Protokolle für MOA-ID

Transkript

1 Dokumentation Identitäts-Protokolle für MOA-ID Version 1.0, Bernd Zwattendorfer 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. E-Government Innovationszentrum Inffeldgasse 16/a, A-8010 Graz Tel Fax Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 Inhaltsverzeichnis 1 Einleitung Identitätsprotokoll für MOA-ID Terminologie Vergleichskriterien Funktionale Kriterien Organisatorische Kriterien Technische Kriterien SAML Allgemeines Authentifizierungsablauf Beispiel Authentifizierungsrequest (Schritt 2) Authentifizierungsrequest (Schritt 8) Authentifizierungsresponse (Schritt 9) Diskussion Funktionale Kriterien Organisatorische Kriterien Technische Kriterien Fazit SAML 2.0 (PVP 2.x) Allgemeines Authentifizierungsablauf Beispiel Authentifizierungsrequest (Schritt 2) Authentifizierungsresponse (Schritt 7) Diskussion Funktionale Kriterien Organisatorische Kriterien Technische Kriterien Fazit Einleitung 2

3 4 OAuth Allgemeines Authentifizierungsablauf Beispiel Authorization Request (Schritt 2) Authorization Response (Schritt 7) Access Token Request (Schritt 8) Access Token Response (Schritt 9) UserInfo Request (Schritt 10) UserInfo Response (Schritt 11) Diskussion Funktionale Kriterien Organisatorische Kriterien Technische Kriterien Fazit OpenID Connect Allgemeines Authentifizierungsablauf Beispiel Authorization Request (Schritt 2) Authorization Response (Schritt 7) Access Token Request (Schritt 8) Access Token Response (Schritt 9) UserInfo Request (Schritt 10) UserInfo Response (Schritt 11) Diskussion Funktionale Kriterien Organisatorische Kriterien Technische Kriterien Fazit OpenID Einleitung 3

4 6.1 Authentifizierungsablauf Beispiel OpenID Authentication Request (Schritt 6) OpenID Authentication Response (Schritt 7) Diskussion Funktionale Kriterien Organisatorische Kriterien Technische Kriterien Fazit CAS Authentifizierungsablauf Beispiel CAS Authentication Request (Schritt 2) Redirect with ticket (Schritt 6 und 7) Authentifizierungsrequest (Schritt 8) Authentifizierungsresponse (Schritt 10) Diskussion Funktionale Kriterien Organisatorische Kriterien Technische Kriterien Fazit WS-Federation Authentifizierungsablauf Beispiel Authentifizierungsrequest (Schritt 2) Authentifizierungsresponse (Schritt 7) Diskussion Funktionale Kriterien Organisatorische Kriterien Technische Kriterien Fazit Einleitung 4

5 9 Weitere Protkolle STORK Mozilla Persona Vergleich Bewertungsschemata Bewertungsschema Funktionale Kriterien Bewertungsschema Organisatorische Kriterien Bewertungsschema Technische Kriterien Vergleich anhand der Kriterien Vergleich anhand funktionaler Kriterien Vergleich anhand organisatorischer Kriterien Vergleich anhand technischer Kriterien Zusammenfassung Abbildungsverzeichnis Abbildung 1 - Bürgerkarten-Authentifizierung mittels MOA-ID... 6 Abbildung 2 - Prozessfluss einer SAML 1-Anmeldung mittels Browser/Artifact Profile Abbildung 3 - SAML Architektur [SAML2_Overview] Abbildung 4 - Prozessfluss einer SAML 2.0-Anmeldung gemäß PVP 2.x Abbildung 5 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von OAuth Abbildung 6 - OpenID Connect Protocol Suite Abbildung 7 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von OpenID Connect Abbildung 8 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von OpenID Abbildung 9 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von CAS Abbildung 10 - Möglicher MOA-ID Authentifizierungsablauf unter Verwendung von WS- Federation Einleitung 5

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 6

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

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 8

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 Authorizati on Server UND Resource Server OpenID Provider Central Authenti cation 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 Funktionale Kriterien Dieser Abschnitt beschreibt die Kriterien für den Vergleich funktionaler Eigenschaften. Transfer von Identitäts- und Authentifizierungsdaten: Das Protokoll soll einen einfachen und strukturierten Transfer von Identitäts- und Authentifizierungsdaten zwischen MOA-ID und der Online Applikation ermöglichen. Sicherheit: Der Transfer von Identitäts- und Authentifizierungsdaten zwischen MOA-ID und der Online Applikation muss sicher erfolgen und vor Angreifern geschützt sein. Einleitung 9

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 Organisatorische Kriterien Dieser Abschnitt beschreibt die Kriterien für den Vergleich von Eigenschaften auf organisatorischer Ebene. Format des Identifikators: Hier wird verglichen, ob das Format des Identifikators vom Protokoll spezifiziert ist, oder ob auch eigene Formate für Identifikatoren verwendet werden können. Format/Name weiterer Attribute: Neben einem Identifikator werden üblicherweise noch weitere Benuterzinnen- bzw. Benutzer-spezifische Attribute übertragen. Mit diesem Kriterium wird untersucht, ob Name bzw. Format dieser Attribute durch die Spezifikation bereits fix festgelegt sind oder ob eigene Werte definiert und in die Spezifikation integriert werden können. Verbreitungsgrad: Dieses Kriterium gibt an, seit wann beispielsweise die Spezifikation zum Identitätsprotokoll bereits existiert bzw. wie häufig das entsprechende Protokoll bereits in Applikationen implementiert ist (z.b. durch welche Big Player). Open-Source Bibliotheken: Dieses Kriterium untersucht, ob zum jeweiligen Identitätsprotokoll Open-Source Bibliotheken frei zur Verfügung stehen. Interoperabilität: Dieses Kriterium checkt, ob es aufgrund von unterschiedlichen Implementierungen des Protokolls leicht zu Interoperabilitätsproblemen kommen kann bzw. ob Interoperabilitätstests zwischen Produkten/Implementierungen durchgeführt werden. Metadaten: Mit diesem Kriterium wird überprüft, ob das Identitätsprotokoll Metadaten spezifiziert. Applikations-Registrierung: Dieses Kriterium untersucht, wie Applikationen bei MOA-ID registriert werden können. Einleitung 10

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ätsund Authentifizierungsdaten ausgetauscht werden können (z.b. XML oder JSON). Bindings: Hier wird unterschieden, welche verschiedenen Austauschmöglichkeiten der Daten zwischen MOA-ID und Online Applikation auf Transportebene möglich sind. Eine Unterscheidung kann beispielsweise getroffen werden, ob die Daten über die Bürgerin bzw. den Bürger (Front-Channel) oder direkt von MOA-ID an die Online Applikation (Back-Channel) übermittelt werden. Transfer-Protokoll: Hier wird überprüft, welches unter dem Identitätsprotokoll liegende Transfer-Protokoll (z.b. SOAP oder REST) verwendet wird. Token-Größe: Mit diesem Kriterium wird die Token- bzw. Objekt-Größe der ausgetauschten Daten verglichen. Auswahl des Identitätsdienstleisters (IdP Disvocery): Dabei wird verglichen, wie entsprechende Identity Provider (z.b. MOA-ID-Zentral) aufgefunden werden können. Dies kann z.b. über Metadaten, über ein eigenes Service, etc. erfolgen. Applikations-Authentifizierung: Dieses Kriterium gibt an, wie sich Applikationen bei MOA-ID im Rahmen eines Bürgerinnen- bzw. Bürger-Authentifizierungsprozesses authentifizieren. SP-initiiert/IdP-initiiert: Dieses Kriterium gibt an, ob eine Authentifzierung zuerst bei der Online Applikation oder direkt bei MOA-ID angestoßen wird. Einleitung 11

12 2 SAML 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 OASIS 2 (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 SAML

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

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 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: 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 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=" T13:38:32+01:00" MajorVersion="1" MinorVersion="0" RequestID=" "> <samlp:assertionartifact> AAH5hs8aaZSFYHya0/cmtJ3QAR7rf54uhIsEcDMZFmmZ1/Qldrdf4JSK </samlp:assertionartifact> </samlp:request> SAML

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=" " IssueInstant=" T13:38:32+01:00" MajorVersion="1" MinorVersion="0" ResponseID=" "> <samlp:status> <samlp:statuscode Value="samlp:Success"> </samlp:statuscode> <samlp:statusmessage>anfrage erfolgreich beantwortet</samlp:statusmessage> </samlp:status> <saml:assertion xmlns:pr=" xmlns:si=" xmlns:xsi=" AssertionID=" " IssueInstant=" T13:37:30+01:00" Issuer=" 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> <saml:subjectconfirmationdata/> </saml:subjectconfirmation> </saml:subject> <saml:attribute AttributeName="PersonData" AttributeNamespace=" <saml:attributevalue> <pr:person xmlns:pr=" xmlns:xsi=" 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> </pr:dateofbirth> </pr:person> </saml:attributevalue> </saml:attribute> <saml:attribute AttributeName="isQualifiedCertificate" AttributeNamespace=" <saml:attributevalue>false</saml:attributevalue> </saml:attribute> <saml:attribute AttributeName="bkuURL" AttributeNamespace=" <saml:attributevalue> </saml:attribute> </saml:attributestatement> SAML

16 </saml:assertion> </samlp:response> 2.4 Diskussion Dieser Abschnitt beinhaltet eine Diskussion von SAML 1.0 anhand der zuvor ausgewählten Kriterien Funktionale Kriterien Funktionales Kriterium Transfer von Identitätsund Authentifizierungsdaten Diskussion 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 Single Sign-On (SSO) Single Logout (SLO) Benutzerinnen bzw. Benutzer-Zustimmung (User Consent) Die modulare Architektur sowie die entsprechenden XML- Formate von SAML-Assertions und Protokoll-Nachrichten wurden entsprechend für einfache Erweiterbarkeit entwickelt. SAML 1.0 unterstützt SSO über Domängrenzen. In SAML 1.0 wird kein SLO unterstützt. SAML 1.0 unterstützt bzw. definiert keine expliziten Elemente oder Attribute für eine Benutzer-Zustimmung bei Anmeldung Organisatorische Kriterien Organisatorisches Kriterium Diskussion Format Identifikators des SAML 1.0 spezifiziert sowohl Formate für einen Identifikator (mailaddress, X509SubjectName, WindowsDomainQualifiedName) als auch lässt es die Möglichkeit eigener Definitionen offen. Format/Name weiterer Attribute Verbreitungsgrad SAML 1.0 gibt keine Attribut-Namen oder Formate vor. Attribute müssen jedoch einem entsprechenden Namespace zugeordnet werden. 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

17 Open-Source Bibliotheken Interoperabilität Metadaten Applikations- Registrierung [SAML_Impl] listet eine Reihe von SAML Implementierungen. SAML 1.0 wird im Wesentlichen aber nur mehr von OpenSAML 3 unterstützt. Weiter verbreitet ist noch der SAML 1.0 Nachfolger in Version 1.1. Offiziell wurden keine Interoperabilitäts-Tests durchgeführt. Nach [Internet2] wurden aber unterschiedliche Produkte vereinzelt auf Interoperabilität getestet. SAML 1.0 unterstützt keine Metadaten. 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 Technische Kriterien Technisches Kriterium Austausch-Format Bindings Transfer-Protokoll Token-Größe Auswahl des Identitätsdienstleisters (IdP Disvocery) Applikations- Authentifizierung SP-initiiert/IdP-initiiert Diskussion SAML 1.0 basiert auf XML und somit auch die ausgetauschten Daten. 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). Neben HTTP wird SOAP als Transfer-Protokoll angeboten. Aufgrund der Verwendung von XML sind SAML 1.0-Tokens groß. Die SAML-Response aus Abschnitt hat beispielsweise 3,14 KByte. SAML 1.0 bietet keine Möglichkeit zum IdP-Discovery. 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. SAML 1.0 unterstützt nur eine IdP-initiierte Authentifizierung 3 SAML

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 Hat sich als Protokoll für MOA-ID bewährt Unterstützung bereits bestehender Online Applikationen Schwächen Nur IdP-initiierte Authentifizierung 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

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

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

21 Abbildung 4 - Prozessfluss einer SAML 2.0-Anmeldung gemäß PVP 2.x 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. 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. 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 von MOA-ID generiert. Die SAML Assertion enthält gemäß SAML 2.0 Spezifikation und PVP 2.x Spezifikation alle für die Online Applikation notwendigen Anmeldedaten der Bürgerin bzw. des Bürgers wie beispielsweise bpk oder Vorname und Nachname sowie allgemein Daten zum Authentifizierungsprozess. Welche Attribute von SAML 2.0 (PVP 2.x) 21

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 8. Basierend auf den Daten der SAML Assertion kann die Online Applikation den Zugriff auf die Applikation gewähren. 3.3 Beispiel Dieser Unterabschnitt zeigt Beispiele für Request- und Response Nachrichten im gezeigten Szenario 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: 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=" ID="_e1ecdd2d f8f0f489dfc49441" IssueInstant=" T14: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=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#_e1ecdd2d f8f0f489dfc49441"> <ds:transforms> <ds:transform Algorithm=" <ds:transform Algorithm=" </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue>qgqkr6stenkfs04dq6yx44cdzzo=</ds:digestvalue> </ds:reference> SAML 2.0 (PVP 2.x) 22

23 </ds:signedinfo> <ds:signaturevalue>ghvpd+urp2bweaejbw3y3dmdikdfdr9aikvn0taywbg3d/+gyxbq0jhpn/xcohp6qq HbNHjfqf8o2wJQrvX9WD/BPJHK2wwecbzPK2cCIco5bGqhGq+LKwHPesHu10nrIfj4T8lAHX4lPiYR5OEDMX tv1svhfwizxebgh/myjtk2qafdt4ofglnenk8hypjcwnb8mwmme+tlr97snfmzkxi5thskb8lzgipq+k2a0 c06ax2ljit8xadscjtqqeaub4zim6haz1lzx0qmh2jfjvvjafybv2bhdss6asetlsp+k2rlpjqvpds8pbn26i8ky bk/bwqiz0hsso//f+q2cw==</ds:signaturevalue> <ds:keyinfo> <ds:keyvalue> <ds:rsakeyvalue> <ds:modulus>nepzkmh3tovnfbntyv+tmyfsgep8uil7inbfvyflobfqrdegdok4es2qwkgb6az+km/9js2h06 m4 pjey7/rijd0lmwqgi8eqdjilmmbfqykkyyqhlzbvi8kqobcckzj5n3gy4qh8a5qn4y85q3szj23t iiiy1rphe+ztohcm6ckerso9jj409yhp1xaxfpvtiyx2ta1uuagxoml75oc/hr7gcum0tmukiseq +TO4VZw2Q7K7YESZ1WkiBoG2i4cHdcBFKnVrGNtyxl6UkjWxXRJSU9aNLs5QxsE6iFwCvFoIO+IU cvwxffhqogbrtacrub4fk+kfhe2o1dlmfwzauq==</ds:modulus> <ds:exponent>aqab</ds:exponent> </ds:rsakeyvalue> </ds:keyvalue> </ds:keyinfo> </ds:signature> <saml2:subject xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion"> <saml2:nameid>demologin-pvp2-sso/main/</saml2:nameid> </saml2:subject> <saml2p:nameidpolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/> <saml2p:requestedauthncontext> <saml2:authncontextclassref comparison= minimum xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion"> AuthnContextClassRef> </saml2p:requestedauthncontext> </saml2p:authnrequest> 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=" InResponseTo="_e1ecdd2d f8f0f489dfc49441" Version="2.0" xmlns:xs=" <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=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI=""> <ds:transforms> <ds:transform Algorithm=" <ds:transform Algorithm=" <ec:inclusivenamespaces xmlns:ec=" PrefixList="xs"/> SAML 2.0 (PVP 2.x) 23

24 </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue>fcipttsfepafyygpsiz6cbehpei=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>jmajoi0ar3fl1o43cg63ujypkzjthiqvss4bbwg9coqlrjjyjgpfdphllexzxowabtz2o1yyf 229R8/mdimiQV0UO+BqbloddbfxloD64djdgr2xDCdnoNjOvFFZaxMxcaXtOfFzgmWTWy5sDVdqfyzT6L5ezJ81 slapbzjgrzvcsbclivetu1qdmnm4lc0jmwe+12rbol342o+rg40fhbtk88z/mot8kfrvbm9kfrocf5ecb8ry8ie AupAlZJw8xiphv8lRPTxevmwpSwdNqDqiW/a3twA8NxzE0YQEi0dgsa5YZXICrUPP9iFUyV7bu86TRqdpsdzoA 98NcMCFTw==</ds:SignatureValue> <ds:keyinfo> <ds:keyvalue> <ds:rsakeyvalue> <ds:modulus>mwrwy07+ho2vomeohpizn3qu2cl2e3ekzakowmg+opsr3upi0dvolruzaxdpueanfe913kp empst 3cOKGS5IIBmxPgZM1H7EcEPVS2PYimMr1HztBMJMGAdFVFeVFsgdYP4cbwPUs03/E6kVmN7/C+vM yrpmd7i83yl8/ihchymz5ajtsrxupm0tjqqpbqbnnhvwzjcuj9z9katas/kpuum8iswk73u/gwos 3vbQLoro80xjLsSdXyJ9dVTCTwCpdP5UJPlsNLg1F7AU+OHwem76rezI0JJZhHUMg6v1xWzh8Xyc I6CizpD6RmkMXfICbFD8TR5zcNBieH/yNQeAEw==</ds:Modulus> <ds:exponent>aqab</ds:exponent> </ds:rsakeyvalue> </ds:keyvalue> </ds:keyinfo> </ds:signature> <saml2p:status> <saml2p:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </saml2p:status> <saml2:assertion xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion" ID="_44cd6604c7a58fff4f5df ad" IssueInstant=" T14: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="_e1ecdd2d f8f0f489dfc49441" NotOnOrAfter=" T14:38:15.647Z" Recipient="demologin-pvp2-sso/main/"/> </saml2:subjectconfirmation> </saml2:subject> <saml2:conditions NotBefore=" T14:18:15.647Z" NotOnOrAfter=" T14:38:15.647Z"> <saml2:audiencerestriction> <saml2:audience>demologin-pvp2-sso/main/</saml2:audience> </saml2:audiencerestriction> </saml2:conditions> <saml2:authnstatement AuthnInstant=" T14:18:15.636Z" SessionIndex="_45945f7d295bf27f8847eb81e88c09c8"> <saml2:authncontext> <saml2:authncontextclassref> </saml2:authncontext> </saml2:authnstatement> <saml2:attributestatement> <saml2:attribute FriendlyName="PVP-VERSION" Name="urn:oid: " NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:attributevalue xmlns:xsi=" xsi:type="xs:string">2.1</saml2:attributevalue> </saml2:attribute> <saml2:attribute FriendlyName="PRINCIPAL-NAME" Name="urn:oid: " SAML 2.0 (PVP 2.x) 24

25 NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:attributevalue xmlns:xsi=" xsi:type="xs:string">mustermann</saml2:attributevalue> </saml2:attribute> <saml2:attribute FriendlyName="BPK" Name="urn:oid: " NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:attributevalue xmlns:xsi=" xsi:type="xs:string">bf:fkk+zdgfnrasdfswdsns4fkt5yc=</saml2:attributevalue> </saml2:attribute> <saml2:attribute FriendlyName="EID-SECTOR-FOR-IDENTIFIER" Name="urn:oid: " NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:attributevalue xmlns:xsi=" 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 Funktionale Kriterien Funktionales Kriterium Transfer von Identitätsund Authentifizierungsdaten Sicherheit Einfache Erweiterbarkeit Single Sign-On (SSO) Single Logout (SLO) Benutzerinnen bzw. Benutzer-Zustimmung Diskussion 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. 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. SAML 2.0 unterstützt SSO über Domängrenzen. SAML 2.0 unterstützt SLO über Domängrenzen. Es wurden einzelne Protokolle und Profile dafür spezifiziert. 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) 25

26 (User Consent) Der Service Provider erhält dadurch Informationen, ob ein Principal bzw. wie ein Principal seine Zustimmung zur Anmeldung gegeben hat Organisatorische Kriterien Organisatorisches Kriterium Diskussion Format Identifikators des SAML 2.0 spezifiziert mehrere Formate für den Identifikator, z.b. ob dieser persistent oder nur temporär ausgestellt wurde. Nebenbei lässt SAML 2.0 aber auch die Möglichkeit eigener Definitionen offen. Format/Name weiterer Attribute Verbreitungsgrad Open-Source Bibliotheken Interoperabilität Metadaten Applikations- Registrierung SAML 2.0 gibt keine Attribut-Namen vor. Formate können aber beispielsweise als String oder URI definiert sein. 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. Die Kantara Initiative testete in 2010 zahlreiche Produkute auf deren Interoperabilität. Eine Liste von interoperablen Produkten kann unter [SAML_Kant_Impl] gefunden werden. 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 Technische Kriterien Technisches Kriterium Austausch-Format Bindings Diskussion SAML 2.0 basiert auf XML und somit auch die ausgetauschten Daten. SAML 2.0 unterstützt zahlreiche Bindings. Die bekanntesten und am häufigsten verwendeten Bindings sind das HTTP-Recirect-, HTTP-Post-, Artifact- und SOAP-Binding. Es existieren also sowohl Front-Channel als auch Back-Channel Bindings. Details zu SAML 2.0 (PVP 2.x) 26

27 diesen und weiteren Bindings können unter [SAML2_Bindings] gefunden werden. Transfer-Protokoll Token-Größe Auswahl des Identitätsdienstleisters (IdP Disvocery) Applikations- Authentifizierung SP-initiiert/IdP-initiiert Neben HTTP wird SOAP als Transfer-Protokoll angeboten. Aufgrund der Verwendung von XML sind SAML 2.0-Tokens ebenfalls sehr groß. Die SAML-Response aus Abschnitt 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. SAML 2.0 unterstützt sowohl eine IdP-initiierte als auch eine SPinitiierte Authentifizierung. 3.5 Fazit Die folgende Tabelle 3 listet Stärken und Schwächen von SAML 2.0 Tabelle 3 - Stärken und Schwächen von SAML 2.0 Stärken Schwächen Weit verbreitet Schwergewichtig, da XML-basierend Zahlreiche Implementierungen Profile müssen meist trotzdem noch konkretisiert werden. Modularer Aufbau Unterstützung zahlreicher Use Cases Umfangreiche Spezifikation 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) 27

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