Sicherheitsmanagement von SOA Plattformen

Transkript

1 Diplomarbeit in Computer Networking Sicherheitsmanagement von SOA Plattformen Referent: Prof. Dr. Christoph Reich Korreferent: Dipl. Inf. (Fh) Joachim Saleyka vorgelegt am: 29. Februar 2008 vorgelegt von: Harald Schwecht Feuerwehrstraße 27, Lahr

2

3 i Abstrakt Die steigende Anzahl an Webanwendungen und Web Services bietet dem modernen Benutzer umfangreiche Möglichkeiten, für die er sich jedoch einzeln anmelden muss. Das Internet2- Konsortium hat ein Verfahren zur Authentifizierung und Autorisierung entwickelt, damit ein Authentifizieren nur einmal und ortsunabhängig ausreicht und dennoch hochgradig sicher ist (engl. Single Sign-On). Diese Diplomarbeit beschreibt das Sicherheitskonzept von Shibboleth und die Anbindung von Serviceorientierten Architekturen.

4

5 Inhaltsverzeichnis 1 Einleitung 3 2 Dienste Definition Merkmale Wesentliche Bestandteile Dienstarten Wertschöpfender Dienst Unterstützender Dienst Technischer Dienst Dienst als Enterprise Application Integration Dienst als Webservice Dienstanbieter Dienstverzeichnis Dienstkonsument Authentifizierung Autorisierung Zusammenfassung SOA Definition Merkmale einer guten SOA Bausteine einer SOA (Fach-)Dienste Service-Meditation-System Service Registry Service Repository Enterprise Application Integration Kritik Zusammenfassung Single Sign-On 25

6 iv Inhaltsverzeichnis 4.1 Definition Einleitung Kategorisierung OpenSSO Access Manager Architecture SAML Service Federation Service Shibboleth Zusammenfassung SAML Definition Historie Bestandteile Assertions Protocol Bindings Profiles Stand Zusammenfassung Shibboleth Definition Einleitung Bausteine einer Sitzung SSO Mechanismus Schutz der Pfade Lazy Session Full Session Servervariablen Föderation Shibboleth Zusammenfassung Single Sign-On an der HFU Einleitung Shibboleth Service Provider Installation Shibboleth Service Provider Konfiguration Metadaten Attribute

7 Inhaltsverzeichnis v Attribute Resolver Attribute Resolution Test Attribute Release Policy Attribute Release Test Attribute Acceptance Policy Service Provider anbinden OLAT (Online Learning And Training) SMS-Infosystem Dienst zum Ändern der RZ-Daten Verantwortung durch SSO Zusammenfassung OLAT an der HFU konkretisiert Einleitung Installation Apache Tomcat OLAT Konfiguration von Apache und Tomcat OLAT mit Eclipse entwickeln Eclipse im Betrieb Anmerkung zu Imports Extension-Konzept von OLAT Automatische Benutzer-Registrierung Orginaler Registrierungsvorgang Zusammenfassung Resumee Ideen Zentraler Logout bzw. Single Logout-Dienst Kerberos Ticket statt Workaround Literaturverzeichnis 97 A Shibboleth Konfiguration 101 B Eidesstattliche Erklärung 109

8

9 Abbildungsverzeichnis 2.1 Einzelne Applikationen in der IT-Landschaft Gesamtprozess einer EAI Magisches Dreieck Intergrationsunterschiede EAI-Topologien in der Praxis Access Manager Internal Architecture SAML SOAPHTTP binding Shibboleth Mechanismus Shibboleth Föderation Screenshot Verzeichniseintrag Abgelehnte Autorisierung Erweiterbarkeit von OLAT durch eine Extension Aufruf des ShibbolethAutoRegistrationController ShibbolethAutoRegistrationController mit UserMapping Auto-Registration Bildschirmfoto OLAT HFU Disclaimer Provider-Einträge

10

11 Tabellenverzeichnis 3.1 Zur Laufzeit messbarer Eigenschaften und SOA Nicht zur Laufzeit messbarer Eigenschaften und SOA

12

13 Listings 5.1 Beispiel einer SAML Assertion Beispiel für ein SAML AuthenticationStatement Beispiel für ein SAML AttributeStatement Beispiel für ein AuthorizationDecisionStatement Beispiel für ein SAML Request Beispiel für ein SAML Response Beispiel für ein SOAP Envelope Beispiel einer IdP-URL bei WAYF Beispiele für Verzeichnisschutz mit Apache Lazy Session shibboleth.xml für Lazy Session shibboleth.xml für Full Session Verzeichnisschutz mit Full Session Liste von Shibboleth Servervariablen Zugriff zu Servervariablen Betriebssystem des Dienstservers Suche nach RPM Paketen Installation des Shibboleth Service Providers Übersicht der Paketquellen SSL-Konfiguration des Servers Metadaten des Service Providers Verzeichnisschutz mit Apache Verzeichnisschutz der Dienste Beispiel einer Attribute Release Policy Beispiel eines Attribute Rule der AAP VirtualHost Konfiguration des Servers openldap angepasst A.1 Metadaten der Hochschule Furtwangen University A.2 Beispiel eines Attribute Release Tests

14

15 Listings 1

16

17 1 Einleitung Diese Diplomarbeit geht aus Recherchen und der praktischen Umsetzung einer Single Sign-On Umgebung an der Hochschule Furtwangen University hervor. Der Schwerpunkt ist die Auseinandersetzung mit den Konzepten der Service-orientierten Architektur (SOA) und den Aspekten der Absicherung von Webservern für die Anbindung von Diensten. Dabei werden Merkmale und Bausteine einer SOA und ihre Funktionalitäten besonders hervorgehoben. Andererseits soll SOA auch einem kritischen Blick unterworfen werden. Die Mechanismen zur Realisierung einer Authentifizierung über Single Sign-On sowie die Vielfalt zur Autorisierung von Benutzern an Diensten werden untersucht. Unter anderem wurde ein Dienst der Hochschule, genauer gesagt ein Learning Management System, um eine Automatische Benutzer-Registrierung erweitert und eine Möglichkeit implementiert, daraus auf andere Dienste über Single Sign-On zugreifen zu können. Der Aufbau der Diplomarbeit ist so konzipiert, dass über das Granulare - die Dienste - der Blickwinkel auf SOA ausgeweitet wird und sich daraus über die Sicherheitsspezifikation SAML ausdehnt. Diese wird als Grundlage genutzt, um die Konzepte von Single Sign-On zu analysieren und deren Grenzen am Beispiel mit dem Single Sign-On Framework Shibboleth auszuloten. Im Konkreten werden diese Erkenntnisse mit den praktischen Erfahrungen an der Hochschule Furtwangen University angewendet.

18

19 2 Dienste In diesem Kapitel soll der wichtigste Bestandteil einer Service-orientierten Architektur (SOA) - der Dienst - thematisiert werden, um eine Basis für den Einstieg in die folgenden Kapitel zu bieten. Zunächst wird eine allgemeine Definition des Begriffs Dienst (engl. Service) aufgestellt und anschließend seine wesentlichen Bestandteile kurz erläutert. Weiterhin wird auf die Auslegung des Begriffs Dienst als Enterprise Application Integration einer SOA sowie auf den Begriff Dienst im Sinne von Webservice eingegangen und dabei zwischen den verschiedenen Dienstarten unterschieden. Da der Aspekt Authentifizierung für Webservices bereits eine wichtige Rolle spielt, wird dieser definiert, wobei auf das Eingehen auf den Mechanismus bewusst verzichtet wird. Schließlich wird der Aspekt Autorisierung definiert und dabei erläutert, wie dadurch der Zugriff zum Dienst selektiv eingeschränkt werden kann. 2.1 Definition A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. 1 Ein Dienst im Sinne der SOA ist eine Komponente mit wohldefinierter und wiederverwendbarer Funktionalität Merkmale Ein Dienst besitzt mindestens eine Fähigkeit, die er auch anbieten muss. Diese Fähigkeit besteht darin, Arbeit für einen Dienstkonsumenten (engl. service consumer) zu verrichten. Die auszuführende Arbeit muss spezifiziert sein. 1 Vgl. MacKenzie, Ref. model for soa, S Vgl. Starke/Tilkov, SOA Expertenwissen, S.142.

20 6 2 Dienste Der Dienst muss bei Anfrage entsprechend der Spezifikation handeln. visibility: Der Dienst muss für den Dienstkonsumenten sichtbar/auffindbar sein. real world effect: Der Dienstaufruf muss, unabhängig vom Aufrufkontext, einen Effekt haben. (Als typische Effekte werden z.b. die Rückgabe eines Rechenergebnisses oder einer Zustandsänderung gewertet.) interaction: Um einen Effekt zu erhalten, muss eine Aktivität im Sinne von Interaktion ausgeübt werden. Ein Dienst kann andere Dienste aufrufen, wenn Bedarf existiert. Ein Dienst muss, laut [KaCh08], Technologie-agnostisch sein, d.h. im übertragenen Sinne wird angenommen, dass der Dienst im Unklaren darüber ist, welche Hard- oder Softwareplattform zu seiner Nutzung eingesetzt wird. Idealerweise, interoperiert ein Dienst mit jedem möglichen Dienstkonsumenten. Lose Kopplung: Verschiedene Dienste sind nicht von einander abhängig. 3 Abstraktion: Zur Nutzung des Dienstes muss nicht bekannt sein, welche Vorgänge darin vorgehen. 4 Autonomität: Der Dienst hat eine klar abgegrenzte Funktionalität, die keine Überlappung mit anderen Diensten darstellt Wesentliche Bestandteile In einer SOA stellen Dienste den Mechanismus dar, durch den Bedürfnisse und Potentiale zusammen gebracht werden. 6 Paradigma von SOA: Services sind das fundamentale Element für die Erstellung von Anwendungen. 7 Schnittstelle Über die beschriebene Schnittstelle wird Zugang zum Dienst gewährt und damit zu den darunter liegenden, angebotenen Fähigkeiten. Sie spezifiziert wie der Zugriff geschehen soll. 8 Eine gute Service-Schnittstelle ist selbsterklärend, hat eine ausgereifte Fehlerbehandlung, nimmt nur genau definierte Parameter an und gibt nur genau definierte Parameter zurück. 9 3 Vgl. Starke/Tilkov, SOA Expertenwissen, S.142f. 4 ebenda. 5 ebenda. 6 Vgl. MacKenzie, Ref. model for soa, S.9. 7 Vgl. Liebhart, SOA goes real, S Vgl. MacKenzie, Ref. model for soa, S Vgl. Liebhart, SOA goes real, S.163.

21 2.3 Wesentliche Bestandteile 7 Beschreibung Unterscheidung der fachlichen und technischen Repräsentation. 10 Dabei umfasst die fachliche Repräsentation die geschäftsrelevanten Funktionen, sowie organisatorische Informationen, wie (die Verantwortlichkeit,) eine verantwortliche Ansprechperson (service owner), den SLA (Service Level Agreement) und ggf. wichtige Angaben wie z.b. Kosten der Servicenutzung. Zur fachlichen Repräsentation kann man auch planerische Informationen zählen, welche die Rahmendaten für das Rollout eines Service beschreiben, d.h. wann und wie ein Service in welcher Form verfügbar ist. Die technische Repräsentation umfasst den Service Contract. Dieser beschreibt die Funktionalität, die Abhängigkeiten und ggf. verfügbare Testszenarien des Dienstes. 11 LIEBHART empfiehlt der Beschreibung zusätzlich eine Reihe von Zuständen zuzuordnen, die einen Lebenszyklus für Dienste definieren. Dies könne ein Mittel sein, um eine Abstimmung von Planung und Durchführung von laufenden Projekten mit dem Rollout von Diensten zu erreichen. Mögliche Zustände wären hierbei: Requested, Planned, Tested, Implemented, Completed, Productive, Deprecated und Decommited. Da die Zustände selbsterklärend sind, wird für deren Details auf die Literatur verwiesen. 12 Informationen, um mit dem Dienst zu interagieren; Informationen, was vollbracht wird, sobald der Dienst ausgeführt wurde; Bedingungen, u.u. auch Regeln (engl. policies), um den Service benutzen zu können. 13 Durch die Beschreibung kann der Dienstkonsument somit feststellen, ob der Dienst seinen Bedürfnissen entspricht. Implementierung Für einen Benutzer bleibt durch Kapselung die Implementierung des Dienstes verborgen, da lediglich die Beschreibung der Schnittstelle von Interesse ist, um den Dienst nutzen zu können. 14 Dadurch ist die Implementierung nicht an eine Programmiersprache gebunden. Im Idealfall könnte man die Implementierung eines Dienstes zu einem späteren Zeitpunkt durch ein effizienteres Äquivalent in einer anderen Programmiersprache ablösen, ohne dass eine der nutzenden Anwendungen auch nur neu gestartet werden müsste, denn die Nutzer eines Dienstes haben ausschließlich eine Abhängigkeit zur Schnittstelle des Dienstes. ßelbstverständlich muss die Implementierung einer Schnittstelle der Schnittstelle selber entsprechen." 15 Die Implementierung besteht aus Geschäftsfunktionen, die Geschäftslogik aufbauen und 10 Vgl. Starke/Tilkov, SOA Expertenwissen, S.142f. 11 Vgl. Liebhart, SOA goes real, S.164f. 12 Vgl. Liebhart, SOA goes real, S Vgl. MacKenzie, Ref. model for soa, S Vgl. Melzer et al., Service-orientierte Architekturen mit Web Services, S Vgl. Liebhart, SOA goes real, S.163.

22 8 2 Dienste zugehörige Daten verarbeiten. 2.4 Dienstarten Da die Auflösung von Diensten sehr unterschiedlich ist, ist es sinnvoll diese zu unterscheiden. Im Folgenden werden drei verschiedene Dienstarten dargestellt Wertschöpfender Dienst der wertschöpfende Dienst umfasst eine sehr beschränkte Anzahl von unternehmensweiten Diensten, welche direkt zur Wertschöpfung des Unternehmens beitragen. Es handelt es ich beim wertschöpfenden Dienst weniger um Software oder Anwendungssysteme, sondern meist um komplexe Geschäftsprozesse. Als Beispiel könnte man sich einen Bestellprozess eines Händlers vorstellen, bei dem Kunden eine Bestellung durchführen können. Dieser Bestellprozess stellt eine der wichtigsten Schnittstellen zwischen Kunde und Händler dar. Dabei muss sich der wertschöpfende Dienst nicht nur an externe Interessenten richten. Für ein Geschäftsmodell, in welchem der Händler einen umfangreichen hochfrequentierten Marktplatz im Internet anbietet, bedarf es einer entsprechenden und effizienten technischen Infrastruktur. Die Auswirkung dieser Infrastruktur, in welche der Händler mit der Zeit enormes Wissen in den Betrieb und Entwurf investiert, können dazu führen, dass der Händler diesen Dienst anderen Unternehmen anbietet und somit ein weiteres Standbein für seinen Unternehmenserfolg aufbaut Unterstützender Dienst Wie bereits erwähnt, verwendet der wertschöpfende Dienst eine Vielzahl von Funktionen, die betriebswirtschaftliches Wissen benötigen, selbst aber nicht direkt wertschöpfend sind. Dieser Typ von Diensten wird als unterstützend bezeichnet. Unterstützende Dienste könne auch extern angeboten werden. Während bei wertschöpfenden Diensten eine Wiederverwendung nahezu entfällt, weisen unterstützende Dienste ein hohes Maß an Wiederverwendung auf. Dies ist allerdings davon abhängig, wie grob diese Dienste strukturiert werden Vgl. Starke/Tilkov, SOA - Expertenwissen, S Vgl. Starke/Tilkov, SOA - Expertenwissen, S.215f. 18 Vgl. Starke/Tilkov, SOA - Expertenwissen, S.216f.

23 2.5 Dienst als Enterprise Application Integration Technischer Dienst Im Gegensatz zum wertschöpfenden und unterstützenden Dienst enthält der technische Dienst, auch Infrastrukturservice genannt, keine betriebswirtschaftliche Logistik, sondern stellt lediglich technische Funktionen zu Verfügung. Bereitgestellt wird dieser direkt als Funktion von Anwendungssystemen oder von Infrastruktursoftware wie Middleware. In einem durchschnittlichen Unternehmen sind tausende Dienste im Einsatz, so dass aktives Management all dieser Funktionen mit den vorhandenen Techniken und Werkzeugen unmöglich erscheint. Folglich müssten für diese Aufgaben spezielle Werkzeuge der Hersteller genutzt werden. Fraglich erscheint, ob einem Fachanwender die Bedeutung aller technischen Artefakte vermittelt werden, damit sie richtig genutzt und kombiniert werden. 19 Der Author empfiehlt, sich beim Start einer SOA-Initiative auf wertschöpfende Services zu konzentrieren und technische Services nur bei Bedarf hinzuzunehmen. Eine aus wirtschaftlicher Sicht sinnvolle SOA hat geschäftliche Flexibilität (business agility) zum Ziel und orientiert sich an wertschöpfenden Services (Geschäftsservices). Eine Architektur, die nur technische Services enthält, ist keine SOA! Dienst als Enterprise Application Integration Man könnte sich die Frage stellen, wie es in der IT-Landschaft eines großen Unternehmens aussieht, wenn es ein kleines Unternehmen übernimmt. An diesem Beispiel soll ein Dienst in einer Enterprise Application Integration (EAI) betrachtet werden. Anfänglich werden alle Applikationen einzeln in der IT-Landschaft stehen, im besten Fall stellen beide ehemals getrennte IT-Landschaften jeweils eine SOA dar. In diesem Fall wären Funktionalitäten bei weitem schneller in ein Gesamtkonzept integrierbar. Abbildung 2.1 zeigt, wie der Zustand vor der Integration aussehen kann. In Prozessrichtung wird bis zu den Applikationsgrenzen abgearbeitet, aber es ist keine Übertragung auf die anderen Applikationen möglich, so dass kein Gesamtprozess über die Applikationen hinweg ausgeführt werden kann. Auch kann es gut möglich sein, dass Funktionalitäten sogar teilweise oder ganz auf allen beteiligten Applikationen gleich implementiert sind aus dem sich jeweils der Prozess der Applikation zusammensetzt. 19 Vgl. Starke/Tilkov, SOA - Expertenwissen, S Vgl. Starke/Tilkov, SOA - Expertenwissen, S.19.

24 10 2 Dienste Abbildung 2.1: Einzelne Applikationen in der IT-Landschaft Die größte Anstrengung bei der Integration wird dabei sein, [...] mehr Aufwand auf die Definition und Entwicklung etwas grob-granularer Funktionen, die dann Dienste genannt werden, aufzubringen. Diese Dienste werden dann nach Bedarf flexibel zu Prozessen kombiniert und unter einem einheitlichen GUI vereint. 21 Unterstützt von Abbildung 2.2, stellt dies damit die Antwort auf die mögliche Frage dar, wie sich mehrere IT-Landschaften miteinander zu einer Enterprise Application Integration kombinieren lassen. Abbildung 2.2: Gesamtprozess einer EAI 21 Vgl. Melzer et al., Service-orientierte Architekturen mit Web Services, S.30f.

25 2.6 Dienst als Webservice Dienst als Webservice Die Funktionsweise eines Webservice in einer SOA lässt sich einfach in einem magischen Dreieck darstellen, siehe Abbildung 2.3. Dabei lassen sich die beteiligten Instanzen in die drei Rollen Dienstanbieter, Dienstverzeichnis und Dienstkonsument gliedern Dienstanbieter Die Aufgaben des Dienstanbieters umfassen die Aufrechterhaltung des Betriebs einer Plattform, auf der er mindestens einen Dienst zur Nutzung anbietet. Neben der Verfügbarkeit muss der Dienstanbieter ebenso viel Sorge um die Sicherheit des Dienstes tragen. Diese Aufgabe umfasst den Großteil der Thematik dieser Diplomarbeit. Insbesondere muss der Dienstanbieter dabei Verfahren zur Authentifizierung und Autorisierung zur Anwendung bringen, dies hält er schriftlich durch Bedingung in der Beschreibung des Dienstes fest und prüft sie sobald ein Dienstkonsument die Nutzung einleitet (siehe Punkt 5 in Abbildung 2.3). Bemerkenswert ist hierbei, dass der Dienstanbieter angebotene Dienste nicht selbst entwickelt und implementiert haben muss und darüber hinaus besteht die Möglichkeit über das Netz andere Dienste dem Angebot anzufügen oder sogar mehrere verteilte, einfache Dienste - gekapselt in einem komplexen Aufrufkonstrukt - als ein weit aus mächtigeres Ganzes anzubieten. Die Rolle des Dienstanbieters schreibt vor, dass er seine angebotenen Dienste dem Dienstverzeichnis bekannt macht (siehe Punkt 1 in Abbildung 2.3). Sobald ein Dienstkonsument auf einen Dienst zugreifen möchte, muss zuvor eine Beschreibung des Dienstes, sowie die Schnittstelle, dem Dienstkonsumenten vollständig dargelegt werden (siehe Punkt 4 in Abbildung 2.3) Dienstverzeichnis Zu den Aufgaben des Dienstverzeichnisses (engl. Registry oder Service Broker) einer SOA zählt einerseits das Entgegennehmen von Registrierungsanfragen für Dienste durch deren Anbieter (siehe Punkt 1 in Abbildung 2.3). Daraufhin wird der Dienst unter den Kategorien registriert, die der Dienstanbieter bei der Anfrage mitgesendet hat. Andererseits übernimmt das Dienstverzeichnis die Aufgabe Suchanfragen von Dienstkosumenten auszuführen (siehe Punkt 2 in Abbildung 2.3) und Suchergebnisse in Form von Verweise auf den jeweiligen Dienst zurück zu liefern (siehe Punkt 3 in Abbildung 2.3) Dienstkonsument Die Aufgaben, die ein Dienstkonsument bewältigen muss, um schließlich den benötigten Dienst nutzen zu können, umfassen das Absetzen einer Suchanfrage für einen geeigneten Dienst an das Dienstverzeichnis (siehe Punkt 2 in Abbildung 2.3) und als Reaktion darauf, bei Erfolg,

26 12 2 Dienste den Erhalt eines Verweises auf den passenden Dienst (siehe Punkt 3 in Abbildung 2.3). Mit diesem Verweis, kann der Dienstkonsument den jeweiligen Dienst bei einem Dienstanbieter auffinden und eine Beschreibung abfragen (siehe Punkt 4 in Abbildung 2.3). Wenn die Beschreibung des Dienstes den Bedarf des Dienstkonsumenten erfüllt, die Schnittstelle des Dienstes ansprechbar ist und alle Bedingungen zur Nutzung des Dienstes aus Sicht des Dienstanbieters erfüllt wurden, kann sich der Dienstkonsument dafür entschließen den Dienst zu nutzen (siehe Punkt 5 in Abbildung 2.3). Abbildung 2.3: Magisches Dreieck Dienstverzeichnis, Dienstanbieter, Dienstkonsument, 1.Veröffentlichung, 2.Suche, 3.Verweis auf Dienst, 4.Abfrage der Beschreibung, 5.Nutzung 22 Was sich in der Theorie recht einfach erwähnen lässt, in der Praxis jedoch oft die größte Schwierigkeit darstellt, wenn es darum geht einen Dienst anzubieten, ist die Erreichbarkeit des Dienstes. Insbesondere da der Aspekt Sicherheit über die Jahre verschiedenste Technologien umfasst, kann u.u. die Infrastruktur nur mit großem Aufwand zum Transport unterschiedlicher Protokolltypen eingerichtet werden, in der sich ein Server mit angebotenen Diensten befindet. 2.7 Authentifizierung Definition: Applications need to verify that only legitimate users are trying to use them. The process of verifying the identity of users is referred to as authentication Vgl. Melzer et al., Service-orientierte Architekturen mit Web Services, S Vgl. Ramarao Kanneganti/Prasad Chodavarapu, Manning, SOA Security, S.14.

27 2.8 Autorisierung 13 Authentifizierung schafft Klarheit darüber, wer man ist. Mechanismen zur Authentifizierung erwarten dabei, dass ein Benutzer seine Identität beweisen kann, bevor Zugriff erteilt wird. Die Identität kann dabei, wie [KaCh08] beschreibt, in verschiedenen Formen ausgedrückt werden. Einerseits kann der Beweis durch Preisgabe eines Geheimnisses durchgeführt werden, wie z.b. durch ein Benutzername-Passwort Paar oder die geheime Antwort auf eine Frage. Andererseits kann durch Vorzeigen bzw. Übermitteln eines einzigartigen, limitierten Besitzgegenstandes, die eigene Identität bewiesen werden, wie z.b. durch Übermittlung eines Token, welches eine, in einem definierten Zeitraum gültige, zufällige Zahlenkombination - errechnet aus einem digitalen Schlüssel und der aktuellen Zeit - darstellt und vom Authentifizierungsmechanismus mit einem erneut nachgerechneten Äquivalent verglichen wird. Des weiteren kann alternativ durch eine biometrische Kontrolle die Identität abgeleitet werden, wie z.b. durch Erkennung eines Fingerabdrucks, einer Iris bzw. Retina, einer Stimme oder einer Gesichtsgeometrie. Ein Mechanismus wird im Kapitel 6.4 Shibboleth beschrieben. 2.8 Autorisierung Definition: Once a user is authenticated with or without the help of a directory server, an application needs to determine whether the identified user is authorized to access the functionality she is requesting. Authorization is also commonly referred to as access control. 24 Autorisierung schafft Klarheit darüber, was man darf. The decision to grant access may depend on multiple criteria, such as the action that is being requested, the resource on which the action is being requested, and the groups to which the authenticated user belongs or the roles that the user plays. 25 [KaCh08] führt auf, dass die zwei meist gebräuchlichsten Zugriffskontrollen die Role-Based Access Control (RBAC) und die Access Control List (ACL) sind. Bei RBAC wird der Zugriff zu einer Aktion für eine oder mehrere Rollen erlaubt, d.h. rollenbasiert. So hat beispielsweise ein Professor eine andere bzw. ergänzende Rollen gegenüber einem Studenten. Bei ACL hingegen wird über Listen definiert, welcher Benutzer etwas darf oder nicht darf, d.h. regelbasiert. Dadurch kann die Autorisierung feiner eingestellt werden, als es bei RBAC mit Rollen der Fall ist. Beispielsweise kann dadurch einer Liste von bestimmten Professoren der Zugriff zu einem rechenintensiven Dienst erlaubt werden. ACLs finden Anwendung bei LDAP Konfigurationen, 24 Vgl. Ramarao Kanneganti/Prasad Chodavarapu, Manning, SOA Security, S Vgl. Ramarao Kanneganti/Prasad Chodavarapu, Manning, SOA Security, S.16.

28 14 2 Dienste bei denen definiert werden können, welche Attribute von wem geschrieben oder gelesen werden können. Ein Mechanismus wird im Kapitel 6.4 Shibboleth beschrieben. 2.9 Zusammenfassung Dienste weisen Eigenschaften auf, wie z.b. die Lose Kopplung und Autonomität, um in einer Service-orientierten Architektur keine redundante Funktionalität, sondern granulare, verteilte Funktionalitäten in einen Prozess einbinden zu können. Durch die Kapselung der Implementation muss nur noch die Schnittstelle berücksichtigt werden, sobald man einen Dienst nutzen möchte. Dadurch sind Implementationen austauschbar, ohne dass der Dienstkonsument davon etwas bemerkt. Dieser muss, um einen Dienst erst einmal zu finden, lediglich ein Dienstverzeichnis aufsuchen, dort nach einem geeigneten Dienst suchen und er erhält einen Verweis auf einen Dienstanbieter, den er kontaktieren kann. Schließlich kann es möglich sein, dass der Dienstkonsument sich für die Nutzung des Dienstes authentifizieren muss und anschließend autorisiert wird den Dienst zu nutzen oder nicht.

29 3 SOA Zunächst erfolgt ein Einblick in eine mögliche Definition von SOA sowie eine Untersuchung der Merkmale einer SOA. Weiterhin wird erläutert aus welchen Bausteinen eine SOA sich zusammensetzt. Folglich wird ein Aufbau einer SOA über Enterprise Application Integration dargestellt. Abschließend wird SOA einem kritischen Blick unterworfen. 3.1 Definition Eine allgemein akzeptierte Definition von SOA kann die Literatur nicht liefern, da in momentan gebräuchlichen Definitionen zwar Überlappungen existieren, aber nicht alle Aspekte einer SOA einheitlich wiedergegeben werden. 26 Gleichwohl haben alle diese zahlreichen Interpretationen einer SOA ihre Berechtigung. 27 Dennoch sollen zwei Definitionen für SOA aus der Literatur hier genannt werden. Im weiteren Sinne soll damit diese Darstellung von SOA verstanden werden: Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. 28 In einer Service-orientierten Architektur handelt es sich um ein generisches Entwurfsmuster für IT-Systemarchitekturen oder - um einen neudeutschen Begriff zu benutzen - um ein Systemarchitektur- Pattern. SOA beschreibt eine Art und Weise, ein lose gekoppeltes, verteiltes Software-System zu entwerfen und zu realisieren, sowie seine Einzelbausteine (vor allem die Services) untereinander und auf verschiedenen Abstraktions- und Skalierungsebenen in eine sinnvolle Wechselwirkung zu setzen. 29 Beide Definitionen gehen auf die mögliche Verteiltheit der Dienste ein und beschreiben SOA als ein Paradigma diese Dienste zu organisieren, um die Nutzung dieser nicht nur voranzutreiben, sondern alle Möglichkeiten aus der Kombination ihrer Fähigkeiten auszuschöpfen. 26 Vgl. Melzer et al., Service-orientierte Architekturen mit Web Services, S Vgl. SOA intern, S Vgl. MacKenzie, Ref. model for soa, S Vgl. SOA intern, S.8.

30 16 3 SOA Eines der größten Versprechen der SOA ist die Erhöhung der Geschäftsflexibilität durch schnellere Reaktionsfähigkeit der IT auf geschäftlich bedingte Änderungen. 30 SOA stellt ein Mittel dar, Lösungen zu organisieren, welche Wiederverwendbarkeit, Wachstum und Interoperabilität vorantreiben. 31 Ein Eckpfeiler von SOA ist, dass Potentiale genutzt werden können, ohne alle Details kennen zu müssen. 32 SOA versteht sich dabei nicht allein auf die Bereitstellung von - eigens für eine Entität (Person oder Organisation) - entwickelten Diensten. Vielmehr bietet SOA die Möglichkeit über ein Dienstnutzer-Dienstanbieter Verhältnis angebotene Dienste bereitzustellen, die quasi auch ein anderer als die eigene Entität administrieren könnte. SOA shifts IT from an application-centric view to a servicecentric view. This shift lets IT build applications that make use of other applications (via the services they provide), making it easy to meet changing business needs by combining functionality from different applications Merkmale einer guten SOA Lose Kopplung: Durch Lose Kopplung ist die Geschäftsprozesslogik von den Geschäftsfunktionen strikt getrennt. Dies bringt eine hohe Unabhängigkeit und damit Flexibilität einzelner Dienste mit sich. Kopplung und Kohäsion beschreiben die Eigenschaften der Gruppierung von Methoden eines Systems. Kopplung beschreibt das Maß des nötigen Verständnisses eines anderen Moduls, das erforderlich ist, um ein gegebenes Modul zu entwickeln oder zu verändern. Je mehr Verständnis für andere Module notwendig ist, desto größer die Kopplung zwischen dem gegebenen und dem anderen Modul. Die Kopplung wird bestimmt von der Abhängigkeit zwischen Modulen, der Komplexität der Schnittstelle und der Art des Informationsflusses. Kohäsion beschreibt im Gegensatz zur Kopplung die Wechselbeziehungen zwischen einzelnen Elementen innerhalb eines Moduls. Es gilt: Je größer die Kohäsion individueller Module, desto geringer die Kopplung. 34 Die lose Kopplung ist einer der wichtigsten Faktoren bei der Einführung einer SOA, wenn nicht gar der wichtigste Faktor überhaupt. 35 Sie sollte jedoch gut durchdacht und nicht übertrieben werden (siehe Kapitel Kritik). 30 Vgl. Starke/Tilkov, SOA - Expertenwissen, S Vgl. MacKenzie, Ref. model for soa, S Vgl. MacKenzie, Ref. model for soa, S Vgl. Ramarao Kanneganti/Prasad Chodavarapu, Manning, SOA Security, S Vgl. Liebhart, SOA goes real, S Vgl. Starke/Tilkov, SOA - Expertenwissen, S.184.

31 3.2 Merkmale einer guten SOA 17 Dynamische Bindung: Bei der dynamischen Bindung werden Dienste [...] von Anwendungen oder anderen Diensten bei Bedarf dynamisch gesucht, gefunden und eingebunden. Dieser Punkt ist insoweit spannend, da es sich um eine Bindung zur Laufzeit handelt. Das heißt, dass zum Zeitpunkt der Übersetzung des Programms meist nicht bekannt ist, wer oder was zur Laufzeit aufgerufen wird. 36 Verzeichnisdienst: Nicht zu verwechseln mit der im Deutschen ebenso verwendeten Bezeichnung für Directory Service (z.b. Directory Access Protocol (DAP) oder Lightweight Directory Access Protocol(LDAP)), der Informationen über Benutzer, Anwendungen und Netzwerkressourcen speichert und organisiert; ironischerweise wird ein Verzeichnisdienst - im eigentlichen Sinne - typisch als Webservice mit Zugriff zu einer LDAP- Architektur aufgebaut. Gemeint damit ist hier jedoch die Bezeichnung für Service Registry, das aus Kapitel 2.6 Dienst als Webservice bekannt gewordene Dienstverzeichnis. Oft wird hier auch der Begriff Repository genannt. Ein Repository (dt. Lager, Vorrat) im Sinne einer SOA, ein so genanntes Metadaten-Repository, bezeichnet ein intelligentes Datenhaltungssystem, in dem Informationen über wiederverwendbare Service-Bausteine aufbewahrt werden. Es findet somit Verwendung in der Beziehung mit Enterprise Application Integration (EAI). Verwendung von Standards: Die Verwendung von Standards ermöglicht einer SOA eine breite Akzeptanz, beispielsweise für eine Dienstschnittstelle. Durch die Überlegung für welche genauen Standards man sich jeweils entscheidet, legt man gleichzeitig einen Grundstein für eine Architektur. Ausdiesem Grunde sollte eine durchdachte, umsichtige Entscheidung frühzeitig getroffen werden. Dies begünstigt außerdem die Trennung von Schnittstelle und Implementierung, infolgedessen ergibt sich aus dieser Kapselung eine Begünstigung der Wiederverwendbarkeit. Neben den genannten Eigenschaften gibt es noch eine Reihe nichtfunktionaler Systemeigenschaften von SOA, die sich in zwei Bereiche einteilen lassen. Zum einen, die zur Laufzeit messbaren Eigenschaften und zum anderen, die zur Laufzeit nicht messbaren Eigenschaften. Erstere geben Auskunft über das allgemeine Verhalten des Systems. Letztere, die zur Laufzeit nicht messbar sind, werden erst in einer späten Phase des Systems sichtbar. 37 "Diese allgemeine Systemeigenschaften haben miteinander gemeinsam, dass sie vor dem Bau eines Systems definiert werden sollten, was in der Realität selten der Fall ist." Vgl. Melzer et al., Service-orientierte Architekturen mit Web Services, S Vgl. Liebhart, SOA goes real, S Vgl. Liebhart, SOA goes real, S.158.

32 18 3 SOA Anhand Tabelle 3.1 und Tabelle 3.2 von [Lieb07] auf Seite 158f wird veranschaulicht, mit welchen Mitteln SOA die nichtfunktionalen Eigenschaften eines Systems beeinflußt. Tabelle 3.1: Zur Laufzeit messbarer Eigenschaften und SOA Tabelle 3.2: Nicht zur Laufzeit messbarer Eigenschaften und SOA

33 3.3 Bausteine einer SOA Bausteine einer SOA (Fach-)Dienste Dienste "[...] repräsentieren die elementaren Bausteine eines SOA-Systems und prägen die Bezeichnung der Service-orientierten Architektur. Sie stehen für minimale Teilfunktionalitäten des zu zu integrierenden Systems, wobei sie selbst - im Unterschied zu zentralistischen EAI-Ansätzen - höherwertige Logik und komplexe Prozesse über verschiedene andere vorhandene Dienste realisieren können. Eine geeignete deutsche Übersetzung für Service könnte Fachdienst lauten: Diese Bezeichnung stellt heraus, dass es sich um Systembausteine handelt, die in einem SOA-System tatsächlich auch aufgerufen werden, also eine echte fachliche Aufgabe erfüllen." Service-Meditation-System Ein Service-Meditation-System wertet Informationen über verteilte Dienste aus, die in der Service Registry zusammenlaufen. Das typische Service-Meditation-System steht für einen dezentralen Integrationsansatz. "Die Service Consumer holen sich über dieses Integrationssystem den Kontakt zu denjenigen Diensten, die sie gerade benötigen. [...] Ein Service Consumer muss daher zumindest das Service-Meditation-System kennen und ansprechen können, das den adressierten Zieldienst hostet. Eine Kommunikation der Dienste untereinander läuft über die Vermittlung der Service-Meditation-Systeme. Diese stellen in ihren heutigen Ausbaustufen die volle Flexibilität einer dezentralen Kommunikationsinfrastruktur bereit. Jeder Service benötigt ein Service-Meditation-System als Service-Host, der seine äußeren Schnittstellen für externe Service Consumer veröffentlicht. Service-Meditation-Systeme ergänzen daher die heute gängigen Serverausprägungen wie Web oder Application Server gut, und können auf dieser Basis auch entwickelt werden." Service Registry Eine Service Registry realisiert ein Verzeichnis von angeschlossenen Services, das die Details zu ihren technischen Beschreibungen enthält, wie IP-Adressen, Portangaben oder einfach deren Bezeichnungen. Sie sind direkt an die Service- Meditation-Systeme angeschlossen, die diesen Zugriff benötigen, um die Kommunikation zwischen den Services abzuwickeln Vgl. Mathas, SOA intern, S Vgl. SOA intern, S Vgl. SOA intern, S.14.

34 20 3 SOA Service Repository In einem Service Repository werden dienstbezogene und im Systemkontext genutzte Metadaten (Kontraktinformationen, Berechtigungsprofile (Policies), laufzeitrelevante Informationen beispielsweise über aktuelle Anzeigedaten) angegeben. Diese Daten sind für die technische Zusammenführung der Dienste sowie ihre Ansteuerung erforderlich Enterprise Application Integration Definition: EAI (Enterprise Application Integration) ist ein Ansatz zur Integration heterogener Anwendungen mit Hilfe verschiedener Werkzeuge und Mechanismen." 43 Abbildung 3.1: Intergrationsunterschiede 42 Vgl. SOA intern, S Vgl. Liebhart, SOA goes real, S.124.

35 3.4 Enterprise Application Integration 21 Bei der Integration ohne EAI kommunizieren die Systeme über Punkt-zu-Punkt-Verbindungen miteinander, anstatt über eine gemeinsame Plattform, wie es bei der Integration mit EAI der Fall ist. Damit wird deutlich, dass die Anzahl der Schnittstellen mit der Anzahl neuer angebundener Systeme erheblich steigt, wenn kein EAI verwendet wird, anstatt konstant zu steigen. Die Implementierung von EAI-Infrastrukturen beschreibt [Lieb07] als basierend auf einer Reihe grundlegender Prinzipien: Die Erweiterung der bestehenden Datenintegration um ein gemeinsames Framework. Die Verbindung von Geschäftsprozessen mit den Daten auf der Anwendungsebene. Die gemeinsame Nutzung der Business-Logik auf der Komponenten-Ebene. Aus diesen Prinzipien gehen unterschiedliche Topologien zur Realisierung von EAI in der Theorie hervor, wie beispielsweise Point-to-Point, Pipeline oder Network-Topologien. Jedoch haben sich praktisch, laut [Lieb07], nur zwei durchgesetzt: die Hub and Spoke -Topologie und die Bus-Topologie, wie in der folgenden Abbildung 3.2 dargestellt.

36 22 3 SOA Abbildung 3.2: EAI-Topologien in der Praxis Bei der Hub and Spoke -Topologie wird die EAI-Infrastruktur realisiert, indem zentral ein Server - der Hub (dt. Nabe) - angesiedelt wird. Dieser stellt die einzige Schnittstelle für die Anwendungen dar, welche direkt miteinander nicht kommunizieren sollen. Um den zentralen Hub werden als so genannte Spokes (dt. Speichen) die Anwendungen plaziert. Damit steuert und überwacht der Hub alle über die EAI-Infrastruktur abgewickelten Aufgaben. Es liegt auf der Hand, dass dieser zentrale Server für das Gesamtsystem den sensibelsten Teil darstellt und vor einem Ausfall durch redundante Server mit Failover- Mechanismen geschützt werden sollte. Im Gegensatz zu diesem Nachteil, führt [Lieb07] als wichtigsten Vorteil die einfache Umsetzung dieser Topologie auf, durch die alle Integrationskomponenten zentral verwaltet werden können. Die Ralisierung als Bus-Topologie - auch verteilte Integration genannt - siedelt die EAI-

37 3.5 Kritik 23 Infrastruktur auf verteilte Systeme an, die miteinander über einen so genannten Integration Bus kommunizieren. Die Bus-Topologie bildet zu dem genannten Vor- und Nachteil der Hub and Spoke -Topologie genau den Gegenpart: nachteilig durch die Verteilung bei der Bus-Topologie bedarf es einer komplexen Realisierung, da laut [Lieb07] Synchronisation und Konsistenz über mehrere Systeme hinweg verwaltet werden müssen; als Vorteil stellt sich jedoch die Robustheit und Ausfallsicherheit dieser Topologie in den Vordergrund. "Letztendlich besteht das Ziel der Integration darin, dass all jene, die mit den IT-Systemen arbeiten, d.h. die entsprechenden Geschäftsprozesse ausführen, möglichst nahtlos die einzelnen Schritte ihrer Tätigkeit mit dem jeweils unterstützenden System ausführen können. Auf dieser Ebene treffen sich die Ziele von EAI mit einem der Ziele von SOA, der Strukturierung der betrieblichen Informationen entlang der Geschäftsprozesse eines Unternehmens." Kritik SOA mittels Webservices gehört heute, laut [StTi07], zu den verbreiteten Standards für die Entwicklung verteilter Systeme und hat dementsprechend in den meisten Entwicklungsplattformen Eingang gefunden. [StTi07] merkt an, dass für viele Problemstellungen jedoch Entwickler andere Kommunikationsprotokolle wie etwa TCP/IP, IIOP (Fussnote: Internet Inter-ORB Protocol ist ein in CORBA definiertes Protokoll.) oder JMS (Fussnote: Java Message Service) bevorzugen. Daher wäre ein Ansatz wünschenswert, der Dienstimplementierung und Kommunikationsaspekte voneinander trennt." [StTi07] bemängelt, dass zwar Baukästen für SOA, wie beispielsweise Apache Axis, Entwicklern mächtige Programmierschnittstellen in die Hand geben, diese jedoch aus Zeitgründen, von nur wenigen Entwicklern in der Praxis bis in die (Un)Tiefen solcher Technologien kennengelernt werden. "Besser wäre daher eine Laufzeitumgebung/Container, die den Entwickler weitgehend von Details abschirmt." Lose Kopplung ist nicht immer sinnvoll, feste Kopplung nicht immer schlecht. Feste Kopplung verursacht prinzipiell Fehler zur Compile-Zeit und liefert mehr Typsicherheit. Lose Kopplung verursacht prinzipiell Fehler zur Laufzeit (falls sie überhaupt bemerkt werden). [...] Auch sind bei loser Kopplung und somit in einer SOA Lasttests viel wichtiger. [...] Lose Kopplung ist eine Form von Abstraktion, und jede Abstraktion kostet letztendlich Zeit und Geld. 45 Weshalb man beim Umsetzen des SOA-Ansatzes auch immer entscheiden muss, welches Maß an loser Kopplung man umsetzen will Vgl. Liebhart, SOA goes real, S Vgl. Starke/Tilkov, SOA - Expertenwissen, S.643f. 46 Vgl. Starke/Tilkov, SOA - Expertenwissen, S.653.

38 24 3 SOA Ein entscheidender Punkt für SOA ist die Tatsache, dass die einzelnen Systeme in unterschiedlicher Hand liegen. Weil dies so ist, gibt es unterschiedliche Aufgabenstellungen, unterschiedliche Prioritäten, unterschiedliche Budgets und unterschiedliche Zeitpläne. Dadurch wird es schon organisatorisch ausgesprochen schwierig, sich auf Gemeinsamkeiten zu einigen Zusammenfassung Es wurde vorgestellt, wie Service-orientierte Architekturen durch gute Eigenschaften identifiziert werden kann und welche Bausteine eine SOA allgemein ausmachen können, wie sie exemplarisch in einer Enterprise Application Integration (EAI) beschrieben wurden. Des Weiteren wurde SOA einem kritischen Blick unterworfen. 47 Vgl. Starke/Tilkov, SOA - Expertenwissen, S.651.

39 4 Single Sign-On In diesem Kapitel wird die Anwendung und der Vorteil von Single Sign-On (SSO) dargestellt. 4.1 Definition Ein Single Sign-On (dt. Einmalanmeldung) bedeutet, dass ein Benutzer nach einer einmaligen Authentifizierung auf alle Rechner und Dienste, für die er berechtigt ist, zugreifen kann, ohne sich jedes Mal neu anmelden zu müssen. Die Funktionalität baut auf Unified-Login, bei der sich ein Benutzer nur einmal am zentralen Authentifizierungsserver anmelden muss und danach für eine festgelegte Dauer für verschiedene Rechner und Anwendungen authentifiziert ist. [...] 48 When SSO occurs among applications in more than one DNS domain, the functionality is called Cross-Domain Single Sign-On (CDSSO) Einleitung Angesichts der vielen Passwörter, die man sich für verschiedenste Anwendungen merken muss, liegt es nahe, dass Benutzer häufig Passwörter bestimmten Anwendungen nicht mehr zuordnen können oder gar ganz vergessen. Durch Single Sign-On entfallen derartige Probleme sowie Hilfestellung beim Zugriff auf Anwendungen und Webinhalte, da sich der Benutzer einmalig gegenüber einem vertrauenswürdigen, zentralen Mechanismus einer IT-Struktur authentifiziert, wodurch der Arbeitsaufwand für Helpdesks und Administratoren erheblich verringert werden könnte. Hauptaugenmerk bei Nutzung von Single Sign-On liegt beim flüssigeren Ablauf der Arbeit während dem Wechsel zwischen diversen Diensten, was zu einer höheren Produktivität führen kann. Aus wirtschaftlicher Sicht eine rentable Möglichkeit Kosten einzusparen. Nichtsdestotrotz ist die Kritik, mit einem einzigen Passwort Zugriff zu einer Vielzahl von Anwendungen zu erlangen, nicht zu unterschätzen und genau aus diesem Anlass muss bei der 48 Vgl. DFN-AAI, Deutsches Forschungsnetz - Projekt Authentifizierungs- und Autorisierungs- Infrastruktur, 49 Vgl. Sun Java System Access Manager 7.1 Technical Overview, März 2007, S.42.

40 26 4 Single Sign-On Nutzung von Single Sign-On ein vertrauenswürdiges Authentifizierungsverfahren zur Überprüfung der Identität sowie ein flexibles Autorisierungsverfahren zur Kontrolle des Zugriffs Anwendung finden. Daraus würde wiederum eine einheitliche Rechte- und Benutzerstruktur innerhalb der Institution resultieren. Für den Aufbau von Single Sign-On, auf der Basis einer bestehenden Infrastruktur, müssen eine Reihe von Anforderungen bei der Konzeption einer zentralen, einmaligen Authentifizierung erfüllt werden: zentrale Administration: Die Benutzerdaten zur Authentifizierung und Autorisierung sollen nur an einer Stelle gepflegt werden. einmalige Datenauskunft: Die Benutzer sollen im Rahmen der Selbstverwaltung bei Eingabe bzw. Änderung ihre Benutzerdaten konsistent und nicht redundant einem System anvertrauen. ausgereifte Sicherheit: Passwörter sollen für Angreifer nicht lesbar sein und Änderung von sensiblen Benutzerdaten soll nur dem Administrator vorbehalten sein. 4.3 Kategorisierung Web SSO: For SSO for Web application requests over HTTP protocol, use a Web proxy deployed in front of a variety of Web application servers and application platforms. This includes support for.net client desktops using SPNEGO technology protocol. Federated SSO: For requests crossing enterprise and security boundaries across heterogeneous platforms, and trust domains, use intermediaries, such as Web services gateways to act as the point of contact for SOAP requests and Web proxy capability for HTTP requests. Use a federated identity management solution to manage the federation policies, identity mapping, and trust policies. Backend SSO: In order to map identities and credentials and connect to backend systems from your business logic, use a security token service. Have a portal or application server call the security token service. If the backend access can be routed through an intermediary, use a Web services gateway to handle the enforcement. End client SSO: There are applications that are accessed using a variety of clients and protocols where SSO has to be done closer to the user (than at the enterprise boundary). In these cases, use a client application single sign-on implementation where client credential store is used to store the user s credentials (user ID and password) and

41 4.4 OpenSSO 27 to automatically let the user log on to applications OpenSSO Java Implementation von Sun Microsystems. Basis für die nächste generation des Sun s Web Access Management Produkt Sun Java System Federated Access Manager 8.0. Wird vom SSOCircle eingesetzt. Die Internetpräsenz befindet sich unter: Access Manager Architecture AccessManager uses a Java technology-based architecture for scalability, performance, and ease of development. It also leverages industry standards including thehypertext Transfer Protocol (HTTP), the extensiblemarkup Language (XML), the Security AssertionMarkup Language (SAML), and SOAP. The internal architecture is multi-layered and includes the following: Vgl. Understanding SOA Security, Design and Implementation, Second Edition, Axel Buecker/Paul Ashley/Martin Borrett et al., November 2007, Stand: , S.60f. 51 Vgl. Sun Java System Access Manager 7.1 Technical Overview, März 2007, S.20.

42 28 4 Single Sign-On Abbildung 4.1: Access Manager Internal Architecture Java Applications C Applications SAML Applications Liberty Applications Web Browser Protected Resource Access Manager Client APIs Administration CLI Servlet / J2EE Container Access Manager Web Services Authentication XML/http(s) Policy XML/http(s) SAML XML/http(s) Federated Identity XML/http(s) Administration Console HTML/http(s) Access Manager Components Authentication Policy (Authorization) SAML Federated Identity Session Logging Access Manager Framework Access Manager SPIs Authentication Policy (Authorization) Service Configuration Delegation Identity Repository Management Authentication Plug-ins Policy Authorization Plug-ins Service Configuration Plug-ins Delegation Plug-ins Identity Repository Plug-ins A presentation layer Web services Core components Client application programming interfaces (APIs) An integrated framework Service provider interfaces (SPIs) A plug-ins layer The AccessManager Session Service enables the following types of user sessions: Vgl. Sun Java System Access Manager 7.1 Technical Overview, März 2007, S.38f.

43 4.5 Shibboleth 29 Basic user session. The user provides credentials to log in to one application, and then logs out of the same application. Single sign-on (SSO) session. The user provides credentials once, and can then access multiple applications within the samedns domain. Cross domain SSO (CDSSO) session. The user provides credentials once, and can then access applications among multipledns domains SAML Service AccessManager uses the Security AssertionMarkup Language (SAML), an XML-based framework for exchanging security information. While the Session Service enables SSO sessions among differentdns domains within the same intranet, the SAML Service enables CDSSO sessions among different business domains. Using the SAML protocol, business partners can securely exchange authentication and authorization information over the Internet Federation Service Identity federation allows a user to consolidate the many local identities he has configured among multiple service providers. With one federated identity, the user can log in at one service provider s site and move to an affiliated service provider site without having to re-authenticate or re-establish identity. The Federation Service uses SAML to enable SSO sessions among business partners over the Internet Shibboleth Shibboleth ist ein System, um die Authentifizierung und Autorisierung von Benutzern durchzuführen und kann Eigenschaften eines Benutzers an einen Dienst senden, welche in einem LDAP Verzeichnis oder einer relationalen Datenbank gespeichert sind. Mit Shibboleth entfällt durch das Single Sign-On Verfahren die Notwendigkeit ein Anmeldeportal bei jedem Dienst zu implementieren, ebenso wie eine redundante Persistenz der Identitäten und der Eigenschaften eines Benutzers bei jedem Dienst. Dies verkürzt bemerkbar die Zeit zwischen dem Aufruf des Dienstes und dem Zugriff darauf. 53 Vgl. Sun Java System Access Manager 7.1 Technical Overview, März 2007, S Vgl. Sun Java System Access Manager 7.1 Technical Overview, März 2007, S.39.

44 30 4 Single Sign-On Es vereinfacht nicht nur den Zugang zu Informationen, sondern vereinheitlicht diesen auch. Shibboleth ist auf SAML aufgebaut, somit basierend auf der Verlässlichkeit der Kommunikationbeziehungen und des Datenaustausch. Shibboleth ist eine Entwicklung der US-amerikanischen Internet2-Initiative und beruht auf den international gängigen Standards HTTP, XML, XML Schema (XSD), XML Signatur (XMLDisg), SOAP sowie SAML 1.1 (später 2.0). Shibboleth besteht im Wesentlichen aus zwei Software-Komponenten, die für die Seite der Anbieter sowie für die Seite der Einrichtungen konzipiert wurden. Der Einsatz von Shibboleth gewährleistet die vollständige Kompatibilität z.b. zu internationalen Verlagen, die den Zugriff vieler ihrer Datenbestände über Shibboleth organisieren. 55 Shibboleth wird in Kapitel 6 ausführlich behandelt. 4.6 Zusammenfassung Single Sign-On bietet ein Verfahren, welches bislang wenig in der Praxis eingesetzt wird. Dabei lässt sich Single Sign-On in die Kategorien Web SSO, Federated SSO, Backend SSO und End client SSO aufteilen. Dadurch kann es in vielen Bereichen in der Praxis herangezogen werden. Als Beispiel wurden zwei Systeme vorgestellt, die Single Sign-On bereits umsetzen. Einerseits OpenSSO von Sun Microsystems, andererseits Shibboleth von Internet2. Daneben existieren eine Menge anderer Systeme, die Single Sign-On anbieten. 55 Vgl. DFN-AAI, Deutsches Forschungsnetz - Projekt Authentifizierungs- und Autorisierungs- Infrastruktur,

45 5 SAML Die Security Assertion Markup Language (SAML) stellt einen standardisierten Austausch von Informationen für den Aufbau einer sicheren SOA-Infrastruktur bereit. Nach einer kurzen Definition erfolgt eine grobe Erklärung zu SAML. In den darauf folgenden Kapiteln werden die Hauptbestandteile Assertion, Protocol, Binding und Profile der SAML Spezifikation mit Beispielen sowie eine anschließende Zusammenfassung vorgestellt. 5.1 Definition Die von OASIS 56 entwickelte Security Assertion Markup Language (SAML) ist eine XMLbasierte Auszeichnungssprache, mit der sich sicherheitsrelevante Informationen zu Authentifizierung, Session-Attributen und Autorisierung ausdrücken sowie Berechtigungs-Schemata definieren lassen. Dabei basiert SAML auf offenen Standards und ist selbst vollständig programmiersprachen-, plattform- und herstellerunabhängig. 57 Es liegt in der menschlichen Natur Informationen aufzunehmen, jedoch gehen Individuen unterschiedlich mit ihnen um. Besonders bei sensiblen Informationen ist Vorsicht geboten, wem gegenüber diese preisgegeben werden. Auf der anderen Seite birgt für ein Individuen die Kenntnis über sensible Informationen eines anderen ein persönliches Risiko, ausgehend von Angreifern, die sich dafür interessieren. Eine Entlastung durch einen Dritten, dem beide Seiten vertrauen, bieten Verfahren, wie z.b. die Treuhand. Im übertragenen Sinne, kann solch ein Szenario ebenso für Dienste untereinander oder eine Kommunikation zwischen Benutzern und Diensten beschrieben werden. Oft ist es wichtig zu wissen, dass jemand eine bestimmte Identität oder Eigenschaft besitzt, ohne diese selbst zu überprüfen, beispielsweise ein Passwort oder eine Identifikationsnummer. Auch eine Rolle innerhalb einer Institution (z.b. Entwickler oder Manager) oder eine Zugehörigkeit zu Teilen dieser Institution (z.b. die Abteilung in einem Unternehmen) stellt oft eine sicherheitsrelevante Information dar. 56 Organization for the Advancement of Structured Information Standards. 57 Vgl. Melzer et al., Service-orientierte Architekturen mit Web Services, S.213.

46 32 5 SAML Für eine Umsetzung dieses Konzepts wurde die Security Assertion Markup Language (SAML) vorgestellt. Mit der Möglichkeit einen Benutzer als authentifiziert zu kennzeichnen und Benutzer- Eigenschaften zu übermitteln, bietet SAML die perfekte Grundlage für die Verwendung im Single Sign-On Verfahren. Der Aufbau von Vetrauensverhältnissen kann sogar über Domaingrenzen hinweg bereitgestellt werden, bekannt als Cross-Domain Single Sign-On. Bestandteile der SAML-Spezifikation sind Assertions, Protocols, Bindings und Profiles. Die sicherheitsrelevanten Informationen machen den Kern von SAML aus - so genannte Assertions. Protocols definieren, wie Assertions angefordert und übermittelt werden. Bindings und Profiles [...] legen fest, wie Teile von SAML in andere Dokumente eingebunden werden können und entsprechende Rahmen aus anderen Spezifikationen zu erweitern sind. 58 Alternatively, if an entity has been authenticated at the service consumer, then an authenticated identity might be presumed where the service provider trusts that authentication has already taken place. The service provider then accepts the authenticated identity carried in the identity token without requiring another authentication. The binding of a SAML-based identity token to a request is one means of asserting an already authenticated identity. 59 Federated single sign-on can leverage both Identity Services and Authentication Services and allow a user to authenticate once to the federation and by asserting security claims using security tokens can be provided access to other trusted domains Historie 12.November SAML v1.0 wurde bei OASIS standardisiert SAML v1.1 wurde als OASIS Standard bewilligt. September SAML v1.1 wurde eingeführt mit beträchtlichem Erfolg für Finanzdienstleistungen, Hochschulen, Regierung und andere Industriesegmente. SAML wurde weitgehend von allen größeren Web Access Management Anbietern eingeführt. SAML Unterstützung wird auch in den meisten Application Server Produkten geliefert und 58 Vgl. Melzer et al., Service-orientierte Architekturen mit Web Services, S Vgl. Understanding SOA Security, Design and Implementation, Second Edition, Axel Buecker/Paul Ashley/Martin Borrett et al., November 2007, Stand: , S Vgl. Understanding SOA Security, Design and Implementation, Second Edition, Axel Buecker/Paul Ashley/Martin Borrett et al., November 2007, Stand: , S.43.

47 5.3 Bestandteile 33 kommt für gewöhnlich bei Anbietern von Management und Sicherheit für Webservices vor. SAML V2.0 baut auf diesem Erfolg auf. 61 März SAML v2.0 wurde als OASIS Standard bewilligt Dezember Die Liberty Alliance meldet, dass die ersten Unternehmen (Hewlett- Packard, IBM, RSA, Sun Microsystems und Symlabs) mit ihren Produkten den SAML v2.0 Interoperabilitäts-Test bestanden haben. 5.3 Bestandteile Assertions An assertion is a package of information that supplies zero or more statements made by a SAML authority; SAML authorities are sometimes referred to as asserting parties in discussions of assertion generation and exchange, and system entities that use received assertions are known as relying parties. 63 Eine Assertion (dt. Versicherung, Beteuerung) ermöglicht sicherheitsrelevante Informationen einer Entität zu versichern. SAML Assertions werden von Authorities (dt. Autoritäten, Obrigkeiten, Zuständigkeiten) erzeugt, die verantwortlich für die Sicherheit sind. Assertions können darüber hinaus digital signiert werden. Eine solche Authority wird auch Asserting Party bzw. Identity Provider genannt, welche Dienst- bzw. Benutzer-Authentifizierungen leitet und Informationen über den Dienst/Benutzer im Überblick behält. Eine SAML Assertion muss immer eine Identifikation (AssertionID) haben, und muss stets angeben, von wem (Issuer) und wann (IssueInstant) die Assertion geliefert wird. Versionsangaben (MajorVersion, MinorVersion) sind ebenfalls Pflicht. Eine SAML Assertion kann angeben, unter welchen Bedingungen (Conditions) diese gültig ist, beispielsweise einem Gültigkeitsbeginn (NotBefore) und einem Gültigkeitsende (NotOnOrAfter). Eine oder mehrere Bedingungen <AudienceRestrictionCondition> können hinzugefügt werden, welche selber ein oder mehrere <Audience> Elemente beinhalten können. Die <Audience> Elemente geben per URI an, für welche Endpunkte, d.h. vertrauende Beteiligte (engl. Relying Party), diese Assertion bestimmt ist. Diese <AudienceRestrictionCondition> Bedingung wird gültig für alle Beteiligten die ebenda als Audience aufgeführt sind. Darüber hinaus gibt es noch 61 Vgl. Nach eigener Übersetzung des 1.Abschnitts der History of SAML, Stand: Vgl. Nach eigener Übersetzung des 1.Abschnitts der History of SAML, Stand: Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, , S.11.

48 34 5 SAML einige weitere optionale Elemente, die bei OASIS SAML v nachgelesen werden können. Die Dokumentation zu SAML v ist ebenfalls erhältlich. [...] extensions are permitted by the SAML assertion schema, allowing userdefined extensions to assertions and statements, as well as allowing the definition of new kinds of assertions and statements. 66 SAML definiert drei unterschiedliche Arten von Statements (dt. Angabe, Aussage), die auf solch eine Bedingung folgen und den Hauptteil einer Assertion ausmachen: Listing 5.1: Beispiel einer SAML Assertion 1 <A s s e r t i o n 2 xmlns=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : a s s e r t i o n " 3 x m l n s : s a m l=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : a s s e r t i o n " 4 x m l n s : s a m l p=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o t o c o l " 5 x m l n s : x s d=" h t t p : //www. w3. org /2001/XMLSchema" 6 x m l n s : x s i=" h t t p : //www. w3. org /2001/XMLSchema i n s t a n c e " 7 A s s e r t i o n I D=" _2a8a f39c11307f703a1545c " 8 I s s u e r=" h t t p s : // i d p. hs f u r t w a n g e n. de / s h i b b o l e t h i d p " 9 I s s u e I n s t a n t=" T08:12: Z" 10 M a j o r V e r s i o n=" 1 " 11 M i n o r V e r s i o n=" 1 "> <C o n d i t i o n s 14 NotBefore=" T08:12: Z" NotOnOrAfter=" T08:17: Z"> 15 <A u d i e n c e R e s t r i c t i o n C o n d i t i o n> 16 <Audience>h t t p s : // f e l i x 2. hs f u r t w a n g e n. de / s h i b b o l e t h / o l a t / sp</ Audience> 17 <Audience>h t t p s : //www. hs f u r t w a n g e n. de / IdP HFU</ Audience> 18 </ A u d i e n c e R e s t r i c t i o n C o n d i t i o n> 19 </ C o n d i t i o n s> </ A s s e r t i o n> SAML Assertions werden typischerweise zu Benutzer oder Dienste angefertigt, demzufolge einem Subjekt (engl. Subject), definiert als optionales Element <Subject>. Im weiteren Kontext sollen Dienste bzw. Benutzer unter dem Begriff Subjekt subsumiert werden. Alle drei Arten von Statements können sich auf ein Subjekt beziehen. Das Element <NameIdentifier> bestimmt, auf welches Subjekt sich ein Statement bezieht und liefert im optionalen Kindelement <NameQualifier> die - das Subjekt näher beschreibende - Authority. 67 Nachfolgend wird in den Beispielen somit ein NameIdentifier genutzt, der unkenntlich und temporär ist - ein so genanntes Handle. Dies geschieht auf Seiten der Authority automatisch, 64 Vgl Vgl Vgl. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OA- SIS Standard, , S Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, , S.12.

49 5.3 Bestandteile 35 um das Subjekt generell für alle Relying Parties gleichermaßen auszuzeichnen, über einen Kompromiss auf niedrigstem Niveau. Über den NameIdentifier können Relying Parties zum Subjekt SAML Anfragen an die Authority richten, z.b. um Attribute zu verlangen. Im Ausnahmefall darf evtl. eine Relying Party kein einziges Attribut über das Subjekt erhalten, somit wäre es schlichtweg unsachgemäß das Subjekt in Klartext zu nennen. Hinweis: Hier wird die noch weit verbreitete SAML v1.0 Spezifikation in den Beispielen von Shibboleth v1.3 genutzt. Beispielsweise verwendet SAML v2.0 andere Elementbezeichnungen, wie <AuthnStatement> für das Authentication Statement und <AuthzDecisionStatement> für das Authorization Decision Statement. Authentication Statement Das Authentication Statement findet Anwendung bei der Authentifizierung eines Subjekts. Nachdem der Mechanismus eines Sicherheitsdienstes das Subjekt authentifiziert hat, kann - wenn gewünscht - eine Information darüber an die Relying Party weitergegeben werden, in Form einer Assertion mit Authentication Statement. Das Subjekt ist somit der Relying Party gegenüber auch authentifiziert; diese vertraut somit - durch dieses Statement - der Authority. Dabei wird der Zeitpunkt der Authentifizierung (AuthenticationInstant) und der angewendete Mechanismus (AuthenticationMethod) angegeben. Listing 5.2: Beispiel für ein SAML AuthenticationStatement 1 <A s s e r t i o n... > <A u t h e n t i c a t i o n S t a t e m e n t 4 A u t h e n t i c a t i o n I n s t a n t=" T08:12: Z" 5 A u t h e n t i c a t i o n M e t h o d=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : a m : u n s p e c i f i e d "> 6 7 <S u b j e c t> 8 <N a m e I d e n t i f i e r 9 Format=" u r n : m a c e : s h i b b o l e t h : 1. 0 : n a m e I d e n t i f i e r " 10 N a m e Q u a l i f i e r=" h t t p s : // i d p. hs f u r t w a n g e n. de / s h i b b o l e t h i d p "> 11 _ 1c56796d2d4d6a8a4caa3598ac4ed </ N a m e I d e n t i f i e r> 13 <S u b j e c t C o n f i r m a t i o n> 14 <ConfirmationMethod> 15 u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : c m : b e a r e r 16 </ ConfirmationMethod> 17 </ S u b j e c t C o n f i r m a t i o n> 18 </ S u b j e c t> 19 <S u b j e c t L o c a l i t y I P A d d r e s s=" "></ S u b j e c t L o c a l i t y> 20 </ A u t h e n t i c a t i o n S t a t e m e n t> </ A s s e r t i o n> Für die Identitätsüberprüfung mit Angabe des Mechanismus (AuthenticationMethod) kann SAML Passwörter, Kerberos, Secure Remote Passwörter, Hardware Token, X.509- oder SSL/TLS- Zertifikate, SPKI- (Simple Public Key Infrastructure), XKMS- (XML Key Management Spe-

50 36 5 SAML cification) oder PGP-Verfahren sowie elektronische Unterschriften mit XML verwenden. Alternativ kann - wie hier - unspecified verwendet werden, d.h. Identitätsüberprüfung in anderer Form. 68 In einigen Situationen möchte eine Relying Party zusätzliche Informationen erhalten, um die Echtheit und das Vertrauen in die Informationen einer Assertion abzuschätzen. Mit der SAML 2.0 kann dem Authentication Statement somit ein Authentication Context mit angegeben werden. Dieser gibt an, welche Prozesse, Prozeduren, Mechanismen usw. bei der Authority zum Einsatz kommen, um ein Subjekt zu authentifizieren. 69 Attribute Statement Das Attribute Statement findet Anwendung bei der Übermittlung von Eigenschaften eines Subjekts zu einer Relying Party. Eine Identität eines Subjekts wird durch dessen Eigenschaften (respektive: Attribute) abgebildet, welche eine Relying Party im Voraus angefordert hat und innerhalb gewisser Richtlinien auch erhalten darf. Heraus gefilterte Eigenschaften werden bei der Übermittlung nicht aufgeführt. Dieses Statement spielt, neben der Möglichkeit einen Dienst an eine Identität anzupassen, auch bei Zugangsberechtigungen eine wichtige Rolle. Listing 5.3: Beispiel für ein SAML AttributeStatement 1 <A s s e r t i o n... > <A t t r i b u t e S t a t e m e n t> 4 <S u b j e c t> 5 <N a m e I d e n t i f i e r 6 Format=" u r n : m a c e : s h i b b o l e t h : 1. 0 : n a m e I d e n t i f i e r " 7 N a m e Q u a l i f i e r=" h t t p s : // i d p. hs f u r t w a n g e n. de / s h i b b o l e t h i d p "> 8 _ 1c56796d2d4d6a8a4caa3598ac4ed295 9 </ N a m e I d e n t i f i e r> 10 <S u b j e c t C o n f i r m a t i o n> 11 <ConfirmationMethod> 12 u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : c m : b e a r e r 13 </ ConfirmationMethod> 14 </ S u b j e c t C o n f i r m a t i o n> 15 </ S u b j e c t> 16 <A t t r i b u t e 17 AttributeName=" u r n : m a c e : d i r : a t t r i b u t e d e f : s n " 18 A t t r i b u t e N a m e s p a c e=" u r n : m a c e : s h i b b o l e t h : 1. 0 : a t t r i b u t e N a m e s p a c e : u r i "> 19 <A t t r i b u t e V a l u e>schwecht</ A t t r i b u t e V a l u e> 20 </ A t t r i b u t e> 21 <A t t r i b u t e 22 AttributeName=" u r n : m a c e : d i r : a t t r i b u t e d e f : g i v e n N a m e " 68 Vgl. Assertions and Protocol for the OASIS, Security Assertion Markup Language (SAML) V1.1, OASIS Standard, pdf, Vgl. Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0,

51 5.3 Bestandteile A t t r i b u t e N a m e s p a c e=" u r n : m a c e : s h i b b o l e t h : 1. 0 : a t t r i b u t e N a m e s p a c e : u r i "> 24 <A t t r i b u t e V a l u e>h a r a l d</ A t t r i b u t e V a l u e> 25 </ A t t r i b u t e> <A t t r i b u t e 30 AttributeName=" u r n : m a c e : d i r : a t t r i b u t e d e f : e d u P e r s o n P r i m a r y A f f i l i a t i o n " 31 A t t r i b u t e N a m e s p a c e=" u r n : m a c e : s h i b b o l e t h : 1. 0 : a t t r i b u t e N a m e s p a c e : u r i "> 32 <A t t r i b u t e V a l u e>s t u d e n t</ A t t r i b u t e V a l u e> 33 </ A t t r i b u t e> 34 </ A t t r i b u t e S t a t e m e n t> 35 </ A s s e r t i o n> Authorization Decision Statement Das Authorization Decision Statement findet Anwendung bei der Autorisierung eines Subjekts. Eine Relying Party hat im Vorfeld eine Anfrage (engl. Request) an die Authority sendet, um in Erfahrung zu bringen, ob ein Subjekt Zugriff zu der Ressource der Relying Party erhalten darf und für welche Aktionen das Subjekt innerhalb der Ressource autorisiert ist. Als Reaktion folgt die Assertion mit Authorization Decision Statement als Antwort (engl. Response) darauf, die behauptet, dass dem Subjekt Zugriff zur Ressource bzw. Aktionen erteilt oder verweigert werden sollen. Dieses Statement kommt somit denkbar nur für den Zugriff auf Dienste vor, die: -selber keine Autorisierung vornehmen, -erweiterte Autorisierung seitens Authority erwarten, -keine Attribute im Vorfeld holen oder -grundsätzlich keine geeigneten Attribute für eine Autorisierung erhalten. Für Single Sign-On ist dieses Statement daher eher untypisch: For single sign-on, a typical SAML assertion will contain a single authentication statement and possibly a single attribute statement. 70 Aus diesem Grund soll hier ein beliebiges Beispiel entworfen werden. Listing 5.4: Beispiel für ein AuthorizationDecisionStatement 1 <A s s e r t i o n... > <A u t h o r i z a t i o n D e c i s i o n S t a t e m e n t 4 R e s o u r c e=" h t t p s : // b e i s p i e l. hs f u r t w a n g e n. de / s a m l d i e n s t / " 5 D e c i s i o n=" Permit "> 6 7 <S u b j e c t> 70 Vgl. Assertions, Stand:

52 38 5 SAML 8 <N a m e I d e n t i f i e r 9 N a m e Q u a l i f i e r=" hs f u r t w a n g e n. de " 10 Format="... :SAML:1. 1 :nameid f o r m a t : e m a i l A d d r e s s "> 11 schwecht@hs f u r t w a n g e n. de 12 </ N a m e I d e n t i f i e r> 13 </ S u b j e c t> 14 <A c t i o n Namespace=" h t t p : //www. o a s i s open. org / x m l a c t i o n s / "> 15 Read 16 </ A c t i o n> </ A u t h o r i z a t i o n D e c i s i o n S t a t e m e n t> </ A s s e r t i o n> Die Assertion im Beispiel besagt, dass der Benutzer schwecht@hs-furtwangen.de zugelassen (engl. permitted) werden darf, die Ressource zu lesen (engl. read), welche sich mit der hier beispielhaft ausgedachten URI Protocol Das SAML Protocol definiert ein Format von Anfragen (engl. Request) und Antworten (engl. Response), demzufolge Interaktionsmöglichkeiten zwischen den Teilnehmern. Über XML-Schema wird der Aufbau einer Anfrage bzw. Antwort definiert, wie es von der W3C für die Definition von Strukturen für XML-Dokumente empfohlen wird. Als Beispiel soll hier eine Anfrage für Eigenschaften demonstriert werden, d.h. Einem AttributeQuery. Die Ressource des AttributeQuery möchte gern zu dem Subjekt alle möglichen Eigenschaften erhalten. Der Anfrage wird eine RequestID zur Identifikation der Anfrage mitgegeben. Listing 5.5: Beispiel für ein SAML Request 1 <Request 2 xmlns=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o t o c o l " 3 x m l n s : s a m l=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : a s s e r t i o n " 4 x m l n s : s a m l p=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o t o c o l " 5 x m l n s : x s d=" h t t p : //www. w3. org /2001/XMLSchema" 6 x m l n s : x s i=" h t t p : //www. w3. org /2001/XMLSchema i n s t a n c e " 7 I s s u e I n s t a n t=" T08:12: Z" 8 M a j o r V e r s i o n=" 1 " 9 M i n o r V e r s i o n=" 1 " 10 RequestID=" _ 22bed46f8b4bc39ed ceb0cef "> <A t t r i b u t e Q u e r y 13 R e s o u r c e=" h t t p s : // f e l i x 2. hs f u r t w a n g e n. de / s h i b b o l e t h / o l a t / sp "> <S u b j e c t xmlns=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : a s s e r t i o n "> 16 <N a m e I d e n t i f i e r 17 Format=" u r n : m a c e : s h i b b o l e t h : 1. 0 : n a m e I d e n t i f i e r " 18 N a m e Q u a l i f i e r=" h t t p s : // i d p. hs f u r t w a n g e n. de / s h i b b o l e t h i d p "> 19 _ 1c56796d2d4d6a8a4caa3598ac4ed </ N a m e I d e n t i f i e r> 21 <S u b j e c t C o n f i r m a t i o n> 22 <ConfirmationMethod>

53 5.3 Bestandteile u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : c m : b e a r e r 24 </ ConfirmationMethod> 25 </ S u b j e c t C o n f i r m a t i o n> 26 </ S u b j e c t> 27 </ A t t r i b u t e Q u e r y> 28 </ Request> Dem Beispiel für die Anfrage folgend, soll nun ein Beispiel für eine Antwort darauf demonstriert werden. Da die Anfrage ein AttributeQuery war, wird folglich nun eine Assertion mit eingebettetem Attribute Statement als Antwort geliefert. Zusätzlich wird der Antwort ein Parameter InResponseTo mitgegeben, der angibt, auf welche Anfrage sich nun diese Antwort bezieht, d.h. die selbe Identifikation wie die Anfrage hatte. Der Antwort wird natürlich eine ResponseID zur Identifikation der Antwort mitgegeben. Listing 5.6: Beispiel für ein SAML Response 1 <Response 2 xmlns=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o t o c o l " 3 x m l n s : s a m l=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : a s s e r t i o n " 4 x m l n s : s a m l p=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o t o c o l " 5 x m l n s : x s d=" h t t p : //www. w3. org /2001/XMLSchema" 6 x m l n s : x s i=" h t t p : //www. w3. org /2001/XMLSchema i n s t a n c e " 7 InResponseTo=" _ 22bed46f8b4bc39ed ceb0cef " 8 I s s u e I n s t a n t=" T08:12: Z" 9 M a j o r V e r s i o n=" 1 " 10 M i n o r V e r s i o n=" 1 " 11 ResponseID=" _ c22c12a10b029dabd38278d9303f5e1d "> <S t a t u s> 14 <StatusCode 15 Value=" s a m l p : S u c c e s s "> 16 </ StatusCode> 17 </ S t a t u s> 18 <A s s e r t i o n... > 19 <C o n d i t i o n s 20 NotBefore=" T08:12: Z" 21 NotOnOrAfter=" T08: 42: Z"> </ C o n d i t i o n s> 24 <A t t r i b u t e S t a t e m e n t> 25 <S u b j e c t> </ S u b j e c t> 28 <A t t r i b u t e... > </ A t t r i b u t e> 31 </ A t t r i b u t e S t a t e m e n t> 32 </ A s s e r t i o n> 33 </ Response> Im Beispiel für die Antwort wird über das Element <Status> gemeldet, ob die Anfrage erfolgreich war oder nicht. Zusätzlich können weitere <StatusCode> Elemente, eine Ebene tiefer, für die Angabe von Gründen im Fehlerfall optional genutzt werden, um den Anfrager zu informieren. Nachdem nun bekannt ist, wie Anfrage und Antwort inhaltlich aussieht, sollen die unterschied-

54 40 5 SAML lichen Arten von in SAML definierten Protokollen betrachtet werden. Dafür müssen vorab einige Begriffe erläutert werden: Identity Provider: A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles. Principal A system entity whose identity can be authenticated. [X.811] Service Provider: A role donned by a system entity where the system entity provides services to principals or other system entities. Im vorangehenden Kontext als Relying Party verwendet. 71 Artifact Eindeutige Zeichenkette, mit der eine SAML-Antwort angefordert wird. Das Artefakt wird via HTTP gesendet und besteht aus einer mit B64 verschlüsselten Zeichenkette mit folgenden Aufbau: TypeCode - EndpointIndex - RemainingArtifact. 72 Die Protokolle 73 die SAML definiert sind: Assertion Query and Request Protocol: Definiert Anfragen, durch die bestehende SAML Assertions erreicht werden können. Die Anfrage kann einer Referenz, einem Subjekt oder einem Statement zugrunde liegen. Authentication Request Protocol: Definiert eine <AuthnRequest> Nachricht, die veranlasst eine <Response> zurückzuschicken, welche eine von mehreren Assertions enthält, die einen Principal 74 betreffen. Gewöhnlich wird die <AuthnRequest> Nachricht durch einen Service Provider (dt. Dienstanbieter) herausgegeben und vom Identity Provider durch eine <Response> Nachricht erwidert. Es wird verwendet, um das Single Sign-On Profile des Webbrowsers zu unterstützen. Artifact Protocol: Stellt einen Mechanismus zur Verfügung, um eine vorher erzeugte Assertion zu erhalten, indem eine Referenz zur Verfügung gestellt wird. In Bezug zu SAML wird die Referenz Artifact genannt. So kann sich ein SAML Protokoll auf eine Assertion durch ein Artifact beziehen. Sobald ein Service Provider dann das Artifact erhält, kann er das Artifact Protocol verwenden, um die tatsächliche Assertion zu erreichen, auf die sich gerade das SAML Protokoll bezieht. 71 Vgl. Stand: Vgl. Stand: Nach eigener Übersetzung von: Protocols, Stand: Vgl. Eine Entität, deren Identität authentifiziert werden kann.

55 5.3 Bestandteile 41 Name Identifier Management Protocol: Stellt einen Mechanismus zur Verfügung, um den Wert oder das Format des Namens eines Principals zu ändern. Der Aussteller der Anfrage kann entweder der Service Provider oder der Identity Provider sein. Das Protokoll liefert auch einen Mechanismus, um eine Assoziierung eines Namens zwischen einem Identity Provider und einem Service Provider aufzulösen. Single Logout Protocol: Definiert eine Anfrage, welche nahezu simultanes Abmelden aller (zugehörigen) Sitzungen erlaubt, die mit einem Principals in Verbindung stehen. Das Abmelden kann direkt durch den Principal oder aufgrund einer Zeitüberschreitung der Sitzung eingeleitet werden. Name Identifier Mapping Protocol: Stellt einen Mechanismus zur Verfügung, um account linking zu ermöglichen. (Betrifft Federated Identity, d.h. ein Subjekt hat evtl. Daten bei verschiedenen, zusammengeschlossener Identity Providern - einer Föderation - jedoch z.b. mit unterschiedlichem Benutzernamen; eine kurze Beschreibung liefert OASIS hier: Anmerkend soll nicht außer Acht gelassen werden, dass es einen praktischen Nutzen zu geben scheint (z.b. gerade beim Authentication Request Protocol), mehrere Assertions in einer Antwort zu liefern: Note that a SAML response could contain multiple assertions, although its more typical to have a single assertion within a response Bindings Das SAML Binding gibt an, über welche Standardprotokolle SAML Request und Response transportiert werden. Generically, a specification of the mapping of some given protocol s messages, and perhaps message exchange patterns, onto another protocol, in a concrete fashion. For example, the mapping of the SAML <AuthnRequest> message onto HTTP is one example of a binding. The mapping of that same SAML message onto SOAP is another binding. In the SAML context, each binding is given a name in the pattern SAML xxx binding. 76 Mit SAML v1.1 wurde am häufigsten ein Binding für SAML mit SOAP 77 über HTTP verwendet. Dies wird als SAML SOAP HTTP binding bezeichnet. Die SAML v2.0 soll ein Binding rein über einen HTTP-Transport für SAML bieten, ein so genanntes SAML HTTP binding. Beim Transport mit SOAP über HTTP, liegt das über das SAML Protocol definierte Request 75 Vgl. Assertions, Stand: Vgl. Stand: Vgl. Mittlerweile ist für SOAP kein Akronym mehr zulässig.

56 42 5 SAML bzw. Response im Body der SOAP Nachricht. Weitere Informationen muss der SOAP-Body nicht enthalten. Eine SOAP Nachricht baut sich aus einem Envelope (dt. Umschlag) auf, in dem ein Header (dt. Nachrichtenkopf) Element sowie ein Body Element enthalten sind. Abbildung 5.1: SAML SOAPHTTP binding Dazu ein Beispiel einer SOAP Nachricht 78 Listing 5.7: Beispiel für ein SOAP Envelope 1 <e n v : E n v e l o p e x m l n s : e n v=" h t t p : //www. w3. org /2003/05/ soap e n v e l o p e "> 2 <e n v : H e a d e r> 3 < n : a l e r t c o n t r o l x m l n s : n=" h t t p : // example. org / a l e r t c o n t r o l "> 4 < n : p r i o r i t y>1</ n : p r i o r i t y> 5 < n : e x p i r e s> T14:00:00 05 : 0 0</ n : e x p i r e s> 6 </ n : a l e r t c o n t r o l> 7 </ e n v : H e a d e r> 8 <env: Body> 9 <m : a l e r t xmlns:m=" h t t p : // example. org / a l e r t "> 10 <m:msg>p i c k up Mary a t s c h o o l a t 2pm</m:msg> 11 </ m : a l e r t> 12 </ env: Body> 13 </ e n v : E n v e l o p e> Da SAML lediglich eine Auszeichnungssprache darstellt und kein kryptographisches Verschlüsselungsverfahren, müssen Maßnahmen für die sichere Übertragung durch Benutzer oder Anwendungen in Erwägung gezogen werden, beispielsweise empfiehlt die OASIS HTTP über SSL 3.0 bzw. TSL 1.0 für das Binding in SOAP, somit ein SAML SOAP HTTPS binding. 78 Vgl. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), W3C Recommendation 27 April 2007, Stand

57 5.3 Bestandteile Profiles In den SAML Profiles wird für ausgewählte Anwendungsfälle definiert, wie Assertions, Protocols und Bindings kombiniert werden. A set of rules for one of several purposes; each set is given a name in the pattern xxx profile of SAML or xxx SAML profile. 79 Nachfolgend eine Reihe von Profiles 80, die SAML definiert sind: Web Browser SSO Profile: Definiert, wie ein Webbrowser Single Sign-On (SSO) unterstützt, wenn <AuthnRequest> Protokoll-Nachrichten in Verbindung mit HTTP Redirect, HTTP POST und HTTP Artifact bindings verwendet werden. Enhanced Client and Proxy (ECP) Profile: Definiert, wie <AuthnRequest> Protokoll- Nachrichten benutzt werden, wenn sie mit dem Reverse-SOAP binding (PAOS) kombiniert werden. Entworfen, um mobile Geräte über WAP Gateways zu unterstützen. Identity Provider Discovery Profile: Definiert, wie ein Service Provider entdecken kann, welche Identity Provider ein Principal mit dem Webserver benutzt. Single Logout Profile: Ein Profil des SAML Single Logout Protokolls ist definiert. Definiert wie SOAP, HTTP Redirect, HTTP POST and HTTP Artifact bindings benutzt werden können. Name Identifier Management Profile: Definiert wie das Name Identifier Management Protokoll mit SOAP, HTTP Redirect, HTTP POST and HTTP Artifact bindings genutzt werden kann. Artifact Resolution Profile: Definiert, wie das Artifact Resolution Protokoll ein synchrones Binding benutzt, z.b. das SOAP binding. Assertion Query/Request Profile: Definiert, wie die SAML query 81 Protokolle (verwendet, um SAML Assertions zu erhalten) ein synchrones Binding - wie das SOAP binding - benutzen. Name Identifier Mapping Profile: Definiert, wie das Name Identifier Mapping Protokoll ein synchrones Binding - wie das SOAP binding - benutzt. 79 Vgl. Stand: Vgl. Nach eigener Übersetzung von: Protocols, Stand: Vgl. Verwendet um SAML Assertions zu erhalten.

58 44 5 SAML 5.4 Stand Es bietet sich an die Unterschiede zwischen SAML v2.0 und v1.1 kennen zu lernen, wenn man tiefer in diese Materie einsteigen möchte. Zur Zeit findet ein Wechsel für viele SAML nutzende Frameworks statt, die gerade ihre Implementation von SAML v1.1 zu v2.0 umstellen. Shibboleth, ein solches Framework, bietet eine sehr übersichtliche Auflistung 82 dieser Unterschiede. Aber nicht nur in Sachen Single Sign-On kann SAML eingesetzt werden. Es sieht ganz danach aus, als könnte SAML in Sachen Spam-Schutz in Zukunft in aller Munde sein. Am 19.November 2007 wurde ein Dokument herausgegeben, welches das Problem SPAM for Internet Telephony (SPIT) angeht, d.h. unerwünschte Anrufe per Voice over IP (VoIP) Zusammenfassung Security Assertion Markup Languague (SAML) ist eine von OASIS entwickelte XML-basierte Auszeichnungssprache, welche eine Spezifikation von Assertions, Protocols, Bindings und Profiles bietet. Dadurch können sicherheitsrelevante Informationen, über den Protokoll-Transport an den Kommunikationspartner, behauptet werden, ohne diese selber preis zu geben. Allerdings bietet SAML die Möglichkeit Eigenschaften eines Subjekts (Dienst oder Benutzer) zu behaupten, indem diese Eigenschaft preisgegeben wird. Über Bindings kann entschieden werden, wie das Protokoll in ein Standardprotokoll eingebettet wird, beisielsweise um einen verschlüsselten Transport zu gewährleisten, da SAML selber dafür nicht Sorge trägt. 82 Vgl. Shibboleth 1 Documentation - SAMLDiffs, Differences Between SAML V2.0 and SAML V1.1, Stand: Vgl. Stand:

59 6 Shibboleth Nach einer kurzen Definition des Shibboleth Frameworks erfolgt ein Exkurs in das Alte Testament. Anschließend werden die Idee und die Sitzungsbausteine von Shibboleth erläutert, bevor der Mechanismus des Single Sign-On anhand einer Abbildung veranschaulicht wird. Ergänzend zum Mechanismus wird, anhand des Verzeichnisschutzes durch den Webserver, die Einleitung von Lazy- und Full Sessions demonstriert. Darauf folgend wird ein Einblick in die durch Shibboleth erweiterten Servervariablen genommen. Abschließend soll über eine Abbildung eine Shibboleth Föderation illustriert und Bezug genommen werden, sowie ein kurzer Ausblick auf die Verbesserungen der Shibboleth Version 2.0 gegeben werden. 6.1 Definition Shibboleth is a system designed to exchange attributes on campus and across realms for single sign-on and authorization. It provides a secure framework to transmit attributes about a web-browsing individual to local or remote web resources Einleitung Und Jeftah sammelte alle Männer von Gilead und kämpfte gegen Ephraim. Und die Männer von Gilead schlugen Ephraim - denn diese hatten gesagt: Ihr seid Flüchtlinge aus Ephraim; denn Gilead liegt mitten in Ephraim und Manasse-; und die Gileaditer besetzten die Furten des Jordans vor Ephraim. Wenn nur einer von den Flüchtlingen Ephraims sprach: Laß mich hinübergehen!, si sorachen die Männer von Gilead zu ihm: Bist du ein Ephraimiter? Wenn er dann antwortete: Nein!, ließen sie ihn sprechen: Schibbolet. Sprach er aber: Sibbolet, weil er s nicht richtig aussprechen konnte, dann ergriffen sie ihn und erschlugen ihn an den Furten des Jordans, so saß zu der Zeit von Ephraim fielen zweiundvierzigtausend. 85 Wörtlich aus dem Hebräischen übersetzt bedeutet Shibboleth Getreideähre. 84 Vgl. Shibboleth Technical Overview, Stand: Vgl. Bibel, Altes Testament, Buch der Richter, Kapitel 12, Vers 4-6.

60 46 6 Shibboleth Durch Shibboleth soll die Idee des Single Sign-On umgesetzt werden. Ein Zugriff auf Inhalte soll unabhängig vom Standort und vom Zugriffsweg ermöglicht werden. Des Weiteren muss trotz der Ortsunabhängigkeit an jedem Standort die gleiche Auswahl an Inhalten zur Verfügung stehen. Dabei soll ein Zugriff diese, nach einmaliger Authentifizierung, vollzählig nutzbar machen. Eigenschaften eines Benutzers kann Shibboleth gefiltert durch ein Regelwerk (engl. Policy) als Attriute bekannt machen. Diese Eigenschaften und die Möglichkeit die Identität eines Benutzers zu kennen, bilden die Grundlage von Shibboleth. Eine Autorisierung des Benutzers innerhalb des Dienstes ist somit über diese angeforderten Attribute möglich. Autorisierung ist ein optionaler Bestandteil eines Dienstes, um granular zu entscheiden, was der jeweilige Benutzer innerhalb der Möglichkeiten des Dienstes darf und ggf. was nicht. Barriers may be good for security, but they get in the way of business. That does not mean security can be compromised to meet the business goals; we just have to find smarter ways to secure our applications. Traditional security approaches assumed and took advantage of barriers. Since SOA lowers barriers, we must rethink the security approaches. 86 In Bezug zum Konzept von SOA, erhöht Shibboleth dabei auch die Sicherheit, da sich der Benutzer einmalig gegenüber seiner eigenen Heimatinstitution (z.b. Hochschule des Professors, Mitarbeiters oder Studenten) authentifizieren muss und somit Benutzername-Passwort-Paare nicht durch jeden Dienst persistent aufbewahrt werden müssen. Zusätzlich genügt, dass sich der Benutzer nur einen Benutzernamen und ein Passwort merken braucht, und zwar zentral bei seiner Heimatinstitution. Jedoch ist es für den Benutzer wichtig zu wissen, dass er damit eine große Verantwortung für seine Browsersession auf sich nimmt, in der er persönlich authentifiziert ist. Der Benutzer verpflichtet sich somit möglichst keinen anderen Benutzer in seiner laufenden Browsersession arbeiten zu lassen und nach Beendigung der Arbeit den Browser so zu schließen, dass entweder automatisch die Browsersession gelöscht wird oder manuell über das Menü des Browsers. Shibboleth baut auf der Spezifikation von SAML auf. Dadurch kann ein Vertrauen zwischen den Beteiligten der Kommunikation aufgebaut werden. Die Beteiligten werden im Folgenden näher beschrieben. Die Heimatinstitution wird als Shibboleth Identity Provider (IdP) bezeichnet und repräsentiert beispielsweise eine Hochschule. Auf ihr wird die Shibboleth IdP Software installiert. Im IdP werden dann alle Dienste bei der Konfiguration registriert. Die Dienste werden auf einem Shibboleth Service Provider (SP) aufgesetzt, einem Webserver mit installierter Shibboleth SP Software. Die Shibboleth Software des IdP bzw. SP gewährleisten die notwendige Sicherheit 86 Vgl. Ramarao Kanneganti/Prasad Chodavarapu, Manning, SOA Security, S.10.

61 6.3 Bausteine einer Sitzung 47 um eine Dienste-Server Architektur aufbauen zu können. Die Authentifizierung gegenüber der Heimatinstitution erfolgt über ein weiteres SSO System (z.b. CAS, welches den Vergleich des Benutzername- Passwort-Paares, innerhalb der Heimatinstitution, mit dem im Verzeichnisdienst registrierten Benutzername-Passwort-Paar durchführt. 6.3 Bausteine einer Sitzung Bevor die einzelnen Schritte des Mechanismus einer Authentifizierung veranschaulicht werden, ist es wichtig einige grundlegenden Bausteine einer Webbrowser-Sitzung kennen zu lernen. Handle: In general, a Shibboleth handle is an opaque reference to a SAML subject, which the IdentityProvider passes to the ServiceProvider in an authentication assertion. The ServiceProvider subsequently uses the handle to communicate with the IdentityProvider (to retrieve attributes, for instance). When the IdentityProvider generates the handle, it is cached in memory along with the corresponding local principal name. Later, when the ServiceProvider requests attributes, the AttributeAuthority does a lookup on the handle in memory to recover the principal name. 87 Das Handle unterliegt einem time-to-live (z.b Sekunden), um Zeitüberschreitungen abzufangen. Cookie: A cookie is an information packet generated by a web server and passed to a web browser. The fact that a web server generates a cookie for a user does not guarantee that the user is allowed access to protected resources. The cookie simply points to user information in a data store from which an access decision can be derived. 88 Parameter: 89 The HTTP request to the identity provider s SSO service endpoint MUST use the GET method and MUST contain the following URL-encoded query string parameters: providerid: The unique identifier of the requesting service provider shire: The assertion consumer service endpoint at the service provider to which to deliver the authentication response 87 Vgl. SharedMemoryShibHandle, Stand: Vgl. Sun Java System Access Manager 7.1 Technical Overview, März 2007, S Vgl. Shibboleth Architecture, Protocols and Profiles, 10 September 2005, internet2-mace-shibboletharch-protocols pdf, S.9.

62 48 6 Shibboleth target: A value specified by the service provider to be returned by the identity provider in the TARGET form control or query string of the authentication response; it SHOULD be opaque to the identity provider, but MAY be the URL of a resource accessed at the service provider The query string MAY contain the following optional parameter: time: The current time, in seconds elapsed since midnight, January 1st, 1970, as a string of up to 10 base10 digits Listing 6.1: Beispiel einer IdP-URL bei WAYF 1 h t t p s : // i d p. hs f u r t w a n g e n. de / s h i b b o l e t h i d p /SSO 2? s h i r e=h t t p s : // s m s i n f o. hs f u r t w a n g e n. d e : / s h i b b o l e t h sp / S h i b b o l e t h. s s o /SAML/POST 3 &time = &t a r g e t=c o o k i e 5 &p r o v i d e r I d=h t t p s : // s m s i n f o. hs f u r t w a n g e n. d e : / s h i b b o l e t h sp 6.4 SSO Mechanismus Obwohl der Single Sign-On Mechanismus von Shibboleth komplex ist, präsentiert sich dieser dem sich authentifizierenden Benutzer durch eine sich schnell aufbauende Authentifizierungsmaske nach dem Versuch einen Dienst zu erreichen. Eine wahrnehmbare Verzögerung ist jedoch bei der Umleitung zurück zum Dienst vorhanden. Im Detail sieht der Mechanismus folgendermaßen aus: Abbildung 6.1: Shibboleth Mechanismus 1. Client erfragt Zugang zu einem Dienst eines Service Providers (SP). Dieser prüft, ob der Client bereits als authentifiziert bekannt ist.

63 6.4 SSO Mechanismus SP leitet Client zum WAYF Service um. GET Parameter werden der URL mitgegeben (target, shire, providerid, time, token, etc.) 3. WAYF nimmt Anfrage entgegen und überprüft, ob Client bereits ein Cookie des WAYF von einer früheren Anfrage besitzt. wenn Cookie vorhanden, Umleitung zum Handle Server des IdP aus den Cookie- Daten und weiter mit (5) wenn kein Cookie vorhanden, wird dem Client ein Formular angeboten für die Auswahl seines Identity Providers (IdP). 4. Client wählt somit seine Heimatinstitution und versendet Formular. 5. WAYF erzeugt Cookie mit preferiertem IdP (bzw. SSO) und leitet Client zum Handle Server des IdPs mit den angehängten GET Parametern um. IdP nimmt Authentifizierungsanfrage entgegen und überprüft ob ein Cookie einer früheren Authentifizierung vorhanden ist. Wenn ein Cookie vorhanden ist, weiter mit (9). Client wird zum Single Sign-On Service (SSO) umgeleitet. 6. SSO Service bietet ein Formular für die Eingabe eines Benutzername-Passwort-Paares an. 7. Benutzer authentifiziert sich gegenüber seiner Heimatinstitution (IdP). SSO überprüft Benutzername und Passwort mit Daten aus dem LDAP Server der Heimatinstitution. (SSO Service ist Shibboleth-unabhängig! z.b. CAS) 8. Bei erfolgreicher Authentifizierung leitet der SSO Service den Client zum Handle Server des IdP um. Dieser erzeugt ein Cookie beim Client. 9. Handle Server überprüft Cookie des SSO und generiert eine Webseite mit versteckten Formulardaten, darin legt er die Parameter und ein Handle für den authentifizierten Benutzer ab. Diese Seite wird per JavaScript automatisch an den Assertion Consumer Service (ACS) des SP abgeschickt. 10. SP speichert Handle und nutzt es, um ggf. Attribute des Benutzers beim IdP anzufragen. 11. Attribut-Anfrage des SP wird beim IdP erst auf Authentizität des SP-Serverzertifikats überprüft. Benutzer für das Handle wird erfasst, dann überprüft, ob Dienst Attribute zu Benutzer erhalten darf (laut Attribute Release Policy des IdP), diese werden dann zum SP gesendet. SP erhält Attribute und entscheidet, ob Benutzer Zugriff zum Dienst erhält.

64 50 6 Shibboleth Benutzer erhält ein Shibboleth Session Cookie. Attribute werden als Servervariablen initialisiert. 12. Client wird zum Dienst umgeleitet. 6.5 Schutz der Pfade Der Shibboleth Service Provider verankert sich bei seiner Installation in den Apache Webserver. Apache kann dadurch Einfluß auf die per SAML übermittelten Alias nehmen und sogar bevor eine Autorisierung innerhalb eines Dienstes geschieht, Entscheidungen treffen, wer für einen Dienst autorisiert ist oder nicht. AuthType: bei shibboleth wird die Authentifizierung durch Shibboleth aktiviert ShibRequireAll: bei on, müssen alle in Konfigurationsanweisungen require festgelegten Bedingungen erfüllt werden ShibRequireSession: signalisiert bei off die Nutzung von Lazy Session require: kann eine Access Control Rule angeben, beispielsweise valid-user für einen über authentifizierten Benutzer Einen Regulären Ausdruck (engl. Regular Expression, kurz RegEXp) nutzt Beispiel 1 des folgenden Listings, um sich auf einen Alias zu bezieht, der sich zuvor authentifizieren musste. Dies verdeutlicht die Tilde nach dem Alias, mit der ein Regulärer Ausdruck signalisiert wird. Der Zirkumflex markiert den Anfang eines RegEXp und das Dollarzeichen das Ende. Damit können Zeichenketten gefiltert werden. Ein komplexes Beispiel mit Abgleich eines Werts eines bestimmten Alias und Regulären Ausdrücken, die alle passen müssen, bietet das Beispiel 2. Listing 6.2: 2 Beispiele für Verzeichnisschutz mit Apache 1 #B e i s p i e l 1 : 2 AuthType S h i b b o l e t h 3 r e q u i r e a l i a s ~ ^ r e g e x $ 4 S h i b R e q u i r e S e s s i o n On 5 6 #B e i s p i e l 2 : 7 AuthType S h i b b o l e t h 8 r e q u i r e a l i a s 1 v a l u e 1 9 r e q u i r e a l i a s 2 ~ ^ r e g e x 1 $ 10 r e q u i r e a l i a s 3 ~ ^ r e g e x 2 $ 11 S h i b R e q u i r e A l l On 12 S h i b R e q u i r e S e s s i o n On Um einen neugierigen Blick auf den Fall zu werfen, dass eine Autorisierung für einen Zugriff nicht erteilt wird, kann hier auf die Abbildung auf Seite 71 verwiesen werden.

65 6.5 Schutz der Pfade Lazy Session Bei der Konfiguration für Lazy Session kann Einblick auf einen Teil eines Dienstes gewährt werden, bis zu einem Punkt, an dem der Benutzer nicht tiefer in den Dienst zugreifen kann ohne sich gegenüber dem IdP zu authentifizieren. Sicherheitshinweis: When using lazy sessions, the Shibboleth module will automatically make the principal s attributes available to the webapplication when a session is established. If no session is established, the module will clear the possible attribute- HTTP-headers from the request. This prevents header spoofing. If you are using these HTTP headers in your webapplication (highly likely), make sure the request always has to pass through the Shibboleth module. If it is possible to bypass the Shibboleth module, somebody might be able to manipulate your webapp severely by spoofing a header! (note that this problem isn t only subject to lazy sessions, but you probably won t notice that problem easily when using the passive lazy sessions mode) 90 Konfiguration in der shibboleth.xml des SP: requiresession : This attribute controls whether Shibboleth will forcibly establish an authenticated session with the user before handing off the request to the web server or application. If true, Shibboleth will force session establishment. If false (the default), applications are responsible for ensuring that a session exists if necessary, so-called lazy session establishment. Most deployments should not specify false for protected content without a full understanding of the implications. 91 Listing 6.3: Lazy Session 1 Lazy S e s s i o n e n t s p r i c h t d e r E i n s t e l l u n g r e q u i r e S e s s i o n=" f a l s e ". 2 F u l l S e s s i o n e n t s p r i c h t d e r E i n s t e l l u n g r e q u i r e S e s s i o n=" t r u e ". 3 4 <RequestMap a p p l i c a t i o n I d=" d e f a u l t "> 5 <! 6 This r e q u i r e s a s e s s i o n f o r documents i n / s e c u r e on t h e c o n t a i n i n g 7 h o s t w i t h h t t p and h t t p s on t h e d e f a u l t p o r t s. Note t h a t t h e name 8 and p o r t i n t h e <Host> e l e m e n t s MUST match Apache s ServerName and 9 Port d i r e c t i v e s o r t h e I I S S i t e name i n t h e <ISAPI> e l e m e n t below. 10 You s h o u l d a l s o be s u r e t h a t Apache s UseCanonicalName s e t t i n g i s On 11 > 12 <Host name=" s m s i n f o. hs f u r t w a n g e n. de "> 13 <! use r e q u i r e S e s s i o n=" t r u e " ( d e f a u l t : f a l s e ) o n l y i f 14 you do not want to use l a z y s e s s i o n w i t h t h i s host, i n s t e a d 15 you f o r c e s e s s i o n c r e a t i o n w i t h t r u e > 90 Vgl. SPProtectionConfig, ProtectingContent, Stand: Vgl. SPProtectionConfig, ProtectingContent,Stand:

66 52 6 Shibboleth 16 <Path name=" s e c u r e " authtype=" s h i b b o l e t h " r e q u i r e S e s s i o n=" t r u e " /> 17 <Path name=" s h i b b o l e t h " authtype=" s h i b b o l e t h " /> 18 </ Host> 19 </ RequestMap> In der.conf-datei für die Definition der <Location> Elemente des Apache für die zu schützenden Pfade: Listing 6.4: shibboleth.xml für Lazy Session 1 # l a z y s e s s i o n mode: 2 # Be s u r e t h e <Path> e l e m e n t i n <Host> e l e m e n t has 3 # a p a r a m e t e r r e q u i r e S e s s i o n=" f a l s e " ( d e f a u l t ) o r 4 # make s u r e i t not s e t! 5 <L o c a t i o n / s h i b b o l e t h> 6 AuthType S h i b b o l e t h 7 R e q u i r e S h i b b o l e t h 8 </ L o c a t i o n> Anschließend muss, zusätzlich zum Apache Webserver, der Shibboleth Daemon shibd auf dem smsinfo-server neu gestartet werden Full Session Konfiguration in der shibboleth.xml des SP: Listing 6.5: shibboleth.xml für Full Session 1 <RequestMap a p p l i c a t i o n I d=" d e f a u l t "> 2 <Host name=" s m s i n f o. hs f u r t w a n g e n. de "> 3 <Path name=" s e c u r e " authtype=" s h i b b o l e t h " r e q u i r e S e s s i o n=" t r u e " /> 4 <Path name=" s h i b b o l e t h " authtype=" s h i b b o l e t h " /> 5 </ Host> 6 </ RequestMap> In der.conf-datei für die Definition der <Location> elemente des Apache für die zu schützenden Pfade: Listing 6.6: Verzeichnisschutz mit Full Session 1 # s h i b b o l e t h s e s s i o n e s t a b l i s h m e n t mode: 2 # Be s u r e t h e <Path> e l e m e n t i n <Host> e l e m e n t has 3 # a p a r a m e t e r r e q u i r e S e s s i o n=" t r u e " 4 <L o c a t i o n / s e c u r e> 5 AuthType S h i b b o l e t h 6 S h i b R e q u i r e S e s s i o n On 7 R e q u i r e m a i l f u r t w a n g e n. de $ 8 </ L o c a t i o n> Nach einer Änderung reicht es aus, den Apache Webserver neu zu starten, um die Änderungen in der Apache conf-datei zu übernehmen. Welcher Alias für den Require verwendet wird, kann in der Datei AAP.xml recherchiert werden.

67 6.6 Servervariablen Servervariablen As a default and in most scenarios, the urn:mace:dir:attribute-def:edupersonprincipalname attribute should be mapped to REMOTE_USER. Even so, EPPN may not be provided by the AA, and REMOTE_USER might still be empty. 92 Nachfolgend ist eine auf Shibboleth Servervariablen eingegrenzte Liste (Stand: ): Listing 6.7: Liste von Shibboleth Servervariablen 1 HTTP_SHIB_ORIGIN_SITE h t t p s : // i d p. hs f u r t w a n g e n. de / s h i b b o l e t h i d p 2 HTTP_SHIB_IDENTITY_PROVIDER h t t p s : // i d p. hs f u r t w a n g e n. de / s h i b b o l e t h i d p 3 HTTP_SHIB_AUTHENTICATION_METHOD u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : a m : u n s p e c i f i e d 4 HTTP_SHIB_NAMEIDENTIFIER_FORMAT 5 HTTP_SHIB_ATTRIBUTES 6 HTTP_SHIB_APPLICATION_ID d e f a u l t 7 HTTP_SHIB_EP_AFFILIATION 8 HTTP_SHIB_EP_UNSCOPEDAFFILIATION 9 HTTP_REMOTE_USER 10 HTTP_SHIB_EP_PRIMARYAFFILIATION s t u d e n t 11 HTTP_SHIB_HFUPERSON_HFUROLE Student 12 HTTP_SHIB_HFUPERSON_HFUTITLE Student 13 HTTP_SHIB_EP_PRIMARYORGUNITDN ou=in, dc=hs furtwangen, dc=de 14 HTTP_SHIB_PERSON_COMMONNAME schwecht 15 HTTP_SHIB_PERSON_USERID schwecht 16 HTTP_SHIB_HFUPERSON_STUDYCOURSE CN 17 HTTP_SHIB_HFUPERSON_FACULTY IN 18 HTTP_SHIB_INETORGPERSON_MAIL H a r a l d. Schwecht@hs f u r t w a n g e n. de 19 HTTP_SHIB_HFUPERSON_OLATUSERNAME schwecht. hfu 20 HTTP_SHIB_PERSON_SURNAME Schwecht 21 HTTP_SHIB_INETORGPERSON_GIVENNAME H a r a l d 22 HTTP_SHIB_HFUPERSON_HOMEORGANIZATION Hochschule Furtwangen U n i v e r s i t y 23 REMOTE_USER H a r a l d. Schwecht@hs f u r t w a n g e n. de Dienste können je nach Implementierung folgendermaßen auf die Servervariablen und damit auf die Attribute zugreifen: Listing 6.8: Zugriff zu Servervariablen 1 PHP: T e i l von $_SERVER [ ] A r r a y 2 P e r l : T e i l von $ENV{} A r r a y 3 S S I : T e i l d e r Umgebungsvariablen 4 ( Bsp. : #echo v a r="http_shib_ep_personprincipalname" ) 5 ASP: Request. S e r v e r V a r i a b l e s (<name>) 6 JSP: r e q u e s t. getheader ( name ) ; 92 Vgl. SPProtectionConfig, ProtectingContent, Stand:

68 54 6 Shibboleth 6.7 Föderation Der zentrale Ansatz einer Heimatinstitution mit ihren angebotenen Diensten kann ebenso sehr einfach dezentral zu einer Föderation ausgebaut werden. Dazu akzeptieren mehrere Institutionen die Nutzung einer Auswahl an Service Providern, d.h. Diensten, durch Mitglieder anderer Institutionen. Dies kann den Nutzen haben, z.b. einen Bibliothekskatalog allgemein durchsuchen zu lassen, um den Benutzer z.b. bei der Fernleihe von Büchern zu unterstützen. Die Konfiguration wird im jeweiligen IdP der Institutionen vorgenommen. Für den föderativen Ansatz wird zusätzlich ein WAYF Dienst ( Where Are You From ) benötigt, der alle der Föderation angehörigen Heimatinstitutionen kennt und diese auflistet, sobald der Benutzer einen Dienst aufruft und noch nicht einmalig während der Browsersession authentifiziert wurde. Der Benutzer kann aus der Liste seine zugehörige Heimatinstitution auswählen und wird für die Authentifizierung ihr gegenüber zu dieser weitergeleitet. Der weitere Vorgang ist dann identisch wie im nicht föderativen Ansatz. Identity and Access also deals with identities both within an enterprise, as well as across enterprises. It also includes management of access policies to resources based on identity information and resource information. 93 Die wesentliche Shibboleth Föderation für Deutschland bildet die DFN-AAI: "Der DFN-Verein betreibt eine Authentifizierung- und Autorisierungs-Infrastruktur (DFN-AAI), um Nutzern von Einrichtungen aus Wissenschaft und Forschung (Teilnehmer) über das Wissenschaftsnetz einen Zugang zu geschützten Ressourcen (z.b. wissenschaftlichen Veröffentlichungen, lizenzpflichtiger Software, Großrechnern, GRID-Ressourcen) von Anbietern zu ermöglichen." Vgl. Understanding SOA Security, Design and Implementation, Second Edition, Axel Buecker/Paul Ashley/Martin Borrett et al., November 2007, Stand: , S Vgl. Deutsches Forschungsnetz, Stand:

69 6.8 Shibboleth Abbildung 6.2: Shibboleth Föderation Wie in der Abbildung demonstriert, können auch einzelne Service Provider mit einem Angebot an Services ohne IdP zum föderativen Ansatz einbezogen werden, z.b. eine Sternwarte, die immer aktuelle Aufnahmen zur Verfügung stellt. Anmerkend sei zum Schluss erwähnt, dass eine Header-Variable überschrieben werden kann durch einen ganz anderen Wert innerhalb einer Föderation, z.b. die als Standard durch das Shibboleth Attribut edupersonprincipalname gesetzte Variable REMOTE_USER. Deshalb muss Sorge getragen werden, dass Shibboleth Attribute (SAML-URN, Benennung des Header und des Alias) innerhalb einer Föderation angeglichen weden müssen, welche einem allgemeinen Standard angehören. 6.8 Shibboleth 2.0 Das derzeit im Beta-Stadium befindliche Shibboleth 2.0 bietet u.a. folgende Features: eine Menge neuer Funktionen auf Basis der erweiterten Möglichkeiten von SAML 2.0 Verbesserungen, basierend auf den Erfahrungen mit Shibboleth 1.x Ein Single LogOut (SLO), welches die Sitzung im IdP und die dazugehörigen Sitzungen in allen SPs beendet und der Benutzer dadurch global ausgeloggt werden kann. weiterhin Kompatibilität zu Shibboleth Zusammenfassung Shibboleth bietet, dadurch dass es auf der SAML-Spezifikation basiert, einen Mechanismus für die Authentifikation und Autorisation, um dadurch das Verfahren des Single Sign-On zu

70 56 6 Shibboleth realisieren. Dieser Mechanismus wurde im Detail beschrieben und illustriert und die technische Realisierung, durch den Schutz der Pfade auf dem Webserver zum Einen und die Bereitstellung von Servervariablen zum Anderen, beschrieben. Abschließend wurde der Begriff Föderation im Sinne von Shibboleth veranschaulicht und die wesentlichsten Besonderheiten der nächsten Version von Shibboleth präsentiert.

71 7 Single Sign-On an der HFU Auf eine kurze Einleitung folgt eine auf das Wesentliche reduzierte Beschreibung zur Installation eines Shibboleth Service Providers. 7.1 Einleitung Da vor Beginn dieser Diplomarbeit bereits ein fertig installierter Shibboleth Identity Provider (IdP) existierte, hat sich die hier vorgestellte Installation von Shibboleth auf die Service Provider (SP) beschränkt. Für Hilfestellung zur Installation und erste Konfiguration des Shibboleth Identity Providers soll auf die Webseite des Anbieters 95 Anpassungen am Identity Provider, welche für die Inbetriebnahme der hier beschriebenen Service Provider notwendig sind, wurden auf einem Server mit Betriebsystem SuSE Enterprise Linux v10 durchgeführt und sollen im Folgenden beschrieben werden. Zusätzlich werden Installationen und Konfigurationen von Service Providern beschrieben, die auf Ubuntu und OpenSuSE durchgeführt wurden. 7.2 Shibboleth Service Provider Installation In diesem Kapitel soll die Installation des original Shibboleth Service Provider 96 beschrieben werden. Das ausgewählte System für die Installation befindet sich zudem in einem stark geschützten Netzwerk und ist nur über NAT 97 von einem anderen Rechner und Port aus erreichbar. Diese Tatsache wurde jedoch erst im Laufe der Konfiguration- und anschließenden Testphase deutlich. Dadurch einschränkend ist zu sagen, dass Verbindungen zum bereits vorhandenen Apache Webserver nur über HTTPS auf Port 9443 möglich sind. Nachdem deutlich war, dass es sich um ein Linux Betriebssystem handelte, war die erste Frage bei der Kontaktaufnahme mit dem System, welche Distribution und Kernel-Version vorliegen. Folgende zwei Kommandos ergaben, dass es sich um ein OpenSuSE 10.2 mit einem er Kernel handelt: 95 InstallingShibboleth, Stand: Vgl Network Address Translation (NAT).

72 58 7 Single Sign-On an der HFU 1 s m s i n f o : ~ # c a t / e t c /SuSE r e l e a s e 2 opensuse ( i ) 3 VERSION = s m s i n f o : ~ # uname r d e f a u l t Listing 7.1: Betriebssystem des Dienstservers Da die Arbeit mit dem Server nur über SSH erfolgt hat, ließ sich keine CD einlegen, um Open- SuSE mit neuen Paketen zu versorgen, zudem war über die Konfigurationsumgebung YaST keine Paketquelle erreichbar, wegen des NAT bzw. möglicher Firewallregeln der Verwaltung. Somit mußte umständlich jedes einzelne notwendige Paket und Abhängigkeiten dazu per SSH von einem System zum anderen kopiert werden. Dazu hat sich als sehr nützlich die Befehlsverkettung herausgestellt, mit der herausgefunden werden kann, welche Versionen eines Pakets bereits installiert sind, beispielsweise hier: Listing 7.2: Suche nach RPM Paketen 1 rpm q a g r e p apache 2 3 Output: 4 apache2 p r e f o r k apache apache2 mod_php Die Königsdisziplin einer Installation stellt immer noch die Kompilierung aus den Quelldateien dar. Damit wird ein hohes Maß an Kompatibilität mit dem System erreicht. Aus diesem Grund werden für den folgenden Vorgang der Installation über eine exzenlente Anleitung 98 einige Pakete als Voraussetzung benötigt (die Existenz kann dazu mit der gerade vorgestellten Befehlsverkettung geprüft werden): -C/C++ Compiler und Tools (z.b. gcc-c++) -doxygen (für log4cpp) -patch (für xerces261) -python (für cxxtest) -apache2-devel (für shibboleth) Anschließend sollten die erforderlichen RPM 99 Pakete geholt werden (auf Abhängigkeiten soll hier nicht eingegangen werden): Listing 7.3: Installation des Shibboleth Service Providers 1 wget h t t p : // s h i b b o l e t h. i n t e r n e t 2. edu / downloads /SRPMS/ c x x t e s t noarch. rpm 2 wget h t t p : // s h i b b o l e t h. i n t e r n e t 2. edu / downloads /SRPMS/ log4cpp rc1 1. s r c. rpm 3 wget h t t p : // s h i b b o l e t h. i n t e r n e t 2. edu / downloads /SRPMS/ opensaml s r c. rpm 4 wget h t t p : // s h i b b o l e t h. i n t e r n e t 2. edu / downloads /SRPMS/ s h i b b o l e t h s r c. rpm 5 wget h t t p : // s h i b b o l e t h. i n t e r n e t 2. edu / downloads /SRPMS/ x e r c e s c s r c. rpm 98 Vgl. DFN-AAI, Installation SP 1.3 unter opensuse 10.2, 99 RPM Package Manager (RPM), ein Software-Paketverwaltungssystem.

73 7.2 Shibboleth Service Provider Installation 59 6 wget h t t p : // s h i b b o l e t h. i n t e r n e t 2. edu / downloads /SRPMS/xml s e c u r i t y c s r c. rpm RPM aus Source erzeugen, danach i n s t a l l i e r e n ( l o g 4 c p p ) : 10 r p m b u i l d r e b u i l d log4cpp rc1 1. s r c. rpm 11 rpm Uhv.. / RPMS/ i / log4cpp rc1 1. i rpm 12.. / RPMS/ i / log4cpp d e v e l rc1 1. i rpm RPM aus Source erzeugen, danach i n s t a l l i e r e n ( x e r c e s ) : 15 r p m b u i l d r e b u i l d x e r c e s c s r c. rpm 16 rpm Uhv.. / RPMS/ i / x e r c e s c i rpm 17.. / RPMS/ i / x e r c e s c d e v e l i rpm RPM aus Source erzeugen, danach i n s t a l l i e r e n ( xml s e c u r i t y und c x x t e s t ) : 20 r p m b u i l d r e b u i l d D x e r c e s v e r 261 xml s e c u r i t y c s r c. rpm 21 rpm Uhv.. / RPMS/ i /xml s e c u r i t y c i rpm 22.. / RPMS/ i /xml s e c u r i t y c d e v e l i rpm 23 rpm Uhv c x x t e s t noarch. rpm RPM aus Source erzeugen, danach i n s t a l l i e r e n ( opensaml ) : 26 r p m b u i l d r e b u i l d D x e r c e s v e r 261 opensaml s r c. rpm 27 rpm Uhv.. / RPMS/ i / opensaml i rpm 28.. / RPMS/ i / opensaml d e v e l i rpm RPM aus Source erzeugen, danach i n s t a l l i e r e n ( s h i b b o l e t h ) : 31 r p m b u i l d r e b u i l d w i t h apache22 D x e r c e s v e r 261 s h i b b o l e t h s r c. rpm 32 rpm Uhv.. / RPMS/ i / s h i b b o l e t h i rpm 33.. / RPMS/ i / s h i b b o l e t h d e v e l i rpm Im l e t z t e n S c h r i t t wurden mit dem B e f e h l r p m b u i l d f o l g e n d e RPM Pakete e r z e u g t : 36 / u s r / s r c / p a c k a g e s /RPMS/ i / s h i b b o l e t h i rpm 37 / u s r / s r c / p a c k a g e s /RPMS/ i / s h i b b o l e t h d e v e l i rpm 38 / u s r / s r c / p a c k a g e s /RPMS/ i / s h i b b o l e t h s e l i n u x p o l i c y t a r g e t e d i rpm Damit existiert nun ein eigens für das System kompilierter Shibboleth Service Provider v1.3-11, anschließend wurde mit dem Befehl rpm der Service Provider installiert. Die Installation des Shibboleth Service Providers ist nun damit komplett abgeschlossen. Eine rekursive Auflistung der genutzten Pakete bringt Aufschluss über Umfang der Abhängigkeiten: Listing 7.4: Übersicht der Paketquellen 1 l s R 2 3. : 4 apache2 o p e n s s l 5 c x x t e s t noarch. rpm saml 6 doxygen s h i b b o l e t h s r c. rpm 7 gcc x e r c e s c s r c. rpm 8 log4cpp rc1 1. s r c. rpm xml s e c u r i t y c s r c. rpm 9 opensaml s r c. rpm / a p a c h e 2 : 12 apache2 d e v e l i rpm l i b a p r u t i l i rpm 13 c y r u s s a s l d e v e l i rpm l i b a p r u t i l 1 d e v e l i rpm 14 db d e v e l i rpm openldap2 c l i e n t i rpm 15 l i b a p r i rpm openldap2 d e v e l i rpm 16 l i b a p r 1 d e v e l i rpm 17

74 60 7 Single Sign-On an der HFU 18. / d o x y g e n : 19 doxygen i rpm / g c c : 22 cpp i rpm 23 cpp _ i rpm 24 f a s t j a r i rpm 25 gcc33 l o c a l e i rpm 26 gcc i rpm 27 gcc _ i rpm 28 gcc41 c _ i rpm 29 gcc41 g i j _ i rpm 30 gcc41 i n f o _ i rpm 31 gcc41 t e s t r e s u l t s _ i rpm 32 gcc ada i rpm 33 gcc c i rpm 34 gcc f o r t r a n i rpm 35 gcc g i j i rpm 36 gcc i n f o i rpm 37 gcc j a v a i rpm 38 gcc l o c a l e i rpm 39 gcc obj c i rpm 40 gcc objc i rpm 41 l i b f f i _ i rpm 42 l i b f f i 4 1 d e v e l _ i rpm 43 l i b f f i d e v e l i rpm 44 l i b g c c _ i rpm 45 l i b g c j 4 1 d e v e l _ i rpm 46 l i b g c j d e v e l i rpm 47 l i b g f o r t r a n _ i rpm 48 l i b m u d f l a p _ i rpm 49 l i b o b j c _ i rpm 50 l i b s t d c _ i rpm 51 l i b s t d c ++41 d e v e l _ i rpm 52 l i b s t d c++ d e v e l i rpm / o p e n s s l : 55 o p e n s s l d e v e l d i rpm xmlsec1 o p e n s s l i rpm 56 xmlsec i rpm xmlsec1 o p e n s s l d e v e l i rpm 57 xmlsec1 d e v e l i rpm / s a m l : 60 c u r l d e v e l i rpm z l i b d e v e l i rpm 61 l i b i d n d e v e l i rpm 7.3 Shibboleth Service Provider Konfiguration Umfangreiche Dokumentation 100 zu den XML-Elementen und -Attributen bietet das Wiki von Shibboleth. Ausgestattet mit diesen Informationen, kann nun die Konfiguration des Shibboleth Service Providers angegangen werden, dafür sind - am Beispiel des SMS-Infosystems - folgende Schritte notwendig: 100Vgl.

75 7.3 Shibboleth Service Provider Konfiguration 61 Anpassungen der shibboleth.xml für den Service Provider vornehmen: 1. Im Block Local muss in den Elementen Host und Path der Hostname und evtl. Port angepasst werden, falls nicht Port 80 oder Im Block Application muss dem Attribut providerid der Wert gegeben werden, der später auch in den Metadaten des Identity Providers dem Attribut entityid dieses Service Providers entspricht. Auf die Gleichheit der Attributwerte muss genaustens Sorge getragen werden. providerid= 3. Im Block Application muss außerdem somit das Element Sessions angepasst werden: handlerurl= /shibboleth-sp/shibboleth.sso a) Im Element Sessions das Kindelement SessionInitiator anpassen: id= hfu <! für hfu-metadata.xml Metadaten > Location= /WAYF/idp.hsfurtwangen.de wayfurl= Für wayfurl kann der direkte SSO Dienst des IdP angegeben werden, da momentan kein WAYF installiert ist. b) Im Element MetadataProvider muss die im Service Provider lokal abgelegte Datei mit den Metadaten angegeben werden: uri= /etc/shibboleth/hfu-metadata.xml 4. Im Block CredentialsProvider muss das SSL-Key und -Zertifikat festgelegt werden: Listing 7.5: SSL-Konfiguration des Servers 1 <Key> 2 <Path>/ e t c / apache2 / s s l. key / wild_hs f u r t w a n g e n. key</ Path> 3 </ Key> 4 < C e r t i f i c a t e> 5 <Path>/ e t c / apache2 / s s l. c r t / wild_hs furtwangen_de. c r t</ Path> 6 </ C e r t i f i c a t e> Einfügen der Metadaten (hfu-metadata.xml) und der AAP.xml - mit dem Mapping für die Shibboleth Attribute - in das Verzeichnis des SP vornehmen. Server-Zertifikate mußten keine erstellen werden, da bereits durch den laufenden Apache Webserver vorhanden. Server-Zertifikat und Service Provider Informationen in den Metadaten des Identity Providers registrieren: Listing 7.6: Metadaten des Service Providers 1 <E n t i t y D e s c r i p t o r e n t i t y I D=" h t t p s : // s m s i n f o. hs f u r t w a n g e n. de / s h i b b o l e t h sp "> 2 <SPSSODescriptor

76 62 7 Single Sign-On an der HFU 3 p r o t o c o l S u p p o r t E n u m e r a t i o n=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 1 : p r o t o c o l "> 4 <K e y D e s c r i p t o r use=" s i g n i n g "> 5 <d s : K e y I n f o> 6 <ds:x509data> 7 <d s : X C e r t i f i c a t e> 8 <! an d i e s e r S t e l l e s t e h t das Z e r t i f i k a t des S e r v e r s > 9 </ d s : X C e r t i f i c a t e> 10 </ ds:x509data> 11 </ d s : K e y I n f o> 12 </ K e y D e s c r i p t o r> 13 <NameIDFormat>u r n : m a c e : s h i b b o l e t h : 1. 0 : n a m e I d e n t i f i e r</nameidformat> 14 <AssertionConsumerService index="1" i s D e f a u l t=" true " 15 B i n d i n g=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o f i l e s : b r o w s e r p o s t " 16 Location=" h t t p s : // smsinfo. hs furtwangen. de / Shibboleth. sso /SAML/POST" /> 17 <A s s e r t i o n C o n s u m e r S e r v i c e i n d e x=" 2 " 18 B i n d i n g=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o f i l e s : a r t i f a c t 01" 19 L o c a t i o n=" h t t p s : // s m s i n f o. hs f u r t w a n g e n. de / S h i b b o l e t h. s s o /SAML/ A r t i f a c t " /> 20 <A s s e r t i o n C o n s u m e r S e r v i c e i n d e x=" 3 " 21 B i n d i n g=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o f i l e s : b r o w s e r p o s t " 22 Location=" h t t p s : // smsinfo. hs furtwangen. de / shibboleth sp / Shibboleth. sso /SAML/POST" /> 23 <A s s e r t i o n C o n s u m e r S e r v i c e i n d e x=" 4 " 24 B i n d i n g=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o f i l e s : a r t i f a c t 01" 25 L o c a t i o n=" h t t p s : // s m s i n f o. hs f u r t w a n g e n. de / s h i b b o l e t h sp / S h i b b o l e t h. s s o /SAML/ A r t i f a c t " /> 26 <A s s e r t i o n C o n s u m e r S e r v i c e i n d e x=" 5 " 27 B i n d i n g=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o f i l e s : b r o w s e r p o s t " 28 Location=" h t t p s : // smsinfo. hs furtwangen. de:9443 / shibboleth sp / Shibboleth. sso /SAML/POST" /> 29 <A s s e r t i o n C o n s u m e r S e r v i c e i n d e x=" 6 " 30 B i n d i n g=" u r n : o a s i s : n a m e s : t c : S A M L : 1. 0 : p r o f i l e s : a r t i f a c t 01" 31 L o c a t i o n=" h t t p s : // s m s i n f o. hs f u r t w a n g e n. d e : / s h i b b o l e t h sp / S h i b b o l e t h. s s o /SAML/ A r t i f a c t " /> 32 </ SPSSODescriptor> 33 <O r g a n i z a t i o n> 34 <OrganizationName x m l : l a n g=" en ">HFU SMSinfo S e r v i c e Provider</ OrganizationName> 35 <OrganizationDisplayName x m l : l a n g=" en ">HFU SMSinfo S e r v i c e</ OrganizationDisplayName> 36 <OrganizationURL x m l : l a n g=" en ">h t t p s : // smsinfo. hs furtwangen. de:9443</ OrganizationURL> 37 </ O r g a n i z a t i o n> 38 <C o n t a c t P e r s o n contacttype=" t e c h n i c a l "> 39 <SurName>T e c h n i c a l S h i b b o l e t h Support</SurName> 40 < Address>postmaster@hs furtwangen. de</ Address> 41 </ C o n t a c t P e r s o n> 42 </ E n t i t y D e s c r i p t o r> Vorsicht ist mit jeglicher Anleitung geboten, die sich auf die Dateien apache*.config beziehen. Es hat sich im Laufe der Konfiguration herausgestellt, dass diese nicht angepasst werden müssen, da automatisch Anpassungen in verschiedenen Dateien vorgenommen wurden, unter anderem in der shib.conf Datei. Stattdessen in der /etc/apache2/conf.d/shib.conf folgende Stellen anpassen bzw. ergänzen: Listing 7.7: Verzeichnisschutz mit Apache 1 A l i a s / s h i b b o l e t h sp / main. c s s / u s r / s h a r e / doc / p a c k a g e s / s h i b b o l e t h / main. c s s 2 A l i a s / s h i b b o l e t h sp / l o g o. j p g / u s r / s h a r e / doc / p a c k a g e s / s h i b b o l e t h / l o g o. j p g 3 4 # s h i b b o l e t h s e s s i o n e s t a b l i s h m e n t mode: 5 # Be s u r e t h e <Path> e l e m e n t i n <Host> e l e m e n t has 6 # a p a r a m e t e r r e q u i r e S e s s i o n=" t r u e " 7 # This one i s f o r t e s t i n g : 8 <L o c a t i o n / s e c u r e> 9 AuthType s h i b b o l e t h 10 S h i b R e q u i r e S e s s i o n On 11 R e q u i r e m a i l f u r t w a n g e n. de $ 12 </ L o c a t i o n> # " l a z y s e s s i o n " mode:

77 7.3 Shibboleth Service Provider Konfiguration # Be s u r e t h e <Path> e l e m e n t i n <Host> e l e m e n t has 16 # a p a r a m e t e r r e q u i r e S e s s i o n=" f a l s e " ( d e f a u l t ) o r 17 # make s u r e i t not s e t! 18 # This i s a l s o f o r t e s t i n g l a z y s e s s i o n : 19 <L o c a t i o n / s h i b b o l e t h> 20 AuthType S h i b b o l e t h 21 R e q u i r e S h i b b o l e t h 22 </ L o c a t i o n> An dieser Stelle sollen auch Ergänzungen aufgeführt werden, die im späteren Kapitel erst in die shib.conf geschrieben werden: Listing 7.8: Verzeichnisschutz der Dienste 1 # t h i s i s t h e SSO v e r s i o n o f SMS I n f o s y s t e m 2 <L o c a t i o n / s s o> 3 AuthType s h i b b o l e t h 4 S h i b R e q u i r e S e s s i o n On 5 R e q u i r e m a i l f u r t w a n g e n. de $ 6 </ L o c a t i o n> 7 8 # t h i s i s t h e SSO f o l d e r f o r t h e RZ Password Change S e r v i c e 9 <L o c a t i o n / rzpwd> 10 AuthType s h i b b o l e t h 11 S h i b R e q u i r e S e s s i o n On 12 R e q u i r e m a i l f u r t w a n g e n. de $ 13 </ L o c a t i o n> Verzeichnis httpd erzeugen sowie Datei native.log für das Logging von Shibboleth erzeugen: mkdir /var/log/httpd touch /var/log/httpd/native.log Das Shibboleth Daemon Startup Script aus dem Shibboleth Verzeichnis nach init.d kopieren: cp /etc/shibboleth/shibd /etc/init.d/ Dieser Datei notwendige Rechte geben, um sie auszuführen zu können: chmod a+x shibd -Den Shibboleth Daemon versuchsweise testen (siehe auch [BrVdVe]): /usr/sbin/shibd Danach lohnt sich ein Blick in die Log-Datei: vim /var/log/shibboleth/shibd.log Wenn nur INFO Meldungen erscheinen und keine ERROR Meldungen, kann der Daemon in Betrieb genommen werden: /etc/init.d/shibd start

78 64 7 Single Sign-On an der HFU Nun den Apache Webserver neustarten: /etc/init.d/apache2 restart Zum Schluss, Firewall Einstellungen prüfen, wie in einer umfangreichen Anleitung 101 empfohlen: inbound traffic: webserver: port 80 and/or 443 are used by any browser-user outbound: Shibboleth daemon (shibd): has to be able to connect to every remote IdP in the federation on port 8443 for attribute fetching NTP: a query from a client (like our server) is performed on a remote NTPserver that runs on port 123. Die Konfiguration des Shibboleth Service Providers ist nun damit komplett abgeschlossen. 7.4 Metadaten Shibboleth relies on metadata to identify and distribute trusted IdP, SP, and certificate authority information. [...] 102 Die Metadaten der HFU sind in XML-basierter Form in der Datei hfu-metadata.xml beim IdP, sowie allen SP s abgelegt. Sie stellen dabei (derzeit) alle eine Kopie der beim IdP hinterlegten Datei dar. Für den Fall, dass eine Föderation eingerichtet werden sollte, kann dies natürlich anders ausfallen und muss je nach Situation zwischen den Föderationspartnern (jeweils Dienstanbieter und Dienstkonsumenten) ausgehandelt werden. Beispielsweise macht es weniger Sinn private Dienste der Hochschule innerhalb der Föderation (über die Metadaten) zu propagieren, wie es für den Dienst zum Ändern des Rechenzentrum-Passworts zutreffen würde. In den Metadaten werden die jeweiligen Zertifikate der Server abgelegt, damit sich der IdP und die SP s gegenseitig darüber vertrauen können. Dies geschieht, damit die gemeinsame Kommunikation nicht im Vorfeld abgelehnt wird. Die Zertifikate werden dabei in den SAML Protocols innerhalb einer XML Signature 103 eingebettet. Beispielsweise in einer SAML Response, die diese XML Signature mit Zertifikat, dann einen Status der SAML Bearbeitung und anschließend eine Assertion mit AuthenticationStatement beinhaltet. 101Vgl Vgl. Shibboleth Glossary, Stand: Spezifikation zur Definition einer XML-basierten Auszeichnungssprache für digitale Signaturen.

79 7.5 Attribute 65 Die Struktur der Metadaten ist für den IdP unterschiedlich wie für die SP, jedoch können die für alle SP durchzuführenden Anpassungen vergleichbar auch für die Metadaten des IdP Anwendung finden: entityid: stellt eine eineindeutige Bezeichnung des IdP bzw. SP dar Zertifikat: muss bis auf die kryptierte Zeichenkette davor und dahinter gekürzt werden ArtifactResolutionService Location: exakter Verweis auf den ARS des SP (Kommunikation mit ACS des SP) AssertionConsumerService Location: exakter Verweis auf den ACS des SP (Kommunikation mit ARS des IdP) SingleSignOnService Location: Ort, der auf Authentifizierungsmaske verweist (nur bei IdP) AttributeService Location: Ort, der auf die Attribute Authority verweist (nur bei IdP) Organization: Angaben über die Institution die diesen Provider betreibt (beliebig) ContactPerson: Angaben über ein Kontakt zur Institution die diesen Provider betreibt (beliebig) Eine - auf das Wesentliche reduzierte - Datei der Metadaten (hfu-metadata.xml) befindet sich im Anhang auf Seite 101. Die eingebetteten Zertifikate wurden dabei der Übersichtlichkeit halber durch Auslassungspunkte ersetzt. 7.5 Attribute An der Hochschule Furtwangen University (HFU) werden alle Professoren, Mitarbeiter und Studenten in einem LDAP-Verzeichnis organisiert. Jeder dieser Benutzer verfügt dabei über eine Reihe von Eigenschaften, die Shibboleth als Attribute zugeführt werden können. Hier ein Auszug meiner Eigenschaften:

80 66 7 Single Sign-On an der HFU Abbildung 7.1: Screenshot Verzeichniseintrag Attribute Resolver Der Attribute Resolver wird in der Datei resolver.xml 104 konfiguriert. Hier wird konfiguriert woher die Daten stammen und wie sie auf dem Weg zum IdP modifiziert werden können. Attribute können durch den IdP aus unterschiedlichen Datenquellen zugezogen werden 105 : 104Vgl. IdPAttributeConfig, Stand: Vgl. Accessing and Releasing an Attribute from the IdP, Stand

81 7.5 Attribute 67 aus relationalen Datenbanken, durch Ausführen von vorkonfigurierten SQL Anfragen: per Java Database Connectivity (JDBC), einer Datenbankschnittstelle der Java-Plattform. aus einem LDAP Verzeichnis, durch Ausführen eines LDAP-Filters auf einen LDAP- Knoten: per Java Naming and Directory Interface (JNDI), einer Java-Schnittstelle für Namens- und Verzeichnisdienste. aus einer festen Definition: per Static Data Connector kann im IdP ein Attribut fest für alle Benutzer definiert werden. Sinnvoll um allen Benutzern des IdP z.b. ein Attribut geben. aus einer benutzerdefinierten Datenquelle: per Custom Data Connector kann im IdP eine benutzerdefinierte Schnittstelle über ein gut konfigurierbares Konstrukt selbst entworfen werden. Hinweis: Es liegt auf der Hand, dass unnötige oder zu empfindliche Daten erst gar nicht geholt werden. Dies würde den Aufwand der Konfiguration und Wartung, sowie für die Sicherheit (Policies) unnötig erhöhen und spiegelt den Sinn von Shibboleth nicht wider. Nachdem nun die Rohdaten aus der Datenquelle zugezogen worden sind und als Attribute bereitstehen, kann über Filterregeln konfiguriert werden - den so genannten AttributeDefinitions (innerhalb der resolver.xml) - ob und wie Attribute transformiert, gefiltert, zusammengesetzt, aufgespalten oder sonst wie bearbeitet werden sollen. Alle Attribute, die der IdP einem SP zukommen lassen soll, müssen beim IdP in ein SAML-basierendes XML-Format umgewandelt werden. Dies wird für jedes Attribut in der resolver.xml eineindeutig definiert. SAML Attribute müssen ein URN-basierten 106 Namen (z.b. urn:mace:dir:attribute-def:givenname) und einen Wert (z.b. Harald) besitzen Attribute Resolution Test Der Shibboleth IdP bietet im Pfad bin/ ein Werkzeug, den Attribute Resolution Test 107, mit dem ein Administrator seine Arbeit überprüfen kann, nachdem er Änderungen an seiner Attribute Resolver Konfiguration in resolver.xml durchgeführt hat. Der Administrator hat damit einen Überblick, aller dem IdP zur Verfügung stehenden Attribute eines Benutzers und kann dadurch auch die AttributeDefinitions prüfen. Die entityid des IdP aus den Metadaten wird dazu als responder angegeben. Dazu sind folgende Kommandos (bitte je nach Installation anpassen) in der Eingabeaufforderung notwendig: 106Uniform Resource Name (dt. einheitlicher Name für Ressourcen). 107Vgl. AttributeResolutionTest, Stand:

82 68 7 Single Sign-On an der HFU export IDP_HOME=/opt/catalina/shibboleth-idp $IDP_HOME/bin/resolvertest responder= user=schwecht resolverxml=file:///$idp_home/etc/resolver.xml Die Ausgabe ähnelt der im Kapitel Attribute Release Test, mit dem Unterschied, dass der Attribute Resolution Test keine Attribute Release Policy (siehe folgendes Kapitel) berücksichtigt, demzufolge eine policy-free attribute resolution durchführt Attribute Release Policy Eine Attribute Release Policy 108 bietet eine Möglichkeit durch ein Regelwerk zu filtern, welche Attribute vom IdP zu welchen Attribute-anfordernden Service Providern geschickt werden dürfen. Es werden zwei Arten von ARPs unterschieden: 1. ein Attribut-Filter, der auf alle Benutzer global angewandt wird (site ARP): arp.site.xml 2. ein Attribut-Filter für einzelne Benutzer (user ARP): arp.user.<benutzername>.xml Sobald der Service Provider (über seinen Attribute Requester) eine Anfrage an die Attribute Authority (AA) des IdP richtet, generiert die AA aus den Filterregeln der ARPs einen persönlichen Filter (effective ARP) für den jeweiligen Benutzer. Folgende Regeln werden angewendet: 1. Alle zum Benutzer passenden Filterregeln identifizieren und für den weiteren Ablauf isolieren, d.h. die arp.site.xml (site ARP) sowie die arp.user.<benutzername>.xml (user ARP). 2. Daraus alle Regeln identifizieren, welche die Anfrage betreffen: a) Alle hieraus als default gekennzeichneten Regeln ohne weitere Anpassungen zum effective ARP hinzufügen. b) Alle hieraus nicht als default gekennzeichneten Regeln, müssen erstens zur Anfrage des SP passen und zweitens nicht für die Kennzeichnung des SP (providerid) ausgeschlossen sein. Trifft beides zu, wird die Regel der effective ARP hinzugefügt. 3. Einen Filter für den Benutzer zusammenbauen: a) Jeweils überprüfen, ob für ein Attribut eine Aussage existiert, die alle Attributwerte als abzulehnen spezifiziert. Diese Attribute im Folgenden nicht mehr berücksichtigen. 108Vgl. IdPARPConfig, Stand:

83 7.5 Attribute 69 b) Jeweils überprüfen, ob für ein Attribut eine Aussage existiert, die alle Attributwerte als zuzulassen spezifiziert. Für jedes Attribut eine temporäre Liste von zugehörigen Regeln generieren, welche alle Werte des Attributs beinhaltet. c) Für jedes übrige Attribut auch eine temporäre Liste von zugehörigen Regeln generieren, welche alle Attributwerte beinhaltet, die mit permit gekennzeichnet sind (alle Attributwerte mit deny werden somit nicht übernommen). 4. Die resultierende Liste jedes Attributs repräsentiert die Allowable Release Values des jeweiligen Attributs. Sie wird als Maske für die - vom Attribute Resolver - zugezogenen Attribute genutzt, um ein SAML Assertion zu generieren. Das folgende Beispiel soll erstens veranschaulichen, wie eine ARP grundsätzlich aufgebaut ist und zweitens den Fall 3b in der Codezeile 13 sowie den Fall 3c in Codezeile 8 und 9 veranschaulichen. Um das XML-Dokument kurz zu halten wurde hier mit Auslassungspunkten gearbeitet. Listing 7.9: Beispiel einer Attribute Release Policy 1 <A t t r i b u t e R e l e a s e P o l i c y... > 2 <Rule> 3 <Target> 4 <R e q u e s t e r>h t t p s : // s m s i n f o. hs f u r t w a n g e n. d e : / s h i b b o l e t h sp</ R e q u e s t e r> 5 <AnyResource /> 6 </ Target> 7 <A t t r i b u t e name=" u r n : m a c e : d i r : a t t r i b u t e d e f : e d u P e r s o n S c o p e d A f f i l i a t i o n "> 8 <Value r e l e a s e=" deny ">member@example. edu</ Value> 9 <Value r e l e a s e=" p e r m i t ">m e m b e b e i s p i e l. edu</ Value> 10 </ A t t r i b u t e> <A t t r i b u t e name=" u r n : m a c e : d i r : a t t r i b u t e d e f : m a i l "> 13 <AnyValue r e l e a s e=" p e r m i t " /> 14 </ A t t r i b u t e> 15 </ Rule> <! mehrere Rule Elemente m ö g l i c h > 18 <Rule> </ Rule> </ A t t r i b u t e R e l e a s e P o l i c y> Attribute Release Test Das selbe Werkzeug, dass der Shibboleth IdP im Pfad bin/ bereits für den Attribute Resolution Test angeboten hat, kann hier jedoch für den Attribute Release Test 109 verwendet werden. Beim Attribute Release Test kann ein Administrator seine Arbeit überprüfen, nachdem er Änderungen 109Vgl. AttributeReleaseTest, Stand:

84 70 7 Single Sign-On an der HFU an seiner Attribute Resolver Konfiguration in resolver.xml oder der Attribute Release Policy durchgeführt hat. Der Administrator hat damit einen Überblick, aller dem IdP zur Verfügung stehenden Attribute eines Benutzers oder bei Angabe des Parameters requester (einem Service Provider), alle Attribute im Einklang mit den ARPs, welche dieser Service Provider erhält. Die dazu notwendigen Kommandos (bitte je nach Installation anpassen) in der Eingabeaufforderung finden sich im Anhang auf Seite Attribute Acceptance Policy Die Attribute Acceptance Policy (AAP), abgelegt in der Datei AAP.xml, verkörpert den Gegenpart der resolver.xml des IdP, jedoch auf Seiten des Service Provider. Sie definiert Regeln für die Bearbeitung von SAML Attributen durch den SP. Diese Regeln beinhalten: Eine Entscheidung, ob die Werte des Attributs zu äkzeptierenßind. Nicht akzeptierte Werte werden herausgefiltert, bevor Informationen für Gebrauch durch Anwendungen extrahiert werden. Die rohen, ungefilterten Assertions können noch erreicht werden, wenn erforderlich. Die HTTP Request Header, in welche Attributwerte platziert werden sollen. Mehrere Attribute können zu einem einzelnen Header abgebildet werden. Mehrere Werte werden, mit Semicolons getrennt, gemeinsam in einen einzelnen Header zusammengefasst. -Namensabkürzungen (engl. Alias), durch welche die Attribute in den Access Control Policy Regeln referenziert werden können, wie z.b. bei Apache, erfordern Befehle. SAML Attribute neigen dazu, Maschinen-freundliche Namen zu haben, somit erlauben also die Namensabkürzungen im Gegenzug, Administrator-freundlichere Namen stattdessen zu verwenden. Die Benennung der HTTP Header kann durch unterschiedliche Programmier- und Scriptsprachen erkannt und die Header darüber zugegriffen werden, wie es in Kapitel 6.6 Servervariablen bereits vorgestellt wurde. Der Alias wurde auch bereits vielerorts in Beispielen angewendet. Kapitel 6.5 Schutz der Pfade ist schon intensiv auf die Möglichkeiten eingegangen, durch Apache einen Pfad und damit die darin enthaltenden Dokumente zu schützen. An dieser Stelle wird jedoch nur auf die AAP eingegangen. Um das nachfolgende Beispiel zu verstehen, müssen zuerst einige Erkenntnisse gewonnen werden: AttributeRule enthalten entweder ein AnySite Element oder ëin oder mehrereßiterule Elemente, welche definieren mit welchen IdP s diese Regel angewendet wird. AnySite spezifiziert eine Regel, die immer für das Attribut gilt, unabhängig vom behauptenden IdP.

85 7.6 Service Provider anbinden 71 SiteRule beinhaltet einen Parameter name, der die Angabe providerid benötigt. Damit kann eine Regel gebildet werden, die nur für den IdP oder die Föderation mit der entsprechenden providerid gilt. AnyValue bezieht sich auf alle Attributwerte eines IdP und mit Value läßt sich nach Attributwerten filtern. Im folgenden Beispiel soll die hochschulinterne adresse mit allen evtl. vorhandenen Attributwerten von allen IdP s akzeptiert werden. Listing 7.10: Beispiel eines Attribute Rule der AAP 1 <A t t r i b u t e R u l e 2 Name=" u r n : m a c e : d i r : a t t r i b u t e d e f : m a i l " 3 Header=" Shib I n e t O r g P e r s o n m a i l " A l i a s=" m a i l "> 4 <A n y S i t e> 5 <AnyValue /> 6 </ A n y S i t e> 7 </ A t t r i b u t e R u l e> 7.6 Service Provider anbinden Eine gute Hilfestellung bietet hierzu auch die in Kapitel 7.4 vorgestellte Anpassung der Metadaten. Im Folgenden wird auf die Unterschiedlichen Service Provider Stellung genommen OLAT (Online Learning And Training) Dem Punkt Anbindung des OLAT Service Providers wird im nachfolgenden Kapitel 8 detailiert Beachtung geschenkt SMS-Infosystem Abbildung 7.2: Abgelehnte Autorisierung Der Dienst SMS-Infosystem wurde initial auf dem Service Provider eingerichtet. Die Konfiguration des SP sowie die Konfiguration des VirtualHost, in der Datei default.conf des Apache,

86 72 7 Single Sign-On an der HFU welche durch den später eingerichteten Dienst RZ-Daten ändern im folgenden Kapitel erläutert wird, sollen an dieser Stelle als Referenz ausreichen Dienst zum Ändern der RZ-Daten Der Dienst RZ-Daten ändern gibt mit seiner Bezeichnung bereits einen Hinweis darüber, zu was er entworfen wurde, und zwar um einem Benutzer zu erlauben, einen nicht sensiblen Teil seiner persönlichen Profildaten zu ändern. Beispielsweise, seine bevorzugte Sprache, sein Geschlecht (falls dieses im Rechenzentrum versehentlich falsch zugeordnet wurde), sowie das eigene Passwort am Rechenzentrum. Diese Möglichkeit für einen Benutzer kann damit, durch Eigenverwaltung, einen erheblichen Teil der Arbeit der Administratoren einsparen. Da dieser Dienst über den gleichen Service Provider wie das SMS-Infosystem angeboten wird, sind keine großen Änderungen mehr an der Shibboleth Konfiguration vorzunehmen. Einerseits eine komplett problemlose Änderung an der eingebundenen Konfigurationsdatei etc/apache2/conf.d/shib.conf des Apache, siehe Listing 7.7, um den mit Shibboleth zu schützenden Pfad einzutragen. Andererseits, gab es mit der Einrichtung des Virtual Host in der default.conf erhebliche Probleme, wobei der Server in der Zwischenzeit bereits für Testzwecke aus dem Verwaltungsnetz in einen weniger stark geschützten Bereich geholt wurde. Damit der Apache Webserver alle Anfragen über Port 443, d.h. über HTTPS, entgegennimmt, mußten einige spezielle Änderungen in der Konfiguration durchgeführt werden. Dabei ist bemerkenswert, dass nur "_default_"funktioniert und nicht der Fully Qualified Domain Name (FQDN), wenn man den VirtualHost angibt. Ein NameVirtualHost Eintrag war auch nicht notwendig. Listing 7.11: VirtualHost Konfiguration des Servers 1 <I f D e f i n e SSL> 2 <I f D e f i n e! NOSSL> 3 4 #NameVirtualHost s m s i n f o. hs f u r t w a n g e n. d e : # H i n t : a l s o put " D SSL" to t h e s e r v e r f l a g 7 # APACHE_SERVER_FLAGS a t : / e t c / s y s c o n f i g / apache2 8 # i f you use h t t p s i n u r l! 9 # I t i s n e c e s s a r y to use _ d e f a u l t _ i n s t e a d o f 10 # t h e fqdn h e r e : 11 <V i r t u a l H o s t _ d e f a u l t _ : 4 4 3> #ServerName sc p r o j e k t. f o o. fh f u r t w a n g e n. de 14 ServerName s m s i n f o. hs f u r t w a n g e n. de 15 DocumentRoot " / s r v /www/ h t d o c s " 16 SSLEngine On 17 S S L C e r t i f i c a t e K e y F i l e / e t c / apache2 / s s l. key / wild_hs f u r t w a n g e n. key 18 S S L C e r t i f i c a t e F i l e / e t c / apache2 / s s l. c r t / wild_hs furtwangen_de. c r t 19 S S L C A C e r t i f i c a t e F i l e / e t c / apache2 / s s l. c r t / wild_hs furtwangen_de. r o o t. c r t 20

87 7.6 Service Provider anbinden CustomLog / v a r / l o g / apache2 / s s l _ r e q u e s t _ l o g s s l _ c o m b i n e d </ V i r t u a l H o s t> </ I f D e f i n e> 26 </ I f D e f i n e> Für den Fall, dass der server wieder per HTTPS statt per HTTP und Portangabe erreichbar sein soll, muss ein Parameter mit dem Namen APACHE _SERVER _FLAGS= -D SSL in der Konfigurationsdatei /etc/sysconfig/apache2 gesetzt werden. Folgende Anpassungen wurden im Quellcode vorgenommen: ldapfields.xml für hfugender und preferredlanguage angepasst. slapd.conf des openldap angepasst: 1 # e n t e r e d f o r Webmin 2 a c c e s s to a t t r s=p r e f e r r e d L a n g u a g e, hfugender 3 by s e l f w r i t e 4 by r e a d Listing 7.12: openldap angepasst Sprache bereits im Login-Screen korrekt dargestellt. Anfangs Nutzung von anonymous ldap_ bind für um Attribute zu lesen. Erst bei Absenden der Änderungen mit Angabe des aktuellen Passworts wird ein nonanonymous bind durchgeführt. Unterbindung der Übergabe eines leeren, neuen Passworts an LDAP. Bugfix: Benutzername bleibt nach "Willkommenërhalten, wenn ein Fehler angezeigt wird. Möglichkeit für Logout hinzugefügt, dabei werden Cookies des Servers gelöscht. Bugfix in Funktion ldap_ modify von LDAPConnector.php damit LDAP-Fehler 21 Ïnvalid Syntax"nicht auftritt: unset($ data[ sambalmpassword ]); unset($ data[ sambantpassword ]); Sprachanpassungen in den language.*.xml Dateien. Anpassung der Ordnung der ldapfields.xml, da ehemals einzeilig dargestellt. config.php erzeugt und später erweitert.

88 74 7 Single Sign-On an der HFU Für den Fall, dass die Logdatei shibd.log des SP folgenden Fehler aufweist, muss damit gerechnet werden, dass entweder die Verbindung zum IdP unterbrochen ist, oder Firewall Einstellungen die Kommunikation blockieren: caught SAML exception during SAML attribute query: SOAPHTTPBindingProvider::send() failed while contacting SAML responder: connect() timed out! 7.7 Verantwortung durch SSO So wie für alle Passwörter gelten auch bei dem SSO-Passwort eines jeden Benutzers, sicher zu stellen, dass es komplex genug ist, nicht von jemandem erraten werden kann oder es aus Worten besteht, die im Wörterbuch zu finden sind. Es sollte dabei jedoch nicht so komplex sein, dass es irgendwo niedergeschrieben werden muss. Ein Passwort sollte möglichst mehr als 8 Zeichen haben, zusätzlich nicht nur am Rand verteilte Ziffern und Sonderzeichen beinhalten und Buchstaben in Groß- und Kleinschreibung aufweisen. Ein Guter Tipp ist, einen Spruch oder ein Sprichwort als Eselsbrücke zu verwenden, die Anfangsbuchstaben in der Groß- und Kleinschreibung zu verwenden, wie sie darin vorkommt, und zusätzlich stets Sonderzeichen und Ziffern an Stellen streuen, an denen man sich dies leicht merken kann. Diese Maßnahme ist bei Weitem nicht übertrieben, da bekannt ist, dass sogar an Hochschulen oft kurze oder sehr schwache Passwörter verwendet werden, beispielsweise die Matrikelnummer. Bei Single Sign-On hat ein Angreifer sonst direkt Zugriff auf eine Menge Daten seines Opfers und ein Schaden kann dabei recht groß ausfallen. Ein weiterer Punkt ist die Browsersitzung. Während einer Browsersitzung ist ein Benutzer per SSO authentifiziert und kann alle ihm angebotenen SSO-Dienste mit seiner Identität nutzen. Obwohl Hochschulen viel Geld für Computerarbeitsplätze investieren, kommt es dennoch besonders zu Beginn und gegen Ende des Semesters vor, dass sich erheblich viele Studenten über Kurse informieren, Skripte downloaden oder einfach nur für Prüfungen an den Computerarbeitsplätzen lernen wollen und diese dadurch knapp werden. Sei es nun aus dieser Knappheit heraus oder aus Zeitgründen, dass sich Studenten gemeinsam an einen Computerarbeitsplatz begeben, kann dies durch SSO zu Verwirrung oder Fehlern führen, wenn Arbeit im Browser durch die Studenten "nahezu parallel"durchgeführt wird. Bei SSO ist es notwendig einen evtl. vorhandenen Single Logout durchzuführen oder alternativ die Browsersitzung zu löschen (z.b. in Firefox per Tastenkombination Umschalttaste+Strg+Entf und dann Cookies und Verbindungen zu löschen) bzw. wenn der Browser korrekt eingestellt ist, alle Instanzen des Browsers einfach zu schließen. Der nächste Student kann dann

89 7.8 Zusammenfassung 75 getrost fortfahren. Es hat sich durch Testszenarien erwiesen, dass nach Absturtz des Rechners und der vom Browser angebotenen "Wiederherstellung der Sitzung"keine SSO Sitzung mehr besteht. Damit muss man nicht Sorge tragen und nach einem Neustart die Sitzungsdaten löschen, bevor man den Rechner verläßt. Ebenso unterliegt die SSO Sitzung einer Zeitbeschränkung (engl. Timeout), die jeder Service Provider in der Konfigurationsdatei shibboleth.xml festlegen kann. Standardwerte liegen dabei für lifetime bei zwei Stunden und für timeout bei einer Stunde. Der Parameter lifetime, gibt an, wie lange ein Service Provider eine Sitzung zu einem Benutzer hält und der Parameter timeout grenzt die Sitzung bei keiner Benutzeraktivität ein. 7.8 Zusammenfassung In diesem Kapitel wurde die Installation und Konfiguration eines Shibboleth Service Providers im Detail beschrieben, wie sie praktisch im Rahmen dieser Diplomarbeit für einen Webserver der Hochschule durchgeführt wurden. Anschließend wurde ein Einblick in die dazu notwendigen Metadaten verschafft. Für das Verständnis, was Attribute bei Shibboleth ausmachen und wie diese herangeschafft, geprüft, modifiziert und - über Policies gefiltert - erteilt werden, wurden Attribute ausführlich dargestellt. Als Hilfestellung für eigene Realisierungen, wurde die Anbindung von Service Providern geschildert - im Besonderen die des Service Providers mit dem Dienst RZ-Daten ändern. Abschließend wurde die Verantwortung aufgezeigt, die jeder zu tragen hat, der mit Single Sign-On in Berührung kommt, speziell mit Shibboleth.

90

91 8 OLAT an der HFU konkretisiert 8.1 Einleitung Das Das Learning Management System (LMS) OLAT (Online Learning And Training) soll an der Hochschule Furtwangen University (HFU) unter dem Namen Felix 2 zum Einsatz kommen. Damit löst OLAT die seit dem Sommersemester 2005 vorhandene Learning Management System Lösung Clix der imc information multimedia communication AG ab, die unter der Bezeichnug Felix derzeit noch parallel betrieben wird, solange für OLAT das Corporate Identity der Hochschule Furtwangen University über CSS 110 noch nicht komplett angepasst ist. Schließlich spielt, neben dem ersten Eindruck, eine optisch ansprechende Plattform für die Akzeptanz unter den Benutzern eine nicht unerhebliche Rolle, und evtl. kann durch das Corporate Identity ein Gefühl der Vertrautheit entstehen. Einige Vorteile von OLAT sind JDBC (Java Database Connectivity), es verwaltet Datenbankverbindungen und transformiert Daten in beide Richtungen zwischen der Form der SQL-Syntax und der für Java nutzbaren Form. Hibernate wird zur Persistierung der Business-Objekte (und wieder zurück) genutzt und befreit den Entwickler von der Erzeugung von SQL-Statements. Durch SCORM (Sharable Content Object Reference Model) können Web-basierende Lerninhalte (engl. E-Learning) per Import wiederverwendet werden. Des Weiteren können Benutzer über einen Listen-Import/Export (CSV oder XLS Dateien) zusätzlich bequem angelegt werden. 8.2 Installation Es wird eine Installationen und anschließende Konfigurationen des OLAT Service Providers beschrieben, die auf Ubuntu und SuSE Enterprise Linux durchgeführt wurden Apache Zuerst sollen nun einige sehr nützliche Befehle betrachtet werden. Nachsehen, ob Prozess httpd läuft: ps -ef grep httpd 110Cascading Style Sheets

92 78 8 OLAT an der HFU konkretisiert Nachsehen, welche Programme auf welchen Ports lauschen: sudo netstat -tupeln Site aktivieren (enabled): sudo a2ensite <virtualhostdateiname> Umgebugsvariable $JAVA_HOME prüfen: echo $JAVA_HOME Ist diese Variable nicht gesetzt bzw. leer, dann per export setzen: export JAVA_HOME=/usr/lib/jvm/java sun Tomcat Tomcat wird für OLAT als Service-Provider einer Shibboleth-Infrastruktur benötigt. Über die Paketverwaltung müssen folgende Pakete für Tomcat5.5 installiert werden: tomcat5.5 (universe, [2], seit Edgy Eft) tomcat5.5-admin (universe, seit Edgy Eft) tomcat5.5-webapps (universe, seit Edgy Eft) Nach der Installation muss der Pfad zum JDK in der Tomcat-Konfiguration in der Zeile JAVA_HOME=... angeben werden: vim /etc/default/tomcat5.5 Besonderheit bei Tomcat5.5!!! Die Log-Datei bei Tomcat5.5 scheint eine Pipe zu sein und bereitet Probleme, den Server zu starten. Daher löscht man die Datei und erstell sie als normale Datei mit den gleichen Eigenschaften (Rechte und Besitzer). cd /var/log/tomcat5.5/ sudo rm catalina.out sudo touch catalina.out sudo chown tomcat55:nogroup catalina.out sudo chmod uo-wrx catalina.out Danach sollte sich der Server starten lassen mit: sudo /etc/init.d/tomcat5.5 start Testen kann man Tomcat, wenn man die Demo-Webseite aufruft: Benutzer und Rollen definieren in Datei /usr/share/tomcat5.5/conf/tomcat-users.xml <role rolename= manager />

93 8.2 Installation 79 <role rolename= admin /> <user username= schwecht password= geheim roles= admin,manager /> <user username= saleyka password= secret roles= manager /> Damit diese Benutzer-/Rollen-Änderungen wirksam werden, Tomcat erneut starten: sudo /etc/init.d/tomcat5.5 restart OLAT Da bei Ubuntu Ant standardmäßig mitinstalliert wird, ist kein Path zu ANT_HOME nötig. MySQL 111 Dazu muss das Paket mysql-server in der Paketverwaltung installiert werden. Empfehlenswert sind noch die Pakete mysql-admin und mysql-query-browser. Manuell für MySql 5.x kann man die Datenbank mit dem MySQL Administrator Erstellen, indem man im Menu TOOLS > MySQL Text Console startet: mysql> create database olat; mysql> create user localhost identified by olat ; mysql> grant all on olat.* to localhost identified by olat ; mysql> flush privileges; Damit hat man nun eine Datenbank olat"mit Benutzer olat und Passwort olat Dies muss man sich merken. Dies wird später für die Datei build.properties benötigt! OLAT Archiv OLAT zip holen bei und auf Desktop ablegen. Dann auf dem Desktop entpacken und nach Verzeichnis /opt verschieben: sudo mv OLAT /opt Nun kommt die OLAT-Konfiguration! In das OLAT Verzeichnis wechseln, dann Datei kopieren: cp build.properties.default build.properties Nun die Template-Kopie editieren: sudo gedit build.properties 111Vgl. Stand:

94 80 8 OLAT an der HFU konkretisiert Hier werden einige Änderungen vorgenommen: base.dir=/opt/olat userdata.dir=/home/user/eclipse-workspace/olatdata tomcat.home=/usr/share/tomcat5.5/ (=CATALINA_HOME) server.domainname=shibboleth-sp.dyndns.org server.port=8180 defaultlang=de registration.notification =shibboleth@online.de smtp.host=smtp.1und1.de db.pass=olat Da nun da das wichtigste in der build.properties (abgesehen von Shibboleth-Einstellungen) konfiguriert ist, kann man mit Ant die build.xml automatisiert deployen: sudo ant config-all Kopie der server.xml von Tomcat anlegen (als Backup): cp var/lib/tomcat5.5/conf/server.xml var/lib/tomcat5.5/conf/server.xml _ original Die server.xml des Tomcat Verzeichnis nun überschreiben mit der von OLAT/conf/ : sudo cp opt/olat/conf/server.xml var/lib/tomcat5.5/conf/server.xml Da Tomcat bereits in /endorsed xercesimpl.jar und xml.apis.jar enthält, nur noch xalan.jar kopieren: sudo cp /opt/olat/webapp/web-inf/lib/xalan jar /usr/share/tomcat5.5/common/endorsed/xalan jar JRE enthält noch kein Verzeichnis /endorsed somit muss es zuerst erzeugt werden, dann die 3 JAR s hineinkopieren: sudo mkdir /usr/lib/jvm/java sun/jre/endorsed sudo cp /opt/olat/webapp/web-inf/lib/xalan jar xercesimpl2.7.1.jar xml-apis.jar /usr/lib/jvm/java sun/jre/endorsed/ OLAT mit Ant compilieren: sudo ant build Automatisches Setup der Datenbank-Tabellen mit Ant: sudo ant dbsetup

95 8.2 Installation 81 Da es mit dem /olatdata/logs Verzeichnis im /home/eclipse-workspace Verzeichnis abgelegt werden sollte, muss der Schreibzugruff korrigiert werden: sudo chmod 777 -R /home/user/eclipse-workspace/olatdata/ Sowie das OLAT Verzeichnis bezüglich Schreib-Zugriff korrigieren, da die OLAT installation Zugriff durch den User tomcat55 benötigt: sudo chown -R tomcat55:adm /opt/olat sudo chown -R tomcat55:adm /home/user/eclipse-workspace/olatdata/ Nun kann OLAT gestartet bzw. erreicht werden. Als erstes sollte mit user administrator und passwort olat eingeloggt werden und das Passwort unter HOME > Einstellungen > Passwort ändern. Es gibt standardmäßig noch einen Gastaccount gast mit Passwort gast, der minimale Rechte besitzt Konfiguration von Apache und Tomcat Apache: Anzumerken ist, dass Apache bei SuSE über httpd.conf und bei Ubuntu über apache2.conf zu konfigurieren ist. Als sehr nützlich hat sich die Webseite von Apache 112 für die Konfiguration der Virtual- Hosts. Tomcat Mod_JK Connector installieren Durch die Einrichtung eines Mod_JK kann Apache über einen Worker die Anfragen für JSP-Seiten an Tomcat zur Verarbeitung weiterleiten: über den Paketmanager folgendes Paket holen: libapache2-mod-jk im Verzeichnis /etc/apache2/mods-available muss die Datei jk.load existieren folgendes muss darin steht: LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so im Verzeichnis /etc/libapache2-mod-jk/ in die Datei worker.properties folgendes ändern: workers.tomcat_home=/usr/share/tomcat5.5/ workers.java_home=/usr/lib/jvm/java sun die httpd.conf aus OLAT nach apache2 kopieren: sudo cp /opt/olat/conf/httpd.conf /etc/apache2/vhost _ olat.conf 112Vgl. Stand:

96 82 8 OLAT an der HFU konkretisiert diese vhost_olat.conf zum Editieren aufrufen: sudo gedit /etc/apache2/vhost_olat.conf in der vhost_olat.conf nun abändern: alle Vorkommen von worker1 durch ajp13_worker ersetzen! alle Vorkommen von /opt/olat/conf/workers.properties durch /etc/libapache2- mod-jk/workers.properties ersetzen! in die apache2.conf folgendes am Ende einfügen: Include /etc/apache2/vhost_olat.conf WICHTIG: nun in der server.xml die Kommentare entfernen nach <! Define an AJP 1.3 Connector on port 8009 > damit der Tomcat Connector auf Port 8009 initialisiert wird und der Mod_JK- Connector zu Port 8009 Verbindung aufnehmen kann: sudo gedit /var/lib/tomcat5.5/conf/server.xml Restarten des Apache sowie des Tomcat: sudo /etc/init.d/apache2 restart sudo /etc/init.d/tomcat5.5 stop sudo /etc/init.d/tomcat5.5 start Testen kann man dies im Browser unter: ( nicht zu funktionieren!) bei Problemen mit dem Mod_JK die OLAT-Mod_JK-Logfile ansehn: gedit /home/schwecht/eclipse-workspace/olatdata/logs/mod_jk.log Sollte das nun funktioniert haben, ist es ratsam den Default http Connector von Tomcat auf Port 8080 bzw zu deaktivieren, dazu den entsprechenden Eintrag in der server.xml auskommentieren: sudo gedit /usr/share/tomcat5.5/conf/server.xml 8.3 OLAT mit Eclipse entwickeln Eclipse installieren Die offizielle Anleitung zum Integrieren von OLAT in Eclipse: erweitern, um OLAT effizient bearbeiten zu können wenn nötig

97 8.3 OLAT mit Eclipse entwickeln 83 ==> wichtig ist im Update Manager von Eclipse folgende URL als Remote Site einzutragen und dann darüber die Web Tools Platform (WTP) zu installieren: Eclipse auf dem Desktop entpacken und dann nach /opt installieren: sudo mv /home/user/desktop/eclipse/ /opt/ Schnellstart konfigurieren, indem man eine Datei /usr/bin/eclipse mit folgendem Inhalt erzeugt: Text!/bin/bash export MOZILLA_FIVE_HOME= /usr/lib/mozilla-firefox/ export ECLIPSE_HOME= /opt/eclipse /opt/eclipse/eclipse -vm /usr/lib/jvm/java sun/bin/java diese Datei nun für alle User ausführbar machen (=Ausführrechte geben): sudo chmod a+x /usr/bin/eclipse 64Bit-Version von Eclipse herunterladen (wenn nötig). auf Desktop entpacken und über das 32Bit-Eclipse kopieren: sudo cp -a /Desktop/eclipse/ /opt/ Nun kann man probieren Eclipse zu starten. Für den Fall, dass es Fehler gibt, sollte Eclipse beim ersten Start ein eclipse -clean im Terminal durchführen. nach Anleitung auf olat.org vorgehen und CVS Repository einbinden in Eclipse servlet-api.jar aus common/lib/ des Tomcat als External JAR einbinden in BuildPath des OLAT-Projekts des Eclipse im Eclipse Workspace einen Ordner dev-olatdata erstellen build.properties des bereits installierten OLAT zur OLAT-Developement-Installation kopiert und folgende Stellen angepaßt: base.dir=/home/schwecht/eclipse-workspace/olat3 userdata.dir=/home/schwecht/eclipse-workspace/dev-olatdata instance.id=mydevolat server.domainname=dev-shib-olat.dyndns.org server.contextpath=/olat-dev db.name=devolat db.user=devolat db.pass=devolat

98 84 8 OLAT an der HFU konkretisiert db.test.name=testdevdb db.test.user=devolat db.test.pass=devolat instantmessaging.db.name=devwildfire instantmessaging.db.user=devwildfire instantmessaging.db.pass=devwildfire shibboleth.providerid= mrtg.loginname=devolat build.host=dev-shib-olat.dyndns.org Manuell für MySql 5.x kann man die Datenbank mit dem MySQL Administrator erstellen, indem man im Menu TOOLS > MySQL Text Console startet: mysql> create database devolat; mysql> create user localhost identified by devolat ; mysql> grant all on devolat.* to localhost identified by devolat ; mysql> flush privileges; Da nun da das wichtigste in der build.properties (abgesehen von Shibboleth-Einstellungen) konfiguriert ist, kann man mit Ant die build.xml automatisiert deployen: Rechte Maus in Eclipse auf die build.xml > Run As... > Ant Build... > Tab Target wählen > Haken bei Sort targets und bei Hide internal targets not selected for execution setzen > Haken in der Liste bei config-all und dbsetup setzen > Run drücken. Damit an das richtige OLAT weitergeleitet wird, in der server.xml im /conf von Tomcat folgendes abgeändert: <! developing > <Context path= /olat-dev docbase= /home/schwecht/eclipse-workspace/olat3/webapp debug= 0 reloadable= false /> Eclipse im Betrieb Speichern in Eclipse nur möglich wenn vorher/währendessen Rechte des olat3-verzeichnisses angepaßt werden: sudo chown -R schwecht:schwecht /home/schwecht/eclipse-workspace/olat3 Tomcat kann nur olat3 (Development-Installation) ausführen wenn die Rechte für Tomcat stimmen: sudo chown -R tomcat55:adm /home/schwecht/eclipse-workspace/olat3

99 8.3 OLAT mit Eclipse entwickeln 85 Damit es mit dem /dev-olatdata/logs Verzeichnis im /home/eclipse-workspace Verzeichnis keine Schreibzugriff-Probleme gibt, muss dies korrigiert werden: sudo chmod 777 -R /home/schwecht/eclipse-workspace/dev-olatdata/ Auf dem IdP die hfu-metadata.xml angepaßt (Kopie von shibboleth-sp.dyndns.org mit Änderungen zu diesem Development-OLAT) Die hfu-metadata.xml in /eclipse-workspace/olat3/webapp/web-inf/ kopiert Rechte der hfu-metadata.xml angepaßt: sudo chown -R schwecht:schwecht./hfu-metadata.xml Anpassen der /etc/apache2/vhost o lat.confbeif elix2 Wenn man eine Extension in Eclipse mit Export... > Java > Jar File durchgeführt hat und diese nach./olat/webapp/web-inf/lib/ kopiert hat, müssen für die jar-datei noch die Rechte angepaßt werden: sudo chmod a+r,u-x facultyservices.jar die bewirkt -rw-r r Rechte, d.h. alle dürfen lesen und Eigentümer darf schreiben Und natürlich die Benutzer- und Gruppen-Inhaber anpassen: (chown -R catalina:users facultyservices.jar) sudo chown -R tomcat55:adm facultyservices.jar Fall Felix2: Seeeeehr wichtig in das apache-tomcat/bin Verzeichnis zu wechseln und dort das Startskript mit voller Pfadangabe per stop/start auszuführen cd /opt/catalina/apache-tomcat /bin /opt/catalina/apache-tomcat /bin/catalina.sh stop /opt/catalina/apache-tomcat /bin/catalina.sh start Anmerkung zu Imports Sollten Imports von javax.servlet.* Fehler anzeigen, folgendes durchführen: Rechtsklick auf das CVS-Projekt von OLAT > Build Path... > Add External Archives... > /usr/share/tomcat5.5/common/lib/servlet-api.jar auswählen > mit OK bestätigen

100 86 8 OLAT an der HFU konkretisiert 8.4 Extension-Konzept von OLAT "Verschiedene so genannte Extension-Points erlauben, das LMS nach kundenspezifischen Bedürfnissen zu erweitern, ohne dabei Änderungen am Grundsystem vornehmen zu müssen." 113 Abbildung 8.1: Erweiterbarkeit von OLAT durch eine Extension Controller Kann weitere Controller aufrufen Erstellt initial Components beim Aufbau Ist für Menüs und die Events verantwortlich Weist den Manager an seine Aufgabe zu erledigen Bietet der View Objekte zum rendern View Nutzt Velocity Engine (Template-Sprache) HTML-Body ist Ansatz (kein html,- head- oder body-tag) Nutzung von translate() Methode für versch. Sprachen (i18n) Manager Verantwortlich für Persistenz-Funktionalitäten (fs oder DB) Trennt Workflow von Perstistierung Bildet die Geschäftslogik ab 113Vgl. Gnägi/Roth/Fisler ( ), OLAT 5 - Funktionsübersicht, v3.0 S.20.

101 8.5 Automatische Benutzer-Registrierung Automatische Benutzer-Registrierung Orginaler Registrierungsvorgang When a user first successfully authenticates herself via Shibboleth, she must register with OLAT. The user is asked for a username which identifies the user within OLAT. A user profile is generated and the address provided by the Identity Provider s Attribute Authority is automatically added to the profile. This implies that an Identity Provider s Attribute Authority must at least provide an address attribute. Furthermore, a unique identifier is needed which is configurable per site in the olat_config.xml. After accepting the disclaimer, the user is forwarded to the home screen and registration is completed. 114 Überlegungen zu der Automatischen Registrierung Die negativen Auswirkungen eines frei gewählten Benutzernamens sollten eigentlich jedem bekannt sein. Obwohl OLAT über einen konfigurierbaren Filter für anstößige Ausdrücke verfügt, wird man nie alle abdecken können. Der Hauptgrund für die Überlegung, eine freie Wahl zu verhinern, liegt jedoch darin, jeden Benutzer stets im System erkennen zu können, da neben Kursen und zu beweltigende Aufgaben auch ein Forum existiert. Der Anstand wird einfacher bewahrt, wenn man nicht anonym agiert. Schließlich könnte sich jemand als Professor ausgeben und u.u. Schaden anrichten. Teil der Überlegungen war, ob genau festgelegt werden kann, wann Benutzer aus dem LDAP Verzeichnis gelöscht werden. Dabei geht es um den vom Rechenzentrum ausgestellten Benutzernamen. Kollisionen von gleichnamigen Studenten scheinen glimpflich zu verlaufen, da im Rechenzentrum die Vergabe der Benutzernamen nicht vollautomatisch erfolgt. Daraufhin wurden alle möglichen Zeichen für den OLAT-Usernamen im Quellcode geprüft. Möglich sind alle zwischen a bis z, 0 bis 9, dem Punkt, Bindestrich und dem Unterstrich ([az][0-9][.-_]). Eine weitere Einschränkung betrifft Jabber, dem integrierbaren Chatclienten, der zwischen 3 und 32 Zeichen lang sein darf. Eine Kombination aus Rechenzentrumsbenutzername, einer Zuordnung zur Hochschule und einem Datum der erstmaligen OLAT Registrierung wurde ebenso ins Auge gefasst. Dieser Ansatz muss jedoch verworfen werden, da bestimmte Teile der Lernplattform sehr schmale Bereiche haben, in denen der Benutzername angezeigt werden muss. 114Vgl. OLAT Developer Documentation, Stand:

102 88 8 OLAT an der HFU konkretisiert Mechanismus der Automatischen Registrierung Mit der Automatischen Registrierung wird dem Benutzer nun die Möglichkeit genommen, sich frei einen Benutzernamen auszudenken, um sich damit zu registrieren. Der Benutzer erhält vom Rechenzentrum nach seiner Immatrikulierung einen Hochschul- Benutzernamen. Dies ist derjenige, mit dem er sich auch per Shibboleth gegenüber dem Identity Provider authentifiziert. Dieser Hochschul-Benutzernamen wird mit einer Zeichenkette.hfu in einer AttributeDefinition der resolver.xml beim IdP verbunden. Der IdP stellt dadurch ein Attribut für alle Service Provider zu Verfügung. Es nennt sich OLATusername und hat beispielsweise schwecht.hfu als Wert. Die Abbildung 8.2 zeigt, wie bei der Implementierung die Klasse DMZController einen Auruf der hier beschriebenen, implementierten Klasse ShibbolethAutoRegistrationController durchführt, anstatt den Controller für die originale Registrierung aufzurufen. Abbildung 8.2: Aufruf des ShibbolethAutoRegistrationController Anschließend werden die von Shibboleth - auf eine Attribute Query - übermittelten Attribute des Benutzers gelesen, um die Registrierung in der OLAT Datenbank vorzunehmen, wie Abbildung 8.3 demonstriert. Die Abbildung 8.4 zeigt, wie mit diesem Attribut als Benutzername der Benutzer bei OLAT registriert wird.