Dokumentation - MOAs in der Cloud_v1.0
Werbung
www.egiz.gv.at E-Mail: [email protected] Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Dokumentation MOAs in der Cloud Version 1.0, 11. Juli 2012 Bernd Zwattendorfer – [email protected] Zusammenfassung: Die MOA-Module sind essentielle Kernkomponenten im österreichischen E-Government. MOA-ID im Speziellen beschäftigt sich mit der Identifizierung und Authentifizierung mittels Bürgerkarte bei Online Applikationen. Nachdem vermehrt Online Applikationen in die Cloud transferiert werden, wurde im Rahmen dieses Projekts analysiert, inwiefern sich MOA-ID auch für die Cloud eignet. Dabei wurde einerseits untersucht, ob man sich mittels Bürgerkarte und MOA-ID bei von Public Cloud Providern offerierten Diensten authentifizieren kann. Andererseits wurde erkundet, ob sich die aktuelle MOA-ID Version aus technischer Sicht für eine Deployment in der Public Cloud eignet. Als Ergebnisse können festgehalten werden, dass MOA-ID durch eine SAML 2.0 Erweiterung zur Authentifizierung bei Software as a Service-Anbietern wie Google Apps oder Salesforce geeignet ist. Weiters konnte MOAID durch entsprechende Anpassungen erfolgreich in der Public Cloud (bei Jelastic und auf der Google App Engine) deployed werden. Inhaltsverzeichnis: 1 2 3 4 5 Einleitung ..........................................................................................................................................4 Cloud Identitätsmodelle ....................................................................................................................5 2.1 Identität in der Cloud 5 2.2 Identität zur Cloud 5 2.3 Identität von der Cloud 6 Mögliche Cloud Anbieter ...................................................................................................................8 3.1 Cloud-Anbieter mit Authentifizierungsschnittstelle 8 3.2 Cloud Anbieter für ein Java PaaS-Modell 9 Verwendung von MOA-ID zur Cloud ..............................................................................................12 4.1 Authentifizierung über MOA-ID bei Google Apps 12 4.2 Authentifizierung über MOA-ID bei Salesforce 15 Verwendung von MOA-ID in der Cloud ..........................................................................................18 5.1 Deployment bei Jelastic 19 5.2 Deployment auf der Google App Engine 20 6 Zusammenfassung .........................................................................................................................23 Referenzen .............................................................................................................................................24 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz MOAs in der Cloud Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1 - Identität in der Cloud ......................................................................................................... 5 Abbildung 2 - Identität zur Cloud ............................................................................................................. 6 Abbildung 3 - Identität von der Cloud ...................................................................................................... 7 Abbildung 4 – Menü-Auswahl des Cloud Angebots von Jelastic .......................................................... 10 Abbildung 5 - Authentifizierung mittles MOA-ID bei Google Apps und Salesforce ............................... 12 Abbildung 6 - Google-Menü zum Eintrag von MOA-ID als Identity Provider ........................................ 14 Abbildung 7 - Authentifizierung bei Google Apps über MOA-ID ........................................................... 15 Abbildung 8 - Salesforce SAML Online Validierungsservice................................................................. 16 Abbildung 9 - Salesforce-Menü zum Eintrag von MOA-ID als Identity Provider ................................... 17 Abbildung 10 - Verwendung von MOA-ID in der Clodu........................................................................ 18 –2– MOAs in der Cloud Revision History Revision History Version Datum Autor(en) 0.1 09.05.2012 Bernd Zwattendorfer Dokumenterstellung 0.2 15.05.2012 Bernd Zwattendorfer Kapitel 2, 3 und 4 hinzugefügt 0.3 10.07.2012 Bernd Zwattendorfer Kapitel 5 hinzugefügt 1.0 11.07.2012 Bernd Zwattendorfer Finalisierung des Dokuments –3– MOAs in der Cloud Einleitung 1 Einleitung Identifizierung und Authentifizierung spielen sowohl bei Applikationen des behördlichen als auch des privatwirtschaftlichen Bereichs eine wichtige Rolle. Für eine eindeutige und sichere Identifizierung und Authentifizierung wird in Österreich die Bürgerkarte bzw. die HandySignatur verwendet. Um Betreibern von Online Applikationen diese Identifizierungs- und Authentifizierungsmöglichkeit mittels Bürgerkarte zu erleichtern, steht das Open Source Modul MOA-ID1 frei zum Download zur Verfügung, welches die Identitäts- und Authentifizierungsdaten einer Bürgerkartenanmeldung der Online Applikation in strukturierter Form bereitstellt. Cloud Computing ist nicht nur ein Hype in den Medien, sondern wird auch aufgrund der Kostenvorteile vermehrt eingesetzt. Auch Behörden beschäftigen sich mit dem Trend und verlagern zunehmend Applikationen in die Cloud. Hier tritt damit unweigerlich die Frage auf, ob auch sichere Authentifizierungsmechanismen wie die Bürgerkarte für eine Identifizierung in der Cloud geeignet sind. Im Rahmen dieses Projekts wurde daher untersucht, inwiefern eine Bürgerkartenauthentifizierung bei ausgewählten Public Cloud Providern möglich ist. Zu Testzwecken wurde eine Authentifizierung über MOA-ID mittels Bürgerkarte an den Public Cloud Providern Google und Salesforce getätigt. In weiterer Folge wurde im Rahmen dieses Projekts auch untersucht, ob nicht auch MOA-ID selbst in der Public Cloud betrieben werden könnte. Hierbei wurde ebenfalls ein Deployment bei zwei ausgewählten Cloud Service Providern (Google und Jelastic) durchgeführt. Bei diesen Deployment-Versuchen wurden nur technische Möglichkeiten analysiert und rechtliche Rahmenbedingungen außer Acht gelassen. Das weitere Dokument gliedert sich wie folgt. Der nächste Abschnitt beschreibt unterschiedliche Identitätsmodelle in der Cloud, Identität in der Cloud, Identität zur Cloud, und Identität von der Cloud. Im weiteren Dokument dient MOA-ID dabei als Identity Provider zur Cloud und von der Cloud. Abschnitt 3 beschreibt jene Cloud Service Provider, die einerseits von MOA-ID zur Identifizierung und Authentifizierung zur Cloud und andererseits als mögliche Deploymentplattform von MOA-ID selbst in der Cloud genutzt werden könnten. Die eigentliche Verwendung von MOA-ID zur Cloud wird in Abschnitt 4 beschrieben. Die Ergebnisse der Tests von einem MOA-ID Deployment in der Public Cloud werden in Abschnitt 5 zusammengefasst. Eine allgemein Zusammenfassung am Ende rundet dieses Dokument ab. 1 http://joinup.ec.europa.eu/software/moa-idspss/home –4– MOAs in der Cloud Cloud Identitätsmodelle 2 Cloud Identitätsmodelle Im Rahmen von Web Applikationen haben sich unterschiedliche Modelle fürs Identitätsmanagement etabliert. [PaGa07] beispielsweise klassifiziert die Identitätsmodelle im Web in einen „benutzer-zentrierten“, einen „zentralen“ und einen „föderierten“ Ansatz. Beim benutzer-zentrierten Ansatz befinden sich die persönlichen Daten der Benutzerin bzw. des Benutzers immer unter Kontrolle der jeweiligen Person. Beim zentralen Ansatz werden hingegen alle persönlichen Daten zentral bei einem Identity Provider gespeichert und verwaltet. Im Unterschied dazu werden beim föderierten Ansatz nicht alle Daten bei einem Identity Provider zentral, sondern bei mehreren Provider verteilt gespeichert. Identitäten und Authentifizierung spielen jedoch nicht nur bei klassischen Web Applikationen, sondern auch in der Cloud eine gewichtige Rolle. Die klassischen Identitätsmodelle können daher auch teilweise in die Welt der Clouds übertragen werden. [Goul10] beschreibt beispielsweise in seinem Whitepaper solche Modelle. Im Folgenden werden drei unterschiedliche Identitätsmodelle und -architekturen für die Cloud vorgestellt. 2.1 Identität in der Cloud Abbildung 1 zeigt das Identitätsmodell in der Cloud, wo die Identitätsdaten vom Cloud Service Provider selbst, der auch die Cloud Applikation hosted bzw. betreibt, verwaltet werden. In diesem Modell verschmelzen quasi Service Provider und Identity Provider. Die Benutzerkonnten und die dazugehörigen Daten sind also alle beim Cloud Service Provider gespeichert, befinden sich daher in der Cloud. Ein Vorteil dieses Modells ist, dass sich die Organisation, die ihre Applikation in die Cloud auslagert, sich zusätzlichen Aufwand und Kosten für die Benutzerverwaltung bzw. -registrierung erspart, da Benutzerprofile bzw. Accounts direkt vom Cloud Service Provider angeboten werden. Cloud Service Provider Identity Provider Cloud Applikation Abbildung 1 - Identität in der Cloud 2.2 Identität zur Cloud In diesem Modell wird der Identity Provider nicht vom selben Cloud Service Provider betrieben, der auch die Cloud Applikation betreibt. Die Identitätsinformationen bzw. auch die –5– MOAs in der Cloud Cloud Identitätsmodelle Authentifizierung von Benutzerinnen und Benutzern werden daher an diesen externen Identity Provider ausgelagert. Die Übertragung der Identitäts- und Authentifizierungsdaten vom Identity Provider zum Cloud Service Provider erfolgt dabei über geeignete Schnittstellen. Der Identity Provider muss daher nicht zwingend in der Cloud, sondern kann auch in einem lokalen Datencenter betrieben werden. Die Identitätsdaten werden daher zur Cloud übertragen. Dieses Identitätsmodell ist in Abbildung 2 dargestellt. Der Vorteil dieses Modells ist, dass eine bereits bestehende Benutzerverwaltung für Cloud Applikationen genutzt werden kann und keine neue Benutzerverwaltung oder Migration erfolgen muss. Während die Applikation in der Cloud betrieben wird, bleibt die Identitätsverwaltung in der Obhut bzw. im Kontrollbereich der eigenen Organisation. Cloud Service Provider Identity Provider Cloud Applikation Abbildung 2 - Identität zur Cloud 2.3 Identität von der Cloud In diesem Modell werden Identitäten von einem Identity Provider in der Cloud zur Verfügung gestellt. Die Identitätsdaten kommen daher von der Cloud. Aus diesem Grund kann dieses Modell auch als „Identity as a Service“-Modell bezeichnet werden. Dieses Modelle ähnelt zwar dem Modell aus Abschnitt 2.1 (Identität in der Cloud), jedoch muss in diesem Fall der Identity Provider nicht zwingend beim selben Cloud Service Provider betrieben werden, der auch die Cloud Applikation betreibt. Dieses Identitätsmodell wird in Abbildung 3 illustriert. Ein Vorteil dieses Modells ist, dass sich eine Organisation ihren Betreiber zur Benutzerverwaltung aussuchen kann und auf spezifische Anforderungen (z.B. Datenschutz und Speicherung der Identitätsdaten nur innerhalb eines bestimmten Bereichs bzw. Landes) besser eingehen kann, als bei Verwendung vom Identitätsmodell aus Abbildung 1. Ein weiterer Vorteil ist, dass die Benutzerverwaltung von der Organisation ausgelagert wird und somit Wartungsaufwand innerhalb der Organisation vermieden und Kosten gespart werden können. –6– MOAs in der Cloud Cloud Identitätsmodelle Abbildung 3 - Identität von der Cloud –7– MOAs in der Cloud Mögliche Cloud Anbieter 3 Mögliche Cloud Anbieter Dieses Kapitel liefert einen kurzen Überblick über ausgewählte Cloud Service Provider (CSP). Die in Abschnitt 3.1 vorgestellten Provider bieten eine „externe“ Authentifizierungsschnittstelle an. Über diese Schnittstelle kann MOA-ID als externer Identity Provider zur Authentifizierung bei Cloud Applikationen genutzt werden (vgl. Abschnitt 2.2 – Identitätsmodell zur Cloud). Abschnitt 3.2 beschreibt Cloud Service Provider, welche eine Java-basierte Plattform als Service (PaaS) anbieten. Auf solchen Plattformen könnte MOAID in der Cloud betrieben werden (vgl. Abschnitt 2.3 – Identitätsmodell von der Cloud). 3.1 Cloud-Anbieter mit Authentifizierungsschnittstelle Dieser Abschnitt beschreibt eine Auswahl von Cloud Service Providern, die eine Schnittstelle für externe Authentifizierungen anbieten. MOA-ID kann in diesem Fall als Identity Provider zur Authentifizierung bei Cloud Applikationen verwendet werden, muss aber nicht, wie im vorigen Abschnitt beschrieben, auch in der Cloud betrieben werden. 3.1.1 Google Apps Google Apps2 stellt im Prinzip ein Software as a Service (SaaS) Modell dar, welches von Google angeboten wird. Bei der angebotenen Software handelt es sich um Web Applikationen, die ähnliche Funktionen wie traditionelle Office Suites abbilden. Dabei handelt es sich unter anderem um die folgenden Produkte von Google: Gmail3, Google Calendar4, Google Docs5 oder Google Groups6. Um diese Anwendungen an Kundenwünsche entsprechend anpassen zu können, können diese Applikationen unter einer kundenspezifischen bzw. eigenen Domain betrieben bzw. aufgerufen werden. Google Apps kann derzeit kostenlos getestet werden. Für den Testbetrieb gibt es jedoch eine Einschränkung auf zehn Benutzerinnen- bzw. Benutzer-Accounts. Für den Zugriff auf diese Services von Google kann einerseits die interne Google Authentifizierung basierend auf Benutzername/Passwort genutzt werden. Andererseits bietet Google aber auf Basis von SAML 2.0 [SAML] auch eine Single Sign-On (SSO) Schnittstelle zum Einbinden von externen Identity Providern bzw. anderen Authentifzierungsmechanismen an. 3.1.2 Salesforce Salesforce7 ist ein Cloud Service Provider, der sowohl Software als auch Plattform as a Service anbietet. Salesforce hat sich speziell auf Geschäftsanwendungen spezialisiert. Bei der angebotenen Software handelt es sich hauptsächlich um Software zum Management für Kundenbeziehungen (CRM – Customer Relationship Management). Nebenbei bietet Salesforce.com aber noch andere Geschäftsanwendungen an, wie z.B. Applikationen für Vertrieb und Marketing (Sales Cloud8), Kundenservice (Service Cloud9) oder aber auch für 2 http://www.google.com/apps 3 http://mail.google.com/ 4 http://www.google.com/calendar 5 http://docs.google.com/ 6 http://groups.google.com/ 7 http://www.salesforce.com 8 http://www.salesforce.com/sales-cloud/overview/ –8– MOAs in der Cloud Mögliche Cloud Anbieter die Kommunikation im Unternehmen in Echtzeit (Chatter10). Diese Services können derzeit für 30 Tage kostenlos genutzt und getestet werden, danach wird eine entsprechende Gebühr fällig. In den einzelnen Applikationen können natürlich Benutzer-Konten, firmenintern sowie -extern für Kunden, angelegt werden. Zur Authentifizierung kann der Benutzername/PasswortMechanismus von Salesforce oder aber auch ein eigener Mechanismus über eine Schnittstelle verwendet werden. Wie auch Google bietet Salesforce die Möglichkeit, einen externen Identity Provider über eine SAML Schnittstelle einzubinden. Dabei kann auf die SAML Versionen 1.1 und 2.0 zurückgegriffen werden. 3.2 Cloud Anbieter für ein Java PaaS-Modell Dieser Abschnitt beschreibt eine Auswahl möglicher Cloud Service Provider, die ein Java PaaS-Modell anbieten und bei denen MOA-ID als Service in der Public Cloud betrieben werden könnte. 3.2.1 Jelastic Jelastic11 ist ein PaaS-Anbieter, welcher rein auf Java spezialisiert ist. Von Jelastic wird also eine Cloud Plattform als Service angeboten, auf der beliebige Java Web Applikationen deployed werden können. Die Registrierung bzw. die Auswahl der benötigten Ressourcen erfolgt einfach über ein Menü (siehe Abbildung 4). Im Gegensatz zu anderen PaaS Anbietern wird hier nicht nach verbrauchten Servern, sondern nach verbrauchten Ressourcen abgerechnet. Genauer gesagt wird in sogenannten „Cloudlets“ pro Stunde, welche eine definierte Menge an Arbeitspeicher und Rechenleistung (ca. 128MB RAM und 200MHz CPU Leistung) abbilden, abgerechnet. Vom Leistungsumfang bietet Jelastic eine Auswahl von unterschiedlichen Java Laufzeitumgebungen (Version 6 oder 7), mehreren Applikations-Servern bzw. Servlet Containern (Jetty 6, Tomcat 6 bzw.7, Glassfish 3), eine SQL-Datenbankuntersützung bzw. den Support für einen automatischen Software-Buildprozess mittels Maven. Um die für Cloud Computing notwendige Skalierbarkeit zu erreichen, können mehrere Server-Instanzen sowohl vertikal (Verwendung mehrer Cloudlets) als auch horizontal (parallele Instanzen wie beim klassischen Loadbalancing) aneinandergeschalten werden. Zusätzlich zu dieser Parallelisierung bietet Jelastic noch einen Loadbalancer auf Basis von Nginx12 an. Interessant an diesem Anbieter ist, dass die zugrundeliegende Infrastruktur nicht selbst angeboten, sondern von anderen Providern bezogen wird. Um beispielsweise Datenschutzanforderungen gerecht zu werden, bietet Jelastic eine Auswahl des Infrastruktur-Providers für Nordamerika, Europa, Russland und Japan an. 9 http://www.salesforce.com/service-cloud/overview/ 10 http://www.salesforce.com/chatter/overview/ 11 http://jelastic.com/ 12 http://nginx.org/ –9– MOAs in der Cloud Mögliche Cloud Anbieter Abbildung 4 – Menü-Auswahl des Cloud Angebots von Jelastic 3.2.2 Google App Engine Die Google App Engine ist ein Plattform as a Service-Angebot von Google zur Entwicklung und zum Hosten von Web Applikationen. Google unterstützt dabei drei Laufzeitumgebungen: Java, Python, und Go (Go vorerst nur in experimenteller Form). Nachdem Java als Plattform angeboten wird, eignet sich die Google App Engine auch prinzipiell für ein Hosting von MOAID. An dieser Stelle ist aber zu erwähnen, dass die Google App Engine keine vollständige Java Laufzeitumgebung (JVM) unterstützt, sondern aufgrund des Sandbox-Ansatzes, wo eine Applikation in einer geschützten Umgebung mit limitierten Rechten auf das zugrundeliegende Betriebssystem läuft, nur eine gewisse Anzahl an JRE-Klassen. Die genauen unterstützen Klassen werden in einer Whitelist13 veröffentlicht. So erlaubt die Google App Engine beispielsweise kein direktes Erstellen von und schreiben in Dateien im darunterliegenden Filesystem. Google unterstützt Java Version 5 und 6 und zusätzliche weitere Java Services wie z.B. zum Abspeichern von Objekten. Darunter fallen Java Data Objects14 (JDO) und die Java Persistence API15 (JPA), aber auch andere Services wie Mail oder Google Accounts16. Auch Google bietet zu Testzwecken eine kostenlose Nutzung der App Engine an. Dabei darf eine Benutzerin oder ein Benutzer maximal zehn Applikationen erstellen. Hier darf jede Applikation maximal 6,5h CPU-Stunden pro Tag verwendet werden. Der eingehende Datenfluss ist auf 1GB pro Tag beschränkt. Wird auf die Mail API zurückgegriffen, so dürfen max. 100 E-Mails pro Tag versendet werden. 13 https://developers.google.com/appengine/docs/java/jrewhitelist 14 http://www.oracle.com/technetwork/java/index-jsp-135919.html 15 http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html 16 https://accounts.google.com – 10 – MOAs in der Cloud Mögliche Cloud Anbieter 3.2.3 Sonstige Anbieter In diesem Abschnitt werden zur Vollständigkeit noch weitere Java-basierte PaaS-Anbieter gelistet, welche sich für ein Deployment von MOA-ID in der Cloud eignen könnten. Es sei an dieser Stelle darauf hingewiesen, dass bei keinem dieser Betreiber ein Deployment von MOA-ID versucht wurde. Mögliche Anbieter wären: Amazon AWS Elastic Beanstalk17 Red Hat Open Shift18 Heroku19 WSO2 StratosLive20 CloudBees21 Cumulogic22 AppFog23 17 http://aws.amazon.com/elasticbeanstalk/ 18 https://openshift.redhat.com/app/ 19 http://www.heroku.com/ 20 http://wso2.com/cloud/stratoslive/ 21 http://www.cloudbees.com/ 22 http://www.cumulogic.com/ 23 http://www.appfog.com/ – 11 – MOAs in der Cloud Verwendung von MOA-ID zur Cloud 4 Verwendung von MOA-ID zur Cloud Dieser Abschnitt beschreibt, wie MOA-ID zur Authentifizierung bei Cloud Applikationen als externer Identity Provider herangezogen werden kann. MOA-ID fügt sich daher in das Bild des Identitätsmodells aus Abschnitt 2.2. Abbildung 5 veranschaulicht noch einmal dieses Identitätsmodell, in dem MOA-ID als externer Identity Provider fungiert, der Identitätsdaten über eine entsprechende Schnittstelle der Cloud Applikation zur Verfügung stellt. Im Rahmen dieses Projekts wurde eine Authentifizierung über MOA-ID bei zwei unterschiedlichen Cloud Service Providern (Google und Salesforce) durchgeführt. Beide Cloud Service Provider offerieren eine solche Authentifizierungs- bzw. SSO-Schnittstelle über SAML. Während Google nur auf die Version 2.0 setzt, bietet Salesforce auch eine Authentifizierungsmöglichkeit über die ältere Version 1.1 an. Beide Anbieter offerieren neben SAML auch noch zusätzliche Authentifizierungsmöglichkeiten für externe Identity Provider wie beispielsweise OAuth24 oder OpenID25. OpenID wird jedoch nur von Google zusätzlich unterstützt. In den folgenden Unterabschnitten wird etwas genauer beschrieben, wie MOA-ID erweitert wurde, um diese Authentifizierungen durchführen zu können. Für die Erweiterungen und die Verwendung von MOA-ID als externer Identity Provider wurde auf die bei beiden Anbietern verfügbare SAML Schnittstelle zurückgegriffen. Abbildung 5 - Authentifizierung mittles MOA-ID bei Google Apps und Salesforce 4.1 Authentifizierung über MOA-ID bei Google Apps Um externe Identity Provider für eine Authentifizierung bei Google Apps einbinden zu können, offeriert Google eine entsprechende SSO-Schnittstelle auf Basis von SAML 2.0. Damit nun MOA-ID als ein solcher Identity Provider fungieren kann, musste MOA-ID um eine entsprechende SAML 2.0 Schnittstelle erweitert werden. Etwas genauer bezeichnet, setzt Google bei seiner Schnittstelle auf das SAML AuthnRequest/Response Protocol [CKP+09] sowie das HTTP Post Binding [CHK+09]. MOA-ID wurde also zu Testzwecken so erweitert, 24 http://oauth.net/ 25 http://openid.net/ – 12 – MOAs in der Cloud Verwendung von MOA-ID zur Cloud dass SAML AuthnRequest Nachrichten empfangen und SAML Response Nachrichten in der Version 2.0 retourniert werden können. Weitere Details zur SSO-Schnittstelle von Google Apps können unter [GCa] bzw. [GCb] gefunden werden, die Dokumentation ist aber nicht mehr am neusten Stand. So wird beispielsweise auf [GCb] angegeben, dass der zur Verfügung gestellte Referenz-Code für eine Authentifizierung mit Google Apps eigentlich veraltert und nicht mehr kompatibel ist. Bei der Implementierung hat sich des weiteren herausgestellt, dass die von MOA-ID zu Google übertragene SAML Assertion exakt den Vorgaben von Google entsprechen muss. Zusätzliche, aber laut SAML Spezifikation gültige SAML Elemente oder Attribute führten zu einem fehlerhaften Anmeldeversuch. Die Dokumentation zu Fehlermeldungen, die Google bereitstellt, ist leider auch eher spärlich und bedingt eine eher aufwendigere Fehleranalyse. Um MOA-ID generell bei Google Apps als Identity Provider zu registrieren, müssen folgende Werte von MOA-ID im Administrator-Menü eingetragen werden (siehe Abbildung 6): 26 Login-URL zum externen Identity Provider Dieser URL zeigt auf den Web Endpunkt bei MOA-ID, wo SAML AuthnRequest Nachrichten empfangen werden können. Logout-URL zum externen Identity Provider Nachdem MOA-ID nach erfolgreicher Anmeldung keine Sitzungen speichert, wird auch keine Logout-Funktionalität benötigt. Nachdem dieser Wert aber verpflichtend angegeben werden muss, kann einfach eine beliebige Seite angegeben werden, auf die eine Benutzerin oder ein Benutzer nach Logout bei Google Apps umgeleitet wird. URL zum Ändern von Passwörtern Auch diese Funktionalität wird von MOA-ID nicht benötigt, es kann einfach ein Dummy-Wert eingetragen werden. Signatur-Zertifikat zur Verifikation Dieses Zertifikat dient Google zur Überprüfung, ob SAML Response Nachrichten von MOA-ID korrekt signiert wurden26. Es ist also einfach das Signatur-Zertifikat, welches MOA-ID zum Signieren von SAML Nachrichten verwendet, hochzuladen. An dieser Stelle ist anzumerken, dass Google anscheinend keine Widerrufsprüfung durchführt, da SAML Nachrichten, welche mit einem revozierten Zertifikat signiert wurden, trotzdem als gültig anerkannt wurden. Es wird daher vermutlich nur ein Vergleich der Zertifikate durchgeführt. – 13 – MOAs in der Cloud Verwendung von MOA-ID zur Cloud Abbildung 6 - Google-Menü zum Eintrag von MOA-ID als Identity Provider Generell kann noch angemerkt werden, dass Google eine Identifizierung nur auf Basis von E-Mail Adressen durchführen kann. Das heißt, dass das von MOA-ID berechnete, und von der Stammzahl der Benutzerin bzw. des Benutzers abgeleitete bereichsspezifische Personenkennzeichen (bPK) für den privatwirtschaftlichen Bereich in ein entsprechendes EMail Format gemäß der bei Google Apps registrierten Domain gebracht werden muss. Nachdem aber E-Mail Adressen auch nicht alle Zeichen enthalten dürfen, die beim Base64kodierten bPK vorhanden sein können, wurde das von MOA-ID berechnete bPK vor dem Versand an Google in ein entsprechendes Format einer Base16-Kodierung gebracht. Ein beispielhafter von MOA-ID erstellter Identifikator für eine Anmeldung bei Google Apps sieht somit folgendermaßen aus: [email protected] Für eine erfolgreiche Anmeldung bei Google Apps muss dieser Identifikator zuvor in der Benutzerverwaltung registriert und die dazugehörigen Benutzerdaten angegeben werden. Eine nahtlose Registrierung nur mittels MOA-ID ohne vorherige Erstellung von BenutzerAccounts bei Google Apps ist nicht möglich. Abbildung 7 zeigt den Prozessablauf einer Authentifizierung bei Google Apps über MOA-ID. – 14 – MOAs in der Cloud Verwendung von MOA-ID zur Cloud https:// docs.google.com/a/ xyz.com/ Abbildung 7 - Authentifizierung bei Google Apps über MOA-ID 4.2 Authentifizierung über MOA-ID bei Salesforce Wie Google bietet auch Salesforce eine SAML Schnittstelle (Version 1.1 und 2.0) für eine Authentifizierung über einen externen Identity Provider an. Zur Übertragung von SAML Nachrichten wird ebenfalls das HTTP Post Binding verwendet, es wird jedoch kein spezielles SAML Protokoll unterstützt. Eine Authentifizierungsanfrage wird auch nicht über einen SAML AuthnRequest gestartet, sondern über den Aufruf einer bestimmten URL bei Salesforce. Details zu den verwendeten SAML Elementen und Attributen können unter [SF] gefunden werden. Obwohl Google und Salesforce beide eine SAML 2.0 Schnittstelle unterstützen, sind die Anforderungen und die ausgetauschten Nachrichten teilweise unterschiedlich. Aus diesem Grund musste die SAML 2.0 Erweiterung von MOA-ID auch auf die Gegebenheiten von Salesforce angepasst werden. Die Dokumentation von Salesforce dazu war wesentlich ausführlicher als bei Google, jedoch waren manchmal Fehlermeldungen ebenso nichtsausagend. Um die Gültigkeit der von einem externen Identity Provider (in diesem Fall MOA-ID) erstellten SAML Response Nachricht einfacher überprüfen zu können, bietet Salesforce ein eigenes Online Validierungsservice für solche Nachrichten an. Abbildung 8 zeigt dieses Validierungsservice, welches eine Fehlersuche bzw. –analyse auf Nachrichtenebene enorm vereinfacht. – 15 – MOAs in der Cloud Verwendung von MOA-ID zur Cloud Abbildung 8 - Salesforce SAML Online Validierungsservice Auch bei Salesforce muss mit MOA-ID als externer Identity Provider ein geeignetes Vertrauensverhältnis hergestellt werden. Dazu müssen im Administrator-Menü von Salesforce die folgenden Einträge gemacht werden (siehe Abbildung 9): SAML Version Hier kann zwischen SAML Version 1.1 und 2.0 unterschieden werden, MOA-ID wurde jedoch nur um die SAML 2.0 Unterstützung erweitert. Issuer Name des externen Identity Providers in der SAML Response Hier wurde der Server Name, auf dem MOA-ID betrieben wurde, angegeben. Signatur-Zertifikat des externen Identity Providers Dieses Zertifikat dient zur Überprüfung der Signatur der SAML Response Nachricht von MOA-ID. Identifikator von Benutzerinnen bzw. Benutzern in der SAML Response Unter diesem Menüpunkt kann angegeben werden, welcher Identifikator für Benutzerinnen bzw. Benutzer in der SAML Response enthalten ist. Entweder kann der Salesforce-Benutzername angegeben sein, welcher auch intern bei Salesforce verwendet wird, oder aber auch ein anderer Identifikator, mit dem eine Verknüpfung (Föderation) zum Benutzeraccount bei Salesforce hergestellt werden kann. Ort des Identifikators innerhalb der SAML Response Dieser Menüeintrag spezifiziert, ob der Identifikator in der SAML Response in einem speziellen Element von SAML (NameID Element) oder als SAML Attribut in der SAML Assertion angegeben ist. – 16 – MOAs in der Cloud Verwendung von MOA-ID zur Cloud Abbildung 9 - Salesforce-Menü zum Eintrag von MOA-ID als Identity Provider Hinsichtlich des Identifikators zur Identifizierung bei Salesforces gibt es im Gegensatz zu Google mehr Freiheiten. Entweder kann die SAML Assertion, die MOA-ID zur Authentifizierung bei Salesforce ausstellt, den Benutzernamen beinhalten, welcher auch bei Salesforce intern Verwendung findet, oder aber auch einen eigenen Identifikator, welcher mit dem Benutzerkonto bei Salesforce verknüpft werden kann. Nachdem MOA-ID selbst keine Benutzerverwaltung durchführt, wurde in der Umsetzung Variante zwei herangezogen. Als Identifikator diente ein für Salesforce entsprechend berechnetes bPK für den privatwirtschaftlichen Bereich, welches zur Identitätsföderation herangezogen werden konnte. Der von Salesforce verwendete Identifikator unterliegt keinerlei Einschränkungen, deshalb konnte die berechnete bPK ohne Umkodierungen bzw. -formatierungen genommen werden. An dieser Stelle sei noch zu erwähnen, dass bei Salesforce der Benutzeraccount vor einer Authentifizierung nicht zwingend bestehen muss. Es wären daher hier „on-the-fly“ Registrierungen von Benutzerinnen und Benutzern via MOA-ID möglich. – 17 – MOAs in der Cloud Verwendung von MOA-ID in der Cloud 5 Verwendung von MOA-ID in der Cloud Im Prinzip beschreibt auch dieses Kapitel, wie MOA-ID zur Authentifizierung von Cloud Applikationen herangezogen werden kann. Im Gegensatz zu Abschnitt 4, wo MOA-ID zur Authentifizierung zur Cloud verwendet wurde, beschäftigt sich dieser Abschnitt zusätzlich damit, wie MOA-ID auch in der Cloud betrieben werden kann. MOA-ID fügt sich daher in das Bild des Identitätsmodells aus Abschnitt 2.3, welches in Abbildung 10 nochmals veranschaulicht wird. Abbildung 10 - Verwendung von MOA-ID in der Clodu In den folgenden Unterkapiteln wird beschrieben, was gemacht wurde bzw. welche Änderungen notwendig waren bzw. wären, um MOA-ID aus technischer Sicht erfolgreich in der Cloud zu betreiben. Dabei wird das Deployment von MOA-ID bei Jelastic und in der Google App Engine anhand unterschiedlicher Kriterien, die in Tabelle 1 dargestellt sind, betrachtet. Tabelle 1- Kriterien für ein Deployment von MOA-ID in der Cloud Kriterium Beschreibung IAIK Security Provider Hier wird beim Deployment betrachtet, inwiefern ein eigener Security Provider, wie z.B. der IAIK Security Provider, welcher von MOA-ID benötigt wird, auch auf der Cloud Plattform verwendet werden kann. MOA-ID Konfiguration Dabei wird untersucht, inwiefern die Standard-Konfiguration von MOA-ID auch in der Cloud verwendet werden kann oder ob auf andere Konfigurationsmöglichkeiten umgestellt werden müsste. XML-Parser Libraries MOA-ID verwendet das /endorsed-Verzeichnis von Tomcat, damit immer die aktuellsten XML-Parser zum Einsatz kommen können, ohne in die Applikation selbst eingreifen zu müssen. Anhand dieses Kriteriums wird untersucht, ob auch der /endorsed-Mechanismus bei den Cloud Anbietern gegeben ist. – 18 – MOAs in der Cloud Verwendung von MOA-ID in der Cloud Kriterium Beschreibung Logging MOA-ID verwendet log4j27 als Logging-Framwork mit einer voreingestellten Konfiguration. Es wird getestet, ob auch in der Cloud log4j als Logging-Framework für MOA-ID geeignet ist und ob die bestehende Konfiguration verwendet werden kann. Root Context Hier wird geprüft, ob MOA-ID im gewohnten Root Context (https://domain/moa-id-auth) aufgerufen werden kann. Threads MOA-ID verwendet Threads zum Löschen von alten Authentifizierungssessions. Es wird untersucht, ob Threads auch von den Cloud Plattformen unterstützt werden. Sockets MOA-ID verwendet Sockets zum Aufrufen von externen Verbindungen. Es wird untersucht, ob Sockets auch von den Cloud Plattformen unterstützt werden. Eigene Domain und SSL Die Verwendung einer eigenen Domain ist speziell für E-Government Applikationen wichtig. Auch ein eigenes SSL-Zertifikat kann von Nöten sein, wenn die Dienstleister- bzw. Verwaltungseigenschaft enthalten sein soll. Hier wird geprüft, inwiefern für MOA-ID in der Cloud eine eigene Domain bzw. ein eigenes SSL-Zertifikat verwendet werden kann. 5.1 Deployment bei Jelastic Jelastic kann eher als eine Mischung aus Infrastructure as a Service (IaaS) und Plattform as a Service (PaaS) Provider angesehen werden. Man hat hier zwar keinen direkten Zugriff auf das Betriebssystem, jedoch kann man sich den Applikationsserver für das Deployment der Applikation aussuchen und hat Zugriff auf die entsprechenden Konfigurationsdateien via eines Webbasierten Editors. Jelastic ist ein rein Java-basierter PaaS Provider und somit ist auch ein Deployment von MOA-ID aus technischer Sicht ohne Probleme möglich. Es gibt auch keine Einschränkung hinsichtlich APIs, gegen die programmiert werden muss, sondern es steht eine komplette JRE Laufzeitumgebung zur Verfügung. Im Folgenden wird trotzdem kurz beschrieben, welche Änderungen an der MOA-ID Installationsroutine vorgenommen werden mussten, um MOA-ID erfolgreich bei Jelastic deployen zu können. IAIK Security Provider: Bei Jelastic hat man zwar keinen direkten Zugriff auf die Dateistruktur der Java Laufzeitumgebung, jedoch kann man beliebige jar-Files in ein Verzeichnis hochladen und mittels Konfigurationsfile angeben, dass diese von der Java Virtuellen Maschine geladen werden. So konnten auch die IAIK Security Libraries (iaik-jce.jar, etc.), die von MOA-ID benötigt werden, einfach in die Java Laufzeitumgebung eingebunden werden. Dabei wurde folgende System Property Djava.ext.dirs=/usr/java/latest/jre/lib/ext:/opt/tomcat/temp/extlibs in der Datei variables.conf hinzugefügt. MOA-ID Konfiguration: Die MOA-ID Konfiguration kann wie bisher auch bei Jelastic mittels System Property geladen werden. Diese Umgebungsvariablen müssen für den Start des Tomcats in der Datei variables.conf eingetragen werden. Theoretisch reicht es, wenn hier der absolute Pfad zu 27 http://logging.apache.org/log4j/2.x/ – 19 – MOAs in der Cloud Verwendung von MOA-ID in der Cloud einer beliebigen Stelle im Dateisystem zur Konfiguration angegeben wird. Praktisch gibt es bei Jelastic aber das Problem, dass keine ganzen Verzeichnisse sondern nur einzelne Dateien auf die Server hochgeladen werden können. Aus diesem Grund musste das Konfigurationsverzeichnis von MOA-ID in die war-File für den Upload gepackt werden. Das Konfigurationsverzeichnis wurde beim Deployment automatisch entpackt, und es musste nur der entsprechende Pfad zur Konfiguration angepasst werden. XML-Parser Libraries: Für Libraries wie z.B. XML Parsern, bei denen es häufiger vorkommt, dass sich die Versionen ändern, gibt es sowohl in Java als auch bei den meisten Applikationsservern ein sogenanntes /endorsed-Verzeichnis, wo Library-Updates einfach eingespielt werden können, ohne die Applikation zu verändern. Von der Class-Loading-Hierarchie werden die Libraries aus dem /endorsed-Verzeichnis gegenüber den Libraries aus der Applikation mit höherer Priorität behandelt. Auch MOA-ID nützt diese Funktionalität für einzelne XML-Parser Libraries. Jelastic bietet zwar kein eigenes /endorsed-Verzeichnis, jedoch reicht es, die XMLParser Libraries in das zur Verfügung gestellte /lib-Verzeichnis zu kopieren, da diese auch hier bevorzugt beim Classloading behandelt werden. Logging: Die von MOA-ID bereitgestellte Logging-Konfiguration über das Logging-Framework log4j benötigt keinerlei Anpassung. Alle Log-Meldungen werden in den entsprechenden Dateien im /log-Verzeichnis des Jelastic-Tomcats abgelegt. Root Context: Bei einem normalen Deployment einer war-File auf einem Applikationsserver wird als Root Context üblicherweise der Name der war-Datei herangezogen, so auch für MOA-ID. Bei Jelastic ist dieser Mechanismus ident, deswegen mussten dafür keine Änderungen vorgenommen werden. Threads: Threads werden von Jelastic ohne weiteres unterstützt, hier sind keine Anpassungen von MOA-ID notwendig. Sockets: Sockets werden von Jelastic ohne weiteres unterstützt, hier sind keine Anpassungen von MOA-ID notwendig. Eigene Domain und SSL: Die Verwendung von SSL kann einfach bei der Auswahl der benötigten Ressourcen ausgewählt werden. Es kommt dabei ein von Jelastic bereitgestelltes SSL-Zertifikat zum Einsatz. Dieses Zertifikat ist jedoch auf die Domain des Jelastic Hosters (z.B. app.jelastic.dogado.eu) beschränkt. Eigene Domains und somit eigene SSL-Zertifikate werden derzeit von Jelastic nicht unterstützt. 5.2 Deployment auf der Google App Engine Das Plattform as a Service Modell von Google (Google App Engine) unterstützt mehrere Laufzeitumgebungen, darunter auch Java. Da auch MOA-ID auf Java basiert, wurde die Google App Engine Plattform zu Testzwecken herangezogen, und es wurde untersucht, inwiefern sich MOA-ID für ein Deployment auf der Google App Engine eignet. Im Rahmen dieser Untersuchung wurden nur technische Möglichkeiten erarbeitet und z.B. rechtliche Rahmenbedingungen außen vor gelassen. Rechtliche Rahmenbedingungen erschweren vermutlich den Betrieb von MOA-ID auf der App Engine für E-Government Zwecke. Nichtsdestotrotz könnte MOA-ID für privatwirtschaftliche Zwecke als Service in der Cloud betrieben werden. – 20 – MOAs in der Cloud Verwendung von MOA-ID in der Cloud Im Folgenden wird beschrieben, welche Änderungen notwendig sind bzw. wären und welche Einschränkungen hinzunehmen sind, um MOA-ID vollständig in der Cloud auf der Google App Engine betreiben zu können. Allgemeine Probleme und Änderungen für ein Google App Engine Deployment von MOA-ID: IAIK Security Provider: Laut Dokumentation und diversen Forumsbeiträgen unterstützt die App Engine keinen anderen Security Provider wie z.B. jenen von MOA-ID verwendeten IAIK Security Provider. Diese Problematik konnte jedoch bei der zugrundeliegenden Untersuchung - zumindest unter der Verwendung von Java 7 - nicht bestätigt werden. Die Signatur-Überprüfung innerhalb MOA-ID erfolgte problemlos auf der Google App Engine. Die dazu notwendigen Dateien (iaik-jce.jar, etc.) mussten jedoch in das Applikationsverzeichnis /WEB-INF/lib kopiert werden, da Google keinen Zugriff auf das zur Laufzeitumgebung interne Verzeichnis %JAVA_HOME%/jre/lib/ext gewährt. Außerdem darf bei den verwendeten Libraries nur eine unsignierte Version verwendet werden, da die Google App Engine keine signierten jar-Files unterstützt28. XML-Parser Libraries: Die Google App Engine stellt kein eigenes /endorsed-Verzeichnis zur Verfügung, deshalb müssen die bei einer MOA-ID Installation normalerweise in dieses Verzeichnis kopierten XML-Parser Libraries direkt in die Applikation integriert und bei notwendigen Updates in der Applikation geändert werden. MOA-ID Konfiguration: In der klassischen MOA-ID Variante wird der Pfad der Konfiguration sowohl für MOA-ID als auch für MOA-SPSS über eine System Property angegeben. Diese System Property zeigt dabei auf eine spezifische Datei bzw. auf ein spezifisches Verzeichnis im Dateisystem. Da die Google App Engine die Applikationen nur in einer Sandbox laufen lässt, kann der Zugriff auf die Konfiguration nicht gewohnt erfolgen. Um die Konfiguration wie gewohnt laden zu können, musste die Konfiguration einerseits komplett in das Applikationsverzeichnis verschoben werden und andererseits der MOA-ID Code so verändert werden, dass die Konfiguration als Applikationsressource geladen werden kann. Ein weiteres Problem stellt generell die MOA-SPSS Konfiguration dar, da hier beispielsweise versucht wird, das Enduser-Zertifikat im Filesystem abzuspeichern. Für Testzwecke wurde dieser Mechanismus deaktiviert. Um MOA-ID besser an die Einschränkungen der Google App Engine anpassen zu können, könnte die Konfiguration beispielsweise an einen entfernten Server ausgelagert und via Web Service geladen werden, oder aber an eine der drei von der Google App Engine angebotenen Datenspeicherservices (App Engine Datastore, Google Cloud SQL, Google Cloud Storage)29 ausgelagert und geholt werden. Logging: MOA-ID verwendet log4j als Standard-Logging Framework. Die standardmäßig von MOA-ID ausgelieferte Konfiguration für dieses Framework sieht die Ausgabe von Log-Meldungen in eine Datei vor. Dies ist aus Sandbox-Gründen bei der Google App Engine nicht möglich. Deshalb musste das Speichern von Log-Meldungen von einer Datei auf die Standardausgabe von Google umgestellt werden. Eine weitere Möglichkeit, das Logging zu verbessern, wäre die Verwendung von Remote Logging-Mechanismen, sodass die LogMeldungen auf einem entfernten Server abgespeichert werden. Root Context: 28 https://developers.google.com/appengine/docs/java/runtime 29 https://developers.google.com/appengine/docs/java/datastore/ – 21 – MOAs in der Cloud Verwendung von MOA-ID in der Cloud Wird das ausgelieferte MOA-ID Webmodul in einer Servlet Engine wie z.B. Apache Tomcat deployed, so ist üblicherweise der Dateiname der war-File gleichzeitig auch der dazugehörige Kontextpfad der Applikation (z.B. http://domain/moa-id-auth). Diese Verhaltensweise wird von der Google App Engine nicht unterstützt; defaultmäßig wird eine Applikation in den Root Context deployed. Um dennoch einen applikationsspezifischen Pfad verwenden zu können, muss in der Google App Engine spezifischen Konfigurationsdatei appengine-web.xml folgender Eintrag mit dem gewünschten Kontextpfad hinzugefügt werden: public-root>/moa-id-auth</public-root> Threads: MOA-ID ist standardmäßig so implementiert, dass erstellte Authentifizierungs-Sessions und dazugehörige Informationen nach einem gewissen Zeitintervall automatisch aus dem Speicher gelöscht werden. MOA-ID hat diese Funktionalität mittels Threads implementiert. Threads werden jedoch von der Google App Engine nur bedingt unterstützt, deshalb sollte auf alternative Möglichkeiten wie z.B. die Task Queue API30 von Google zurückgegriffen werden. Sockets: Code-Teile von MOA-ID bauen auf der Verwendung von Sockets auf (z.B. die Kommunikation Stammzahlenregister-Gateway). Das Öffnen von Sockets wird aber von der Google App Engine nicht unterstützt, deshalb sollte für die Kommunikation mit anderen Hosts via http oder https auf die von Google bereitgestellte URL Fetch Java API31 aufgebaut werden. Eigene Domain und SSL: Defaultmäßig werden Google App Engine Applikationen unter einer .appspot.com domain deployed (z.B. moa-id-auth.appspot.com). Soll die Applikation auch HTTPS Anfragen unterstützen, so kann mit einer einfachen Konfigurationsänderung in der Datei appengineweb.xml (<ssl-enabled>true</ssl-enabled>) auch der Zugriff via SSL aktiviert werden. Bisher konnte jedoch nur das von der Google App Engine bereitgestellte SSLZertifikat dafür verwendet werden. Seit geraumer Zeit besteht jedoch die Möglichkeit, nicht nur die .appspot.com Domain zu verwenden, sondern seine eigene Domain mit eigenem SSL-Zertifikat. Details dazu können unter [GDa] nachgelesen werden. Dieses Service ist jedoch kostenpflichtig und beläuft sich auf 9$ für fünf Zertifikate pro Monat. 30 https://developers.google.com/appengine/docs/java/taskqueue/ 31 https://developers.google.com/appengine/docs/java/urlfetch/ – 22 – MOAs in der Cloud Zusammenfassung 6 Zusammenfassung MOA-ID ist eine essentielle Kernkomponente im österreichischen E-Government. MOA-ID erleichtert Online Applikationen die sichere und eindeutige Identifizierung und Authentifizierung mittels Bürgerkarte. Nachdem einige Behörden bereits danach streben, ihre Online Applikationen in die Cloud zu bringen, um Kosten zu sparen, kann auch daran gedacht werden, einerseits MOA-ID in die Cloud zu bringen bzw. andererseits MOA-ID für die Authentifizierung von Cloud Applikationen zu verwenden. Im Rahmen dieses Projekts wurden beide Möglichkeiten auf technischer Ebene untersucht. Um eine Authentifizierung mittels Bürgerkarte bei Cloud Applikationen zu ermöglichen, wurde MOA-ID zu Testzwecken um eine SAML 2.0 Schnittstelle erweitert. Diese Schnittstelle wurde genau auf die beiden Cloud Service Provider, bei denen im Rahmen dieses Projekts eine mögliche Authentifizierung untersucht wurde, abgestimmt. Als Resultat konnte eine Authentifizierung mittels Bürgerkarte sowohl bei Google Apps als auch bei Salesforce erfolgreich durchgeführt werden. Im zweiten Teil des Projektes wurde analysiert, inwiefern sich die aktuelle MOA-ID Version für eine Deployment in der Public Cloud eignet. Als Ergebnis kann sowohl ein erfolgreiches Deployment bei Jelastic als auch auf der Google App Engine präsentiert werden. Für beide Cloud Service Provider waren jedoch entweder Anpassungen in der MOA-ID Installationsroutine und/oder Änderungen im Source Code notwendig. Letztendlich kann festgehalten werden, dass MOA-ID mit gewissen Änderungen für einen Einsatz in der Cloud geeignet ist, sofern vorerst nur technische Rahmenbedingungen beachtet werden. – 23 – MOAs in der Cloud Referenzen Referenzen [CHK+09] Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and Maler, E. (2009). Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS. [CKP+09] Cantor, S., Kemp, J., Philpott, R., and Maler, E. (2009). Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS. Google Code: SAML Single Sign-On (SSO) Service for Google Apps, [GCa] http://code.google.com/googleapps/domain/sso/saml_reference_implement ation.html [GCb] Google Code: Web-based Reference Implementation of SAML-based SSO for Google Apps, http://code.google.com/googleapps/domain/sso/saml_reference_implement ation_web.html [GDa] Google Developer: SSL for a Custom Domain, https://developers.google.com/appengine/docs/ssl [Goul10] J. Goulding: identity and access management for the cloud: CA’s strategy and vision, Whitepaper, Mai 2010, CA Cloud Business Unit [PaGa07] J. Palfrey, U. Gasser: Digital Identity Interoperability and eInnovation, Case Study, November 2007, Berkman Publication Series [SAML] Security Assertion Markup Language (SAML), OASIS Security Services (SAML) TC, http://www.oasisopen.org/committees/tc_home.php?wg_abbrev= security [SF] Salesforce.com: Single Sign-On Implementation Guide, 2012, https://login.salesforce.com/help/doc/en/salesforce_single_sign_on.pdf – 24 –
