Dokumentation MOA-ID Single Sign-On

www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Dokumentation MOA-ID Single Sign-On Erweiterung von MOA-ID für bereichsübergreifendes Single Sign-On Version 1.0, 05. Oktober 2009 Bernd Zwattendorfer bernd.zwattendorfer@egiz.gv.at Zusammenfassung: Zur Identifizierung von BenutzerInnen bei Online Applikationen wird im österreichischem E- Government das bereichsspezifische Personenkennzeichen (bpk) verwendet. Üblicherweise erfolgt dabei eine Anmeldung über das Server-Modul MOA-ID. Derzeit ist die Situation so, dass BenutzerInnen nach erfolgreicher Anmeldung bei MOA-ID eines Tätigkeitsbereiches für den Zugriff auf eine weitere Applikation aus einem anderen staatlichen Tätigkeitsbereich sich erneut mittels Bürgerkarte bei der weiteren Applikation anmelden müssen. Um diesen Problem entgegenzuwirken, wurde MOA-ID so erweitert, dass ein vereinfachter Anmeldeprozess (Single Sign-On) bereichsübergreifend unterstützt wird. Es wird hier die Anwendung dokumentiert. Es werden dabei sowohl die Benutzung (Anwendungsbeschreibung), die getesteten Umgebungen (Testbeschreibung), sowie die Installation beschrieben (Deployment und Auslieferung). Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU -Graz

Inhaltsverzeichnis Inhaltsverzeichnis 1 Kurzbeschreibung... 5 1.1 Grundlagen 5 1.2 Funktionsbeschreibung 8 1.3 Voraussetzungen zur Nutzung der Anwendung 8 2 Anwendungsbeschreibung... 9 2.1 Prozessablauf 11 2.2 Online Applikation (A) MOA-ID (A) 12 2.3 MOA-ID (A) - SZR 12 2.4 MOA-ID (A) MOA-ID (B) 13 2.5 MOA-ID (B) Online Applikation (B) 14 3 Testbeschreibung...15 4 Deployment...17 4.1 Systemanforderungen 17 4.2 Konfiguration 17 5 Auslieferung...22 5.1 Struktur 22 Referenzen...23 2

Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1-1: SAML Architektur... 6 Abbildung 2-1: Derzeitige Situation... 9 Abbildung 2-2: Single Sign-On... 10 Abbildung 2-3: Sequenz-Diagramm SSO Anmeldung... 12 Abbildung 3-1: Anmeldung an Online Applikation 1... 15 Abbildung 3-2: Erfolgreiche Anmeldung an Online Applikation 1 und Link für SSO-Anmeldung... 15 Abbildung 3-3: Anmeldung via SSO bei Applikation 2... 16 3

Revision History Revision History Version Datum Autor(en) 0.1 25.09.2009 1.0 02.10.2009 Bernd Zwattendorfer Bernd Zwattendorfer Dokumenterstellung Finalisieren Version 1.0 4

Kurzbeschreibung 1 Kurzbeschreibung 1.1 Grundlagen 1.1.1 Single Sign-On Über das World Wide Web werden immer mehr Informationen und Dienste angeboten. BenutzerInnen können auf diese Dienste mittels Web-Browser zugreifen. Üblicherweise sind dabei Dienste, welche nicht nur rein für den Informationsaustausch Verwendung finden, mittels Benutzername/Passwort oder über andere, sicherere Authentifizierungsmechanismen geschützt. Oft erfolgt der Einstieg zu solchen Dienstleistungen über ein Portal, wo mehrere Dienste und Services unterschiedlicher Anbieter gebündelt sind. Dabei kann das Problem entstehen, dass die einzelnen Anbieter nicht auf eine gemeinsame Benutzerverwaltung Zugriff haben und sich so BenutzerInnen, die mehrere Dienste unterschiedlicher Anbieter gleichzeitig nutzen wollen, jeweils separat und erneut anmelden müssen. Um diesem Problem entgegenzuwirken, wurde das Konzept des Single Sign-On (SSO) entwickelt. Mit Hilfe von Single Sign-On wird es BenutzerInnen ermöglicht, sich in einem verteilten Netzwerk nur mehr einmal authentifizieren zu müssen, und trotzdem Zugriff auf weitere und unterschiedliche geschützte Ressourcen zu erhalten. Die Authentifizierung bei den weiteren geschützten Ressourcen erfolgt dabei für die BenutzerInnen automatisch und übergangslos. Vorteile von Single Sign-On bilden auf der einen Seite Zeitersparnis und Benutzerfreundlichkeit, da BenutzerInnen nur mehr einmal einen gesamten Anmeldeprozess durchlaufen müssen. Auf der anderen Seite kann damit die Sicherheit erhöht werden, da die Authentifizierung nur mehr an einer zentralen Stelle passiert und eine Überladung von Anmeldedaten (z.b. das Merken unterschiedlicher Benutzernamen/Passwörter) entfällt. Als Nachteil muss an dieser Stelle erwähnt werden, dass bei Identitätsdiebstahl eine Angreiferin oder ein Angreifer Zugriff nicht nur auf ein System sondern auf alle mit Single Sign-On geschützten Systeme erhält. 1.1.2 Security Assertion Markup Language (SAML) Die Security Assertion Markup Language (SAML) [1] spezifiziert einen auf XML-basierenden Standard für den sicheren Austausch von Authentifizierungs- und Autorisierungsdaten. Üblicherweise beinhalten diese Daten Informationen darüber, dass sich eine Benutzerin oder ein Benutzer zu einer bestimmten Zeit an einem bestimmten System mittels einem entsprechenden Authentifizierungsmechanismus ordnungsgemäß und erfolgreich authentifiziert hat. Authentifizierungsdaten können aber nicht nur für natürliche Personen, sondern auch für Web Services oder Systeme ausgestellt werden. Die Security Assertion Markup Language wurde von OASIS (Organization for the Advancement of Structured Information Standards) 1 entwickelt und die erste Version (1.0) im Jahr 2002 veröffentlicht. In den meisten Fällen werden Authentifizierungs- und Autorisierungsdaten zwischen einem oder mehreren sogenannten Service Providern (SP), welche Dienstleistungen anbieten, und einem Identity Provider (IdP), welcher für die Authentifizierung und den Nachweis der Identität verantwortlich ist, ausgetauscht. Der Identity Provider übernimmt üblicherweise den Authentifizierungsprozess und stellt sogenannte SAML Assertions (XML-Konstrukte welche Informationen über den Authentifizierungsprozess beinhalten) aus. Aus diesem Grund wird ein Identity Provider im Kontext von SAML auch als Asserting Party oder SAML Authority 1 http://www.oasis.org 5

Kurzbeschreibung bezeichnet. Ein Service Provider (oder Relying Party) verwendet diese Assertions vom Identity Provider um basierend auf den enthaltenen Authentifizierungsdaten den Zugriff zu den von der Benutzerin oder vom Benutzer nachgefragten Online Ressourcen zu gewähren oder zu verweigern. Gründe für den Einsatz von SAML [2]: Single Sign-On Für Single Sign-On verwenden Anwendungen üblicherweise Browser-Cookies zur Speicherung von Zustandsinformationen für die Vermeidung eines erneuten Authentifizierungsprozesses. Die Verwendung von Cookies besitzt aber Limitierungen, da diese nicht über DNS Domänen-Grenzen ausgetauscht werden können. Diese Problem wird als Multi-Domain SSO (MDSSO) bezeichnet. SAML löst dieses Problem mit Hilfe eines standardisierten Protokolls für den Austausch von Authentifizierungsinformationen unabhängig von der DNS Domäne. Föderierte Identität Die Bezeichnung föderierte Identität definiert den Austausch von Personen- Informationen übergreifend zwischen Sicherheitsdomänen zwischen Partnern. Auf Basis von speziellen Vereinbarungen können Personen-Informationen zwischen diesen Sicherheitsdomänen ausgetauscht werden. Die Notwendigkeit von doppelter Datenspeicherung von BenutzerInnen entfällt, da diese Daten einfach auf Basis eines gemeinsamen Bezeichners ausgetauscht werden können. Web Services und andere Industrie-Standards SAML besitzt eine große Flexibilität und Modularität und kann so auch in anderen Frameworks eingesetzt werden. Ein Beispiel dafür wäre die Verwendung in WS- Security zur Sicherung von Web Service SOAP-Nachrichten. 1.1.2.1 Architektur SAML beschreibt eine modulare Architektur die aus mehreren Komponenten besteht. Setzt man diese Komponenten zusammen, so können unterschiedliche Anwendungsfälle realisiert werden. Abbildung 1-1 zeigt die einzelnen Komponenten und deren Zusammenhang. Profiles Bindings Protocols Assertions Statements Abbildung 1-1: SAML Architektur 6

Kurzbeschreibung 1.1.2.1.1 Assertions SAML Assertions bilden die Kernkomponente von SAML und beinhalten ein oder mehrere Statements. Diese Statements inkludieren Eigenschaften und Attribute von einem sogenannten SAML Subject, welches jene Person oder jenes System, für die bzw. das die Authentifizierungsdaten ausgestellt werden, beschreibt. SAML Assertions sind durch ein XML Schema definiert und stellen somit einfach XML-Konstrukte dar. Die SAML Spezifikation [3] unterscheidet drei Arten von Statements, die in eine SAML Assertion eingearbeitet werden können: Authentication Statements Authentication Statements werden von einem Identity Provider erzeugt, wenn sich ein SAML Subject entsprechend erfolgreich bei ihm authentifiziert hat. Eine Assertion, welche ein Authentication Statement enthält, besitzt zumindest Informationen darüber, wer sich authentifiziert hat und wem gegenüber die Authentifizierungsnachweise erbracht wurden. Attribute Statements Diese Statements beinhalten bestimmte Attribute oder Eigenschaften eines SAML Subjects. Meist werden diese Daten für die Zugangskontrolle bei Applikationen verwendet. Authorization Decision Statements Diese Statements wurden speziell für den Fall einer Autorisierung entwickelt und inkludieren Informationen ob Zugriff zu einer bestimmten Ressource gewährt oder verweigert werden soll. 1.1.2.1.2 Protocols SAML Assertions können entweder von einem Service Provider angefragt werden oder einfach vom Identity Provider zum Service Provider geschickt werden. Die sogenannten SAML Protocols definieren welche Art von Assertion ausgetauscht und wie diese angefragt wird. Die SAML Spezifikation stellt dazu ein eigenes XML-Schema für diese Request/Response-Nachrichten zur Verfügung. Die Request-Nachrichten beinhalten Anfrage-Informationen für Assertions, die Authentication, Attribute oder Authorization Decision Statements enthalten können. 1.1.2.1.3 Bindings Die Verknüpfung von SAML Request/Response-Nachrichten auf darunterliegende Transport- Protokolle wird in den SAML Bindings definiert. Die bekanntesten Bindings sind das sogenannte SAML SOAP Binding, das die SAML Protokoll-Nachricht in eine SOAP- Nachricht einbettet, und das HTTP-POST-Binding, das eine SAML-Nachricht via HTTP- POST zum entsprechenden Provider überträgt. Die unterschiedlichen Bindings können in Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 [4] gefunden werden. 1.1.2.1.4 Profiles SAML Profiles beschreiben, wie SAML Assertions, Protocols und Bindings miteinander verknüpft werden um entsprechende Anwendungsfälle zu formen. Das Web Single Sign-On Profile spezifiziert beispielsweise, wie Authentifizierungsdaten zwischen einem Identity Provider und einem Service Provider ausgetauscht werden müssen, um Single Sign-On mittels Web Browser nutzen zu können. Weiter Profile sind in dem Dokument Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 [5] spezifiziert. 7

Kurzbeschreibung 1.2 Funktionsbeschreibung Neben privaten Anbietern bieten auch öffentliche Behörden und Institutionen immer mehr Informationen oder Dienste über das World Wide Web (WWW) an. Aus Sicherheitsgründen kann bei einzelnen Applikationen eine Identifizierung bzw. Authentifizierung von BenutzerInnen notwendig sein. Sowohl im behördlichen als auch im privatwirtschaftlichen Bereich wird aber bereits vermehrt auf sicherere Authentifizierungstechnologien, wie es beispielsweise das österreichische Bürgerkartenkonzept bietet, gesetzt. Anwendungen und Dienste im behördlichen Bereich setzen speziell auf das Modul MOA-ID zur sicheren und starken Authentifizierung mittels Bürgerkarte. Zur Identifizierung einer Benutzerin oder eines Benutzers wird ein sogenanntes bereichsspezifisches Personenkennzeichen (bpk) verwendet. Für die Bestimmung bzw. Berechnung eines bpks wird behördlichen Anwendungen ein spezieller staatlicher Tätigkeitsbereich zugeordnet. Die Berechnung des bpks wird üblicherweise von MOA-ID übernommen. Möchte eine Benutzerin oder ein Benutzer auf eine mit Bürgerkarte geschützte Anwendung zugreifen, so muss er/sie sich entsprechend bei der zur Applikation zugeordneten MOA-ID-Instanz anmelden. Derzeit ist die Situation so, dass eine Benutzerin oder ein Benutzer, wenn er/sie auf eine weitere Applikation, welche einem anderen staatlichen Tätigkeitsbereich zugeordnet ist, zugreifen möchte, sich erneut mittels Bürgerkarte bei einer MOA-ID-Instanz des anderen Bereichs anmelden muss. Ziel dieses Projekts war es, MOA-ID um eine Service-Schnittstelle so zu erweitern, dass ein automatischer Authentifizierungsvorgang und somit Single Sign-On unterstützt wird. Im konkreten Fall bedeutet dies, dass BenutzerInnen, die bei Applikation (Bereich A) über MOA- ID (A) angemeldet sind, bei einem Zugriff aus Applikation (A) auf Applikation (B) automatisch und ohne sichtbaren Authentifizierungsvorgang mittels Bürgerkarte bei MOA-ID (B) angemeldet werden und somit Zugriff auf Applikation (B) erhalten. BenutzerInnen soll dadurch einerseits ein vereinfachter Anmeldeprozess geboten und andererseits ein automatischer Zugriff auf bereichsübergreifende behördliche Anwendungen und Dienste ermöglicht werden. 1.3 Voraussetzungen zur Nutzung der Anwendung Für die Verwendung von MOA-ID-SSO sind für BenutzerInnen keine weiteren Voraussetzungen als wie für die normale Verwendung von MOA-ID zur sicheren Authentifizierung von Nöten. 8

Anwendungsbeschreibung 2 Anwendungsbeschreibung Dieser Abschnitt beschreibt die Umsetzung für eine Single Sign-On Lösung im WWW unter Verwendung und Erweiterung von MOA-ID. Durch diese Lösung soll BenutzerInnen ein erhöhter Komfort durch einen vereinfachten Anmeldeprozess bei mehreren Anwendungen im behördenübergreifenden Bereichen ermöglicht werden. Im österreichischen E-Government wird zur Identifizierung eines/einer BürgerIn bei Online Applikationen das bereichsspezifische Personenkennzeichen (bpk) verwendet. Dieses Kennzeichen berechnet sich aus der einzigartigen Stammzahl der Benutzerin oder des Benutzers und dem staatlichen Tätigkeitsbereich, dem die Online-Applikation zugeordnet ist. Zur sicheren Authentifizierung und eindeutigen Identifizierung von BenutzerInnen sowie zur Entkopplung der Online-Applikation wird mit MOA-ID ein Modul bereitgestellt, welches auf dem Konzept der Bürgerkarte basiert und die Berechnung des bpk sowie die Anmeldung an der Online Applikation vornimmt. Möchte eine Benutzerin oder ein Benutzer auf Daten einer geschützten Online Applikation zugreifen, so muss er/sie sich zuvor korrekt über MOA-ID identifizieren. Befindet sich die Online Applikation beispielsweise im staatlichen Tätigkeitsbereich (A), so stellt das zur Authentifizierung verwendete Modul MOA-ID (A) ein bpk für den Bereich (A) aus und stellt dieses für die Anmeldung an der Online Applikation des Bereichs (A) bereit. Will die selbe Benutzerin oder der selbe Benutzer auf eine Applikation aus dem Bereich (B) zugreifen, so muss er/sie sich erneut mittels Bürgerkarte an einer MOA-ID-Instanz des anderen Bereichs (B) authentifizieren. Diese Instanz stellt entsprechend wiederum ein bpk diesmal für den Bereich (B) aus. Abbildung 2-1 illustriert diese derzeitige Situation. Tätigkeitsbereich A Tätigkeitsbereich B Online Applikation (A) Online Applikation (B) bpk (A) bpk (B) MOA-ID (A) MOA-ID (B) Web Browser / Benutzer BKU Abbildung 2-1: Derzeitige Situation 9

Anwendungsbeschreibung Zusätzliche Anmeldeprozesse erhöhen nicht gerade die Benutzerfreundlichkeit eines Systems. Aus diesem Grund wurde MOA-ID so erweitert werden, dass ein automatischer Anmeldeprozess und Single Sign-On für BenutzerInnen ermöglicht wird. Dies bedeutet für BenutzerInnen, dass sie nach erfolgreicher Anmeldung bei einer Applikation beim Wechsel auf eine weitere, ebenfalls durch MOA-ID geschützte Applikation eines anderen Bereichs automatisch authentifiziert wird, sofern sie die entsprechenden Berechtigungen bzw. Zugriffsrechte dafür besitzen. Ob Zugriff gewährt oder verweigert wird, obliegt weiterhin der geschützten Online Applikation. Als konkretes Beispiel wird angenommen, dass sich eine Benutzerin oder ein Benutzer bereits ordnungsgemäß mittels Bürgerkarte an Applikation (A), welche dem Tätigkeitsbereich (A) zugeordnet ist und durch MOA-ID (A) geschützt wird, authentifiziert hat und Zugriff auf diese besitzt. Applikation (A) bündelt beispielsweise mehrere Applikationen und besitzt somit auch Verweise zu anderen Anwendungen (z.b. eine Auswahl Weiter zur Zustellung in der Anwendung Meldebestätigung hier exemplarisch, den Zustellnachweis nicht berücksichtigend). Unter anderem befindet sich auch ein Verweis auf eine Applikation (B) aus dem Bereich (B), welche entsprechend durch MOA-ID (B) geschützt ist. Mit MOA-ID Single Sign-On kann eine für die Benutzerin oder den Benutzer nicht sichtbare und automatische Anmeldung bei MOA- ID (B) erfolgen. MOA-ID (B) gewährt Zugriff auf die Applikation (B), da sich die Benutzerin bzw. der Benutzer bereits erfolgreich bei MOA-ID (A) authentifiziert hat und ein geeignetes Vertrauensverhältnis zwischen MOA-ID (A) und MOA-ID (B) existiert. Die von MOA-ID (B) benötigten Authentifizierungsdaten werden von MOA-ID (A) entsprechend gesichert übertragen. Abbildung 2-2 zeigt den Fall einer Single Sign-On Anmeldung. Tätigkeitsbereich A Tätigkeitsbereich B Online Applikation (A) bpk (A) + Bereich B Fremd-bPK (B) Stammzahlen register Online Applikation (B) bpk (A) bpk (B) SSO (IdP) Fremd-bPK (B) SSO (SP) MOA-ID (A) MOA-ID (B) Web Browser / Benutzer BKU Abbildung 2-2: Single Sign-On 10

Anwendungsbeschreibung MOA-ID (B) benötigt für eine Anmeldung von BenutzerInnen an Applikation (B) auch ein bpk für den Bereich (B). Bei der Anmeldung an Applikation (A) wurde durch MOA-ID (A) jedoch nur ein bpk für den Bereich (A) berechnet. Damit Applikation (A) eine automatisierte Anmeldung bei MOA-ID (B) durchführen kann, muss zuvor ein Fremd-bPK für den Bereich (B) berechnet werden. Die Fremd-bPK-Berechnung erfolgt über das Stammzahlenregister. Dabei werden die Daten der Benutzerin bzw. des Benutzers, die bpk des bekannten Bereichs (in diesem Fall des Bereichs A) sowie der gewünschte, andere Bereich (hier Bereich B) an das Stammzahlenregister gesendet. Das Stammzahlenregister berechnet ein Fremd-bPK für den Bereich (B), welches einem verschlüsseltem bpk für den Bereich (B) entspricht. Mit Hilfe dieses Fremd-bPKs kann MOA-ID (A) ein entsprechendes Authentifizierungstoken zusammenstellen, welches anschließend an MOA-ID (B) gesendet wird. Das Authentifizierungstoken kann neben dem Fremd-bPK noch unterschiedliche Informationen über die Benutzerin oder den Benutzer beinhalten. MOA-ID (B) extrahiert aus diesem Authentifizierungstoken alle notwendigen Daten für eine Anmeldung an der Applikation (B) und führt diese anschließend auch durch. Durch die Anmeldung mittels Authentifizierungstoken ist keine erneute Bürgerkarten-Interaktion notwendig und die Benutzerin oder der Benutzer wird nahtlos bei MOA-ID (B) authentifiziert und erhält Zugriff auf die Applikation im Bereich (B). 2.1 Prozessablauf Um Single Sign-On zu unterstützen, mussten sowohl MOA-ID (A) als auch MOA-ID (B) um eine entsprechende Service-Schnittstelle erweitert werden. Das Authentifizierungstoken, welches zwischen MOA-ID (A) und MOA-ID (B) ausgetauscht wird, basiert auf SAML 2.0 und wird gemäß dem Web Single Sign-On Profile [5] verarbeitet. Verwendet man die Terminologie von SAML, so arbeitet MOA-ID (A) mit SSO-Erweiterung als Identity Provider und MOA-ID (B) mit SSO-Erweiterung als Service Provider. Im folgenden wird der Prozessablauf für eine SSO-Anmeldung genauer beschrieben (siehe Abbildung 2-3). Der Ablauf wird dabei in vier Stufen unterteilt. Es wird weiters angenommen, dass sich eine Benutzerin oder ein Benutzer bei MOA-ID (A) bereits ordnungsgemäß mittels Bürgerkarte authentifiziert hat. MOA-ID wurde daraufhin so erweitert, dass eine Sitzung zwischen dem Browser der Benutzerin bzw. des Benutzers und MOA-ID gehalten und so erkannt werden kann, ob sich eine Benutzerin oder ein Benutzer zuvor bereits ordnungsgemäß authentifiziert hat. 11

Anwendungsbeschreibung Browser OA (A) MOA-ID (A) SZR MOA-ID (B) OA (B) Request OA (B) Stufe 1 Redirect auf MOA-ID (A) SSO Request mit Parametern Überprüfung gültige Sitzung Stufe 2 Request Fremd-bPK Fremd-bPK HTTP Post Formular mit Response/Assertion Stufe 3 HTTP POST Redirect mit SAML Artifact Überprüfung SAML Assertion Artifact Stufe 4 SOAP Request mit Artifact Response OA (B) SOAP Response mit Assertion Abbildung 2-3: Sequenz-Diagramm SSO Anmeldung 2.2 Online Applikation (A) MOA-ID (A) Der Zugriff auf eine Applikation (B) aus einem anderen Bereich wird in Applikation (A) durch das Einbetten einer speziellen URL als Hyperlink gelöst. Die URL zeigt auf ein Service von MOA-ID (A), welches entsprechend angehängte Parameter wie den fremden Tätigkeitsbereich und die gewünschte Online Applikation aus diesem fremden Bereich, auf die zugegriffen werden soll, entgegennimmt. Beispiel eines solchen URLs: https://bereich-a.gv.at/moa-id-auth-a/moa-sso/idp/saml/redirect? OA=https://bereich- B.gv.at/applikation-B/&Target=Bereich-B Parameter Name OA Target Beschreibung Applikation aus fremden Tätigkeitsbereich Fremder Tätigkeitsbereich 2.3 MOA-ID (A) - SZR MOA-ID (A) nimmt diese beiden Parameter entgegen und überprüft, ob die Benutzerin oder der Benutzer, die/der diese Anfrage gerichtet hat, sich zuvor mittels Bürgerkarte 12

Anwendungsbeschreibung ordnungsgemäß authentifiziert hat und ob noch eine gültige Sitzung besteht. Ist dies der Fall, so kann für die Benutzerin oder den Benutzer eine Fremd-bPK-Berechnung für den neuen Bereich über eine Anfrage an das Stammzahlenregister durchgeführt werden. Dafür werden die persönlichen Daten der Benutzerin bzw. des Benutzers wie Name und Geburtsdatum, das bpk für den bereits authentifizierten Bereich und der gewünschte fremde Bereich benötigt. Diese Daten werden in einen Web Service-Request verpackt und an das Stammzahlenregister geschickt. Die Antwort enthält das Fremd-bPK der Benutzerin bzw. des Benutzers oder eine entsprechende Fehlermeldung, falls das bpk für den fremden Bereich nicht berechnet werden konnte. 2.4 MOA-ID (A) MOA-ID (B) Wurde die Benutzerin oder der Benutzer bereits ordnungsgemäß authentifiziert und konnte eine Fremd-bPK berechnet werden, so stellt MOA eine SAML Assertion in der Version 2.0 zusammen, welche das Fremd-bPK sowie weitere personenbezogene Daten enthält. Korrespondierend zum Web Browser SSO Profile von SAML wird diese Assertion signiert und in eine SAML Protocol-Nachricht verpackt. Beispiel einer SAML Assertion: <saml:assertion xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" ID="_29820986f2d2493b3de333d80a034780" IssueInstant="2009-09-17T16:14:05.938Z" Version="2.0"> <saml:issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://bereich-A.gv.at</saml:Issuer> <ds:signature> </ds:signature> <saml:subject> <saml:nameid NameQualifier="urn:publicid:gv.at:ecid+B">encrypted-bPK</saml:NameID> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata Address="127.0.0.1" NotOnOrAfter="2009-09-17T16:19:05.938Z" Recipient="https://bereich-B.gv.at /moa-id-auth-b/moa-sso/sp/saml/post"/> </saml:subjectconfirmation> </saml:subject> <saml:conditions NotBefore="2009-09-17T16:14:05.938Z" NotOnOrAfter="2009-09-17T16:19:05.938Z"> <saml:audiencerestriction> <saml:audience>https://bereich-b.gv.at</saml:audience> </saml:audiencerestriction> <saml:onetimeuse/> </saml:conditions> <saml:authnstatement AuthnInstant="2009-09-17T16:13:39.377Z"> <saml:authncontext> <saml:authncontextclassref>urn:oasis:names:tc:saml:2.0:ac:classes:smartcardpki</saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute Name="GivenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>xxxkarin Stella</saml:AttributeValue> </saml:attribute> <saml:attribute Name="FamilyName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>xxxkunz</saml:attributevalue> </saml:attribute> <saml:attribute Name="DateOfBirth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>1900-01-01</saml:attributevalue> </saml:attribute> 13

Anwendungsbeschreibung <saml:attribute Name="oaURL" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:attributevalue>https://bereich-b.gv.at/applikation-b/</saml:attributevalue> </saml:attribute> <saml:attribute Name="bkuURL" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:attributevalue>http://localhost:3495/http-security-layer-request</saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> Beispiel einer SAML Response: <samlp:response xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" ID="_5421b4b66af2ee10ea74ed0b47c210b2" IssueInstant="2009-09-18T14:55:28.725Z" Version="2.0"> <saml:issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://bereich-A.gv.at</saml:Issuer> <ds:signature> </ds:signature> <samlp:status> <samlp:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:status> <saml:assertion> </saml:assertion> </samlp:response> Diese SAML Protocol Nachricht wird anschließend gemäß gewähltem Binding von MOA-ID (A) zu MOA-ID (B) übertragen. Im Moment wird nur eine Übertragung mittels HTTP-POST- Binding unterstützt, welches die Assertion via HTTP-POST und dem Browser der Benutzerin bzw. des Benutzers an MOA-ID (B) überträgt. 2.5 MOA-ID (B) Online Applikation (B) MOA-ID (B) empfängt an der entsprechenden Stelle die SAML Response und extrahiert daraus die Assertion. Um deren Gültigkeit zu Überprüfen werden neben einer Signatur- und Zertifikatsprüfung auch einzelne in der Assertion enthaltene Parameter wie z.b. Gültigkeitsdauer der Assertion validiert. Weiters wird überprüft, ob eine Anmeldung an der von der Benutzerin bzw. vom Benutzer gewünschten Applikation, welche als Parameter in der Assertion enthalten ist, von MOA-ID (B) auch unterstützt wird. War die Überprüfung aller Kriterien erfolgreich, so stellt MOA-ID (B) die erhaltenen Daten gemäß der MOA-ID-Spezifikation in einer Assertion der Version 1.0 zusammen und überträgt diese entsprechend dem Browser/Artifact Profile an die Online Applikation (B). Dieser Vorgang entspricht der Weiterleitung der Daten nach einer erfolgreichen Bürgerkarten- Anmeldung. Für Online Applikationen ergibt sich daraus kein Unterschied, ob die Bürgerin oder der Bürger von MOA-ID (B) mittels Bürgerkarte oder via Single Sign-On authentifiziert wurde. An Applikation (B) müssen daher keine Veränderungen vorgenommen werden. 14

Testbeschreibung 3 Testbeschreibung Die Anwendung wurde zu Testzwecken mit zwei Beispiel-Applikationen deployt. Dabei muss sich eine Benutzerin oder ein Benutzer zuerst bei der Demo-Applikation 1 mit ihrer/seiner Bürgerkarte anmelden und kann nach erfolgreichem Login eine SSO-Anmeldung bei Demo- Applikation 2 durchführen. Die nachfolgenden Abbildungen zeigen jeweils Screen-Shots dieses Demo-Logins. Abbildung 3-1: Anmeldung an Online Applikation 1 Die Benutzerin oder der Benutzer kann sich bei Applikation 1 entweder mit lokaler oder server-seitiger Bürgerkartenumgebung anmelden. Abbildung 3-2: Erfolgreiche Anmeldung an Online Applikation 1 und Link für SSO-Anmeldung 15

Testbeschreibung Nach erfolgreicher Anmeldung wird der Benutzerin bzw. dem Benutzer ein Hyperlink dargestellt, via dem er/sie eine SSO-Anmeldung bei Applikation 2 durchführen kann. Abbildung 3-3: Anmeldung via SSO bei Applikation 2 Die Benutzerin bzw. der Benutzer hat sich erfolgreich via SSO bei Applikation 2 angemeldet. Die Anmeldung ist äquivalent zu einer erneuten Anmeldung mittels Bürgerkarte bei Applikation 2. 16

Deployment 4 Deployment 4.1 Systemanforderungen Es gelten folgende Anforderungen an die Installationsplattform bzw. an die Clientkomponenten (die angegebenen Versionen entsprechen der getesteten Umgebung): 4.1.1 Server-Komponenten Die Anforderungen von MOA-ID sind identisch mit jenen, die in der MOA-ID Dokumentation angegeben sind [8]. Für die Nutzung von Single Sign-On wird zusätzlich die Erfüllung der folgenden Anforderungen benötigt: Java ab Version 1.5 Tomcat Servlet-Container ab Version 5 4.1.2 Client-Komponenten Web Browser mit Java-Script Unterstützung 4.2 Konfiguration Die Konfiguration für die SSO-Erweiterungen basiert auf dem XML-Schema für SAML Metadaten [6]. Zur Vereinfachung werden aber nicht die gesamten von SAML zur Verfügung gestellten Metadaten unterstützt, sondern nur Teile daraus entsprechend abgeändert und verwendet. Weiters sind Anpassungen im Deployment-Descriptor (web.xml) vorzunehmen und bei Bedarf kann die Implementierung durch Konfiguration entsprechend erweitert werden. 4.2.1 Minimalkonfiguration Die hier angeführten Parameter sind unbedingt vor Inbetriebnahme der Anwendung anzupassen und stellen somit eine Minimalkonfiguration dar. Beispielkonfiguration für eine MOA-ID Installation, die sowohl als IdP als auch als SP arbeitet. <EntityDescriptor xmlns="urn:oasis:names:tc:saml:2.0:metadata" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:moa="urn:moa:sso:metadata" entityid="http://test.gv.at"> <IDPSSODescriptor protocolsupportenumeration="urn:oasis:names:tc:saml:2.0:protocol"> <KeyDescriptor use="signing"> <dsig:keyinfo> <dsig:keyname>test.gv.at</dsig:keyname> </dsig:keyinfo> </KeyDescriptor> <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="/Redirect"> </SingleSignOnService> </IDPSSODescriptor> <SPSSODescriptor 17

Deployment WantAssertionsSigned="true" protocolsupportenumeration="urn:oasis:names:tc:saml:2.0:protocol"> <Extensions> </Extensions> <moa:trustedidps> <moa:entityid>http://test.gv.at</moa:entityid> </moa:trustedidps> <AssertionConsumerService isdefault="true" index="0" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="/POST"> </AssertionConsumerService> </AssertionConsumerService> </SPSSODescriptor> </EntityDescriptor> Die gelb hinterlegten Werte müssen vor Inbetriebnahme an die Umgebung angepasst werden. Die in der Tabelle angegeben Werte betreffen einerseits MOA-ID als IdP und andererseits MOA-ID als SP. SSO-Metadata Element bzw. Attribut Default-Wert Beschreibung EntityDecriptor.entit yid Eindeutige Bezeichung für MOA-ID, welches als SSO IdP bzw. SP arbeitet <dsig:keyname> Host-Name Name des privaten Schlüssels, der zum Signieren von SAML Nachrichten verwendet wird SingleSignOnService.B inding SingleSignOnService.L ocation SPSSODescriptor.WantA ssertionssigned <moa:entityid> AssertionConsumerServ ice.binding AssertionConsumerServ ice.location false Das Transport-Binding, mit dem eingehende SSO-Requests entgegen genommen werden können Eingehende Requests mit dieser URL-Pattern-Endung werden mit dem spezifizierten Binding verarbeitet. Gibt an, ob MOA als SP SAML- Assertions signiert empfangen möchte Bezeichnet jene MOA-SSO- IdPs, denen ein MOA-SSO-SP vertraut. Die Werte müssen mit der entityid eines MOA-SSO- IdP übereinstimmen Binding des SP, das für den Empfang von SAML- Nachrichten verwendet wird Über dieses URL-Pattern eingehende Nachrichten werden mit obigen Binding verarbeitet. 18

Deployment Wird MOA-ID als IdP betrieben, so ist zusätzlich noch eine Konfigurationsdatei notwendig, die jene MOA-SSO-SPs bezeichnet, an die SAML Nachrichten gesendet werden können. Beispiel einer solchen Konfigurations-Datei: <EntitiesDescriptor xmlns="urn:oasis:names:tc:saml:2.0:metadata" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Name="Relying-Parties.xml"> <EntityDescriptor entityid="http://test.gv.at:8080/moa-id-proxy/"> <SPSSODescriptor WantAssertionsSigned="true" protocolsupportenumeration="urn:oasis:names:tc:saml:2.0:protocol"> <KeyDescriptor use="encryption"> <dsig:keyinfo> <dsig:keyname>test.gv.at</dsig:keyname> </dsig:keyinfo> </KeyDescriptor> <AssertionConsumerService isdefault="true" index="0" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://test.gv.at:8080/moa-id-auth/moa-sso/sp/SAML/POST"> </AssertionConsumerService> </SPSSODescriptor> </EntityDescriptor> </EntitiesDescriptor> Relying-Parties Element bzw. Attribut Default-Wert Beschreibung EntitiesDescriptor.Na me EntityDescriptor.enti tyid SPSSODescriptor.WantA ssertionssigned <dsig:keyname> AssertionConsumerServ ice.binding AssertionConsumerServ ice.location false Muss den gleichen Namen wie die Datei besitzen. Gibt die Online Applikation des fremden Bereichs an, für die eine SSO-Anmeldung durchgeführt werden soll Gibt an, ob dieses MOA-ID SAML-Assertions signiert empfangen möchte Name des Schlüssels, welcher zum Entschlüsseln von FremdbPKs verwendet wird Binding, über welches SAML- Nachrichten and MOA-SSO-SP übertragen werden sollen URL an den SAML-Nachrichten über oben genanntes Binding gesendet werden sollen. Damit diese Dateien vom Servlet-Container korrekt geladen werden können, müssen die Pfade dafür in der Datei web.xml von MOA-ID-Auth angepasst werden. 19

Deployment web.xml Context-param Default-Wert Beschreibung metadatalocation metadataentityid relyingpartieslocatio n keystorepath keystorepassword Pfad für die SSO-Metadata Datei EntityID, für die die Metadaten geladen werden soll Pfad zur Relying Parties- Konfiguration, falls MOA-ID als IdP betrieben wird Pfad zu einem KeyStore, welcher Schlüssel zum Signieren von SAML- Nachrichten (IdP) bzw. Schlüssel zum Entschlüsseln von Fremd-bPKs (SP) enthält Passwort für den KeyStore 4.2.2 Erweiterte Konfiguration Die folgenden Parameter dienen teilweise zu Testzwecken bzw. stellen konstante Einträge dar, die in typischen Installationen nicht geändert werden sollten. web.xml Context-param Default-Wert Beschreibung ssohandlerconfig szrconfigfile Pfad zur Datei, welche interne Konfigurationsparameter enthält Pfad zur Datei, welche Informationen zur SZR- Kommunikation enthält Die Anwendung wird bereits mit einer internen Konfigurations-Datei ausgeliefert, die angibt, welche Implementierung für welches Binding verwendet werden soll. Beispiel für die Konfigurationsdatei: <properties> <category name="idpinboundhandler"> <property name="urn:oasis:names:tc:saml:2.0:bindings:http-redirect" value="moa.sso.authentication.idp.idpinboundredirecthandler"/> </category> <category name="idpoutboundhandler"> <property name="urn:oasis:names:tc:saml:2.0:bindings:http-post" value="moa.sso.authentication.idp.idpoutboundposthandler"/> </category> <category name="spinboundhandler"> <property name="urn:oasis:names:tc:saml:2.0:bindings:http-post" value="moa.sso.authentication.sp.spinboundposthandler"/> </category> <category name="spoutboundhandler"> 20

Deployment <property name="urn:oasis:names:tc:saml:1.0:bindings:http-artifact" value="moa.sso.authentication.sp.spoutboundmoahandler"/> </category> <category name="errorhandler"> <property name="errorhandlerimpl" value="moa.sso.error.errorhandler"/> <property name="errorpage" value="/ssoerror.jsp"/> </category> <property name="bpkbuilder" value="szrbpkbuilder"/> </properties> Wird die bpk-berechung über einen Aufruf des SZRs durchgeführt, so müssen für den Verbindungsaufbau geeignete Paramter angegeben werden. Diese Paramter werden in einer eigenen Datei angegeben, der Pfad dazu wird in der Datei web.xml definiert. SZR Properties Property Default-Wert Beschreibung foreign_vkz szr_url szr_keystore szr_keystore_pwd szr_truststore Verwaltungskennzeichen das für die Berechung der Fremd-bPK verwendet wird URL des Stammzahlenregisters Relativer Pfad zum Keystore, der Zertifikate und Schlüssel zur Authentifizierung gegenüber dem SZR enthält Passwort für den Zugriff auf den Keystore Relativer Pfad zum Truststore, der die vertrauenswürdigen Zertifikate für eine SSL- Verbindung zum SZR enthält szr_pvp_version 1.8f Verwendete PVP-Version szr_pvp_file Relativer Pfad zur Datei, die die notwendigen PVP-Header enthält 21

Auslieferung 5 Auslieferung Die vorliegende Applikation wird zusammen mit den Quelltexten und dieser Dokumentation ausgeliefert. 5.1 Struktur /README.txt /moa-id-auth-war /moa-id-changes /src /target /pom.xml Kurzbeschreibung des Projekts MOA-ID-Auth als.war-datei mit SSO inkludiert Die Änderungen, die für SSO in MOA-ID vorgenommen werden müssen Die Source-Files für MOA-SSO moa-sso als lib Maven pom-file 22

Referenzen Referenzen [1] Security Assertion Markup Language (SAML), http://saml.xml.org/ [2] [3] [4] [5] [6] [7] Hal Lockhart, Brian Campbell, Security Assertion Markup Language (SAML) V2.0 Technical Overview, OASIS, Committee Draft 02, März 2008, http://www.oasis-open.org/committees/download.php/27819/sstc-saml-techoverview-2.0-cd-02.pdf Scott Cantor, John Kemp, Rob Philpott, Eve Maler, Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS, März 2005. http://docs.oasisopen.org/security/saml/v2.0/saml-core-2.0-os.pdf Scott Cantor, Frederick Hirsch, John Kemp, Rob Philpott, Eve Maler, Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS, März 2005. http://docs.oasisopen.org/security/saml/v2.0/saml-bindings-2.0-os.pdf John Hughes, Scott Cantor, Jeff Hodges, Frederick Hirsch, Prateek Mishra, Rob Philpott, Eve Maler, Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS, März 2005, http://docs.oasisopen.org/security/saml/v2.0/saml-profiles-2.0-os.pdf Scott Cantor, Jahan Moreh, Rob Philpott, Eve Maler, Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS, März 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0- os.pdf Rudolf Schamberger, Gregor Karlinger, Ludwig Moser, Spezifikation Module für Online Applikationen - ID, Version 1.4, August 2007 [8] Dokumentation Module für Online-Applikationen v1.4 23