Einsatz von Single-Sign-On Technologien im Rahmen der Integration von E-Learning Anwendungen

Größe: px
Ab Seite anzeigen:

Download "Einsatz von Single-Sign-On Technologien im Rahmen der Integration von E-Learning Anwendungen"

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Einsatz von Single-Sign-On Technologien im Rahmen der Integration von E-Learning Anwendungen Für das Hauptseminar E-Learning Christian Nockemann Toppheideweg 10, Münster Mat.Nr: Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Christian Arndt Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung Single Sign-On Einführung Vor- und Nachteile SSO-Anbieter Shibboleth Kerberos OpenID Evaluation der einzelnen SSO-Anbieter SSO im E-Learning-Kontext Vorteilhaftigkeit von SSO im E-Learning Kontext SSO an der Westfälischen Wilhelms-Universität SSO-Landschaft Kopplung mit dem zentralen Identitätsmanagement der Hochschulverwaltung Praktische Anwendung Implementierung Einsatz und Wartung Fazit und Ausblick Literaturverzeichnis II

3 1 Einleitung Heutzutage sehen sich viele Internet-Benutzer mit einer unüberschaubaren Anzahl von Web-Ressourcen konfrontiert. Die meisten davon haben aus Sicherheitsgründen geschützte Bereiche, auf die nur zugegriffen werden kann, wenn sich der Benutzer zuvor authentifiziert. Demzufolge müssen die meisten Benutzer in der Summe eine sehr große Anzahl von Anmeldedaten (bestehend aus Nutzerkennung und Passwort) verwalten. Diese Entwicklung führt einerseits zu verminderter Benutzerfreundlichkeit, da die Benutzer viel Zeit mit fehlgeschlagenen Login-Versuchen und dem Wiederfinden von Passwörtern verbringen. Andererseits kann es aber auch zu ernsthaften Sicherheitsproblemen kommen. Beispielsweise hinterlegen viele Benutzer ihre Anmeldedaten als Gedächtnisstütze in elektronischer Form auf ihrem Rechner, was von der sicherheitstechnischen Relevanz in etwa mit der Aufbewahrung der Bankkarte und der zugehörigen PIN im gleichen Portemonnaie vergleichbar ist. Des Weiteren werden sehr oft die gleichen Anmeldedaten für verschiedene Web-Ressourcen benutzt, womit ein nicht vertrauenswürdiger Service Anbieter, unter Verwendung dieser Anmeldedaten, weit reichenden Zugriff auf sensible Daten hätte. Auch aus der Sicht von Software-Entwicklern und Administratoren gibt es hier Besserungsbedarf. Die Verwaltung von Benutzerdatenbanken, die Entwicklung von sicheren Anmeldeverfahren sowie das Zurücksetzen von verlorenen Benutzer- Passwörtern sind kosten- und zeitaufwändig. Innerhalb eines Unternehmens oder einer Universität kann es darüber hinaus auch schnell zu inkonsistenten Daten kommen, wenn jede vorhandene Anwendung eine eigene Benutzerdatenbank verwaltet, da bei einer Änderung der Benutzerdaten alle einzelnen Datenbanken aktualisiert werden müssen. Um einen Lösungsansatz für diese Probleme zu finden, ist es nötig, sich über eine Alternative zum klassischen Modell der Authentifizierung (-> jeder Service Anbieter verlangt eine separate Authentifizierung) Gedanken zu machen. Ein weit verbreiteter Ansatz zur Lösung dieser Probleme ist das so genannte Single Sign-On. Das Ziel dieser Ausarbeitung ist es, einen Überblick über die Grundlagen und Konzepte von Single Sign-On zu geben, sowie eine Auswahl von Single Sign-On Anbietern, respektive ihre Software vorzustellen. Dabei wird ein besonderes Augenmerk auf die Single Sign-Ongestützte Integration von E-Learning Anwendungen gelegt. 3

4 2 Single Sign-On 2.1 Einführung Single Sign-On (SSO) ist ein Mechanismus, welcher es dem Benutzer erlaubt, sich mit einer einzigen Anmeldung bei mehreren Service-Anbietern zu authentifizieren. Dabei meldet sich der Benutzer bei einer zentralen, vertrauenswürdigen Authentifizierungs- Autorität (AA) an, die daraufhin für die Authentifizierung des Benutzers bei allen Service-Anbietern (SA) sorgt, die mit dieser AA zusammenarbeiten und bei denen der Benutzer Zugriffsrechte besitzt. Danach erhält der Benutzer Einsicht in die geschützten Inhalte dieser SAs. Man kann dabei client- und serverbasierte SSO-Varianten unterscheiden [Koc07]. Erstere findet meist Anwendung innerhalb von Unternehmen und gewährleistet eine einheitliche Anmeldung bei mehreren auf einem Rechner installierten Programmen. Die zweite Variante kommt zur Anwendung, wenn auf mehrere verteilte Internet- Ressourcen mit einer einzigen Anmeldung zugegriffen werden soll. Da sich diese Ausarbeitung auf den Bereich des E-Learnings konzentriert und es sich dabei um Web- Anwendungen handelt, ist im Folgenden immer das server-basierte gemeint, wenn von SSO die Rede ist. Des Weiteren lassen sich SSO-Techniken nach der Art der Weiterleitung der Benutzerdaten differenzieren: direkt, token-basiert, sofort und temporär [Ope01]. Bei der direkten Weiterleitung werden die Daten des Benutzers, nachdem er sich bei der AA angemeldet hat, von dieser unverändert an die SAs weitergegeben und dort zur Authentifizierung benutzt. Im Falle der token-basierten Weiterleitung gibt die AA nach der Anmeldung nicht die Benutzerdaten weiter, sondern sendet nur ein Token an den Benutzer. Dieses Token ist eine Art Schlüssel, welchen der Benutzer verwenden kann, um Zugriff auf die geschützten Inhalte eines SA zu erhalten, ohne seine Anmeldedaten weitergeben zu müssen. Der SA kann sicher sein, dass ein Benutzer, der ein Token besitzt auch die entsprechenden Zugriffsrechte hat, ohne dass er Einsicht in die Anmeldedaten des Benutzers erhält. 4

5 Bei der sofortigen Anmeldung fungiert die AA als eine Art Anmelde-Proxy für den Zugriff auf die einzelnen SAs. Das heißt, nachdem ein Benutzer sich bei der AA authentifiziert hat, erlangt er direkten Zugang zu den geschützten Ressourcen der SAs, ohne dass Letztere noch irgendwelche Informationen (seien es nun Anmeldedaten oder ein Token) benötigen. Bei der temporären Weiterleitung werden die Benutzerdaten nur eine gewisse Zeit lang bei der AA zwischengespeichert und können so lange für die Anmeldung bei den verschiedenen SA benutzt werden. Wichtig bei dieser Unterscheidung ist, dass diese Kategorien nicht disjunkt sind und dass sich nicht jede SSO-Software eindeutig in eine dieser Kategorien einordnen lässt. Die meisten führenden SSO-Anbieter (z.b. Shibboleth und Kerberos) benutzen allerdings die token-basierte Weiterleitung, teilweise in Kombination mit einer temporären Zwischenspeicherung der Benutzerdaten. Aus diesem Grunde wird im Folgenden detaillierter auf diese Art der Weiterleitung eingegangen. In Anlehnung an [Dec02] Abb.1: Token-basierte Single Sign-On Anmeldung Abb. 1 zeigt den schematischen Aufbau eines token-basierten SSO-Anmeldevorgangs. Dabei wird der grundsätzliche Anmelde-Prozess dargestellt, der tatsächliche Ablauf kann allerdings je nach SSO-Software in den Details davon abweichen (dazu mehr im Abschnitt 2.3). Zunächst meldet sich der Benutzer unter der Verwendung seiner 5

6 Anmeldedaten (1) bei der AA an, woraufhin diese überprüft, ob der Benutzer in der Benutzer-Datenbank vorhanden ist und authentifiziert werden kann (2). Im Falle einer erfolgreichen Authentifizierung sendet die AA ein Token an den Agenten des Benutzers (im Normalfall also an den Browser) zurück (3), welches dieser nun zur Anmeldung bei den einzelnen SAs benutzen kann, die mit der AA zusammenarbeiten (4) [Dec02]. Hierbei ist zu beachten, dass der Agent des Benutzers die Anmeldung und Weiterleitung des Tokens übernimmt, so dass der Benutzer nur für die Anmeldung bei der AA in Aktion treten muss. Die Schritte (2) bis (4) sind demnach transparent für den Benutzer. Wie in Abb1. zu sehen ist, müssen die Service-Anbieter der Authentifizierungs- Autorität vertrauen, dass wirklich nur berechtigte Benutzer Zugriff auf die gesicherten Inhalte erhalten. Auch müssen die Benutzer sicher sein können, dass Ihre Anmeldedaten von der AA nicht missbraucht werden. Darüberhinaus muss gewährleistet werden, dass die Anmeldedaten im Zuge der Übermittlung nicht ausspioniert werden können [Ope01]. Dies ist mit geeigneten Kryptographie-Methoden wie z.b. dem Diffie- Hellman-Schlüsselaustausch [Res99] oder dem RSA-Kryptosystem [Sch02] zu gewährleisten. Nachdem ein Benutzer erfolgreich authentifiziert wurde, muss im nächsten Schritt überprüft werden, über welche Zugriffsrechte er verfügt. Dies geschieht im Rahmen der Autorisierung, welche der Zuweisung [ ] von Zugriffsrechten auf Daten und Dienste an Systemnutzer [Jan04] dient. Im Zuge der Autorisierung wird also überprüft, auf welche Ressourcen ein authentifizierter Benutzer zugreifen darf. Dies geschieht häufig in Form einer Rollenzuweisung. Typische Rollen in E-Learning Anwendungen sind beispielsweise Administrator, Dozent/Korrektor und Student. Wie eine SSO- Anwendung mit der Autorisierung der Benutzer umgeht, ist sehr unterschiedlich. In Abschnitt 2.3 werden drei SSO-Anwendungen vorgestellt, unter anderem wird dort auch darauf eingegangen, wie die Autorisierung der Benutzer vonstatten geht. Es sei auch noch erwähnt, dass einige SSO-Anbieter einen so genannten Single-Sign- Out-Mechanismus unterstützen, der gewährleistet, dass ein Benutzer, der sich bei allen SAs gleichzeitig abmelden möchte, dies auch tun kann. Das macht insbesondere im E- Learning-Kontext Sinn, da bei Benutzung öffentlicher Rechner (z.b. an der Universität) ohne solch einen Mechanismus ein nachfolgender Benutzer Zugriff hätte auf alle SAs, für die sich der vorherige Benutzer per SSO angemeldet hat. Diese Problematik wird in Abschnitt 3.2 genauer erörtert. 6

7 2.2 Vor- und Nachteile Zunächst einmal bleibt festzuhalten, dass einige der in der Einleitung genannten Sicherheitsprobleme wie das Weitergeben von Anmeldedaten an nichtvertrauenswürdige Service-Anbieter mithilfe von SSO gelindert werden können. Andererseits zeigen alle derzeit auf dem Markt verfügbaren SSO-Softwarepakete auch Schwächen in Bezug auf Komfort und Sicherheit. Im Folgenden werden daher die Vorteile und Nachteile von SSO gegenübergestellt. Zu den wichtigsten Vorteilen zählen folgende Punkte: Einheitlicher Zugriff auf Webinhalte mit Hilfe eines einheitlichen Authentifizierungsvorgangs Erhöhung der Benutzerfreundlichkeit Erhöhung der Sicherheit, da die Anmeldedaten nur an eine einzige Authentifizierungs-Stelle weitergegeben werden müssen Es ist nur noch eine Benutzerdatenbank nötig, was den Kosten- und Zeitaufwand für die Benutzerverwaltung reduziert Ebenfalls wird die Datenhaltung dadurch konsistenter, da Änderungen an den Benutzerdaten nicht mehr in mehreren Datenbanken vorgenommen werden müssen Anpassungen am Anmeldeverfahren (z.b. nach einer Änderung des Datenschutzrechts) müssen nur ein mal gemacht werden und nicht bei jedem einzelnen SA Demgegenüber stehen folgende Nachteile [Rum06]: Falls die Zugangsdaten bei der Übertragung zur AA ausgespäht werden, hat der Angreifer Zugriff auf alle SAs, für die der Benutzer über die AA authentifiziert wird Die AA stellt einen Single-Point-Of-Failure dar, denn wenn der Authentifizierungsmechanismus versagt, wird dem Benutzer der Zugriff auf alle teilnehmenden SAs verweigert 7

8 Diese beiden Punkte könnte man allerdings teilweise umgehen. Der Single-Point-Of- Failure ließe sich beheben, indem jeder Service-Anbieter neben der SSO-Anmeldung noch eine alternative, klassische Anmeldung zur Verfügung stellt. Allerdings müsste dann doch wieder pro SA eine eigene Benutzerdatenbank verwaltet werden. Darüberhinaus muss die Authentifizierungs-Autorität gewährleisten, dass die Übertragung der Anmeldedaten des Benutzers so sicher wie möglich ist, zum Beispiel indem Tokens mit einer Gültigkeit versehen werden, damit sie nicht missbraucht werden können, falls es einem Angreifer gelingt ein Token abzufangen [Rum06]. Oder es wird mit geeigneten Kryptographie-Verfahren (siehe Abschnitt 2.1) verhindert, dass ein Angreifer überhaupt die Möglichkeit bekommt, ein Token abzufangen. Grundvoraussetzung dafür, dass der Einsatz von SSO überhaupt Sinn macht, ist, dass es mehr als einen SA gibt, der an der SSO-Infrastruktur teilnimmt. Normalerweise ist diese Voraussetzung aber an Universitäten und in Unternehmen erfüllt. Abschließend lässt sich sagen, dass die Vorteile in den meisten Fällen die Nachteile überwiegen. Um allerdings endgültig die Vorteilhaftigkeit von SSO beurteilen zu können, sollte zunächst eine Übersicht über die wichtigsten SSO-Anbieter verschafft werden, gefolgt von einer Evaluation. 2.3 SSO-Anbieter Shibboleth Shibboleth ist ein Projekt der Internet2-Middleware Initiative mit dem Ziel, eine Open- Source Software zur Verfügung zu stellen, welche den Zugriff auf Web-Ressourcen vereinheitlicht [Shi07]. Es wurde an der Pennsylvania State University (hauptsächlich für den universitären Kontext) entwickelt. Es basiert auf der Security Assertion Markup Language (SAML) welche ein XML-basiertes Framework zur technischen Realisierung von Authentifizierungs-und Berechtigungsverfahren ist [OAS07]. Im Zentrum der Shibboleth-Architektur steht der Austausch von SAML-Aussagen mithilfe des SOAP-Netzwerkprotokolls [W3C07]. Diese Aussagen beinhalten allgemeine Informationen über den Benutzer (wie z.b. ob die Authentifizierung erfolgreich war oder welche speziellen Zugriffsrechte der Benutzer hat) sowie über die Attribute die der Benutzer besitzt [CDS05]. Eine SAML-Aussage welches ein Attribut eines Benutzers weiterleitet hätte z.b. die Form <samlp:attributestatement> einattribut</samlp:attributestatement>. Im Kontext von Shibboleth 8

9 werden Attribute als Eigenschaften des Benutzers verstanden, die mit beliebigem Inhalt, wie z.b. Zugriffsrechten oder Wohnort, gefüllt werden und somit dem SA zur Verfügung gestellt werden können. Damit lässt sich mit ihnen auch die Benutzer- Autorisierung (siehe Abschnitt 2.1) realisieren, indem bei der Anmeldung ein Attribut weitergeleitet wird, welches die Rollenbezeichnung beinhaltet (z.b. Admin oder Student ). Ob und welche Attribute weitergeleitet werden, entscheidet die AA. Da nur Aussagen und keine konkreten Benutzerdaten ausgetauscht werden, kann man hier von einem token-basierten SSO-Mechanismus sprechen, wobei ein so genannter Sicherheitskontext ein Token repräsentiert. Ein Sicherheitskontext ist ein SAML- Konstrukt, welches dem SA garantiert, dass der Benutzer derjenige ist, für den er sich ausgibt, und dementsprechende Zugriffsrechte besitzt. Anders als bei vielen anderen SSO-Anbietern wird bei Shibboleth die Authentifizierungsanfrage nicht zunächst an die AA, sondern direkt an den SA gestellt (und von dort aus an die AA weitergeleitet). D.h. der Benutzer braucht gar nicht wissen, wer die Zuständige AA ist, sondern geht schlicht auf die Homepage des SA, wird von dort auf ein Anmeldeformular der AA und nach erfolgter Anmeldung direkt zur geschützten Ressource weitergeleitet. Grundlegend sind an einem Authentifizierungsvorgang unter Verwendung von Shibboleth drei verschiedene Parteien beteiligt [Can05]. Der Identity-Provider (IdP, übernimmt ähnliche Aufgaben wie die AA), der Service-Provider (SP, ähnlich wie der SA) und der Benutzer (bzw. sein Agent). Darüber hinaus gibt es noch den so genannten Where Are You From? -Service (WAYF), der bei Bedarf den IdP eines bestimmten Benutzers ermitteln kann. Der IdP ist dafür verantwortlich, Aussagen über die Authentifizierung und die Attribute eines Benutzers zu treffen und weiterzuleiten. Der SP stellt Web-Ressourcen zur Verfügung. Der (optionale) WAYF-Service bietet dem SP die Möglichkeit, einen validen IdP für einen Benutzer zu ermitteln. In Abb. 2 ist der schematische Aufbau eines SSO-Vorgangs mit Hilfe von Shibboleth dargestellt. 9

10 In Anlehnung an [CDS05] Abb. 2: Schematischer Aufbau einer Anmeldung mit Shibboleth Wie man sehen kann, sind der SP und der IdP in weitere Komponenten unterteilt. Der SP beinhaltet neben den geschützten Ressourcen auch den sog. Assertion Consumer Service, welcher dafür zuständig ist, einen Sicherheitskontext für den Benutzer zu erstellen, falls letzterer zuvor erfolgreich authentifiziert wurde. Der IdP besteht im Wesentlichen aus dem SSO-Service, welcher für die Authentifizierung des Benutzers verantwortlich ist, sowie der Authentication Authority, welche überprüft, ob ein Benutzer in der Datenbank vorhanden ist und authentifiziert werden kann. Der genaue Ablauf wird im Folgenden schrittweise erklärt. SP und IdP haben auch noch weitere Komponenten, deren Funktionen jedoch für den Überblick, der hier gegeben werden soll, nicht von Belang sind. Bei Interesse sei [CDS05] als weiterführende Lektüre empfohlen. Wenn der Benutzer auf eine Ressource des SP zugreifen möchte (1) (der Benutzer braucht, wie bereits erwähnt, im Unterschied zu den meisten anderen SSO- Anwendungen, nicht zuerst auf den IdP zugreifen), wird er von letzterem an den SSO- Service des IdP (wenn der IdP des Benutzers nicht bekannt ist, kommt hier der oben genannte WAYF-Service ins Spiel, welcher den entsprechenden IdP ermittelt) weitergeleitet (2), wo der Benutzer sich mit seinen Anmeldedaten authentifizieren muss (3). Der SSO-Service leitet die Daten an die Authentication Authority weiter, welche ein Authentifizierungs-Statement zurückgibt, welches wiederum vom SSO-Service in Form einer SAML-Aussage an den Agenten des Benutzers weitergeleitet wird (4). Dieses Statement beinhaltet Informationen über den Erfolg bzw. Misserfolg der 10

11 Authentifizierung des Benutzers. Im nächsten Schritt wird dieses Authentifizierungs- Statement vom Agenten des Benutzers an den Assertion Consumer Service des SP weitergeleitet (5), wo dieses Statement überprüft und gegenebenfalls ein Sicherheits- Kontext erstellt wird (6). Nun versucht der Agent des Benutzers erneut auf die geschützte Ressource zuzugreifen (7), was auch gelingt, wenn ein valider Sicherheits- Kontext vorhanden ist (8) [CDS05]. Die Schritte (3) bis (7) sind transparent für den Benutzer, da der Agent des Benutzers (im Normalfall also der Browser) sie übernimmt. Darüber hinaus wird der von dem Assertion Consumer Service erstellte Sicherheitskontext für eine gewisse Zeit zwischengespeichert, in welcher dem Benutzer die Eingabe der Benutzerdaten beim IdP erspart bleibt und er direkt zur Ziel-Ressource weitergeleitet wird, wenn er erneut auf einen SP zugreift, der mit dem hier betrachteten IdP zusammenarbeitet. Abschließend bleibt noch zu erörtern, was die Vor- und Nachteile von Shibboleth für die Integration von E-Learning Anwendungen sind. Vorteile: Unterstützt weit verbreitete Standards (SAML, XML, SSL, SOAP uvm.) Open-Source Nutzung bereits vorhandener Infrastrukturen: keine eigene Authentifizierung, sondern Nutzung von Apache Webserver und/oder Tomcat Servletengine, sowie Nutzung bereits vorhandener Datenbanken [Ebe06] Sehr intuitiv, da der Benutzer sich direkt beim Service-Anbieter anmeldet und nicht zuerst bei der Authentifizierungs-Autorität Nachteile: Insgesamt eine relativ komplexe Technik: Java, Tomcat und Apache Kenntnisse werden vorausgesetzt Bisher existiert noch kein Single Sign-Out Mechanismus, was gerade im E- Learning Bereich zu Problemen führt, wenn Shibboleth von einem öffentlichen (Uni-) Rechner benutzt wird Kerberos Das Kerberos-Authentifizierungsprotokoll wurde vom MIT (Massachusetts Institute of Technology) entwickelt, um verschiedenen Parteien eine Möglichkeit zu geben, sich 11

12 zuverlässig und sicher gegenseitig zu authentifizieren. Dabei liegt das Hauptaugenmerk auf einer sicheren Kryptographie [Ker07]. Im Speziellen benutzt Kerberos den amerikanischen DES (Data Encryption Standard) [Kel06], der so sensibel ist, dass die Vereinigten Staaten den Export von Kerberos-Implementierungen bis ins Jahr 2000 verboten. Anders als Shibboleth wurde es nicht speziell zur Implementierung eines SSO-Mechanismus entwickelt, sondern für den Authentifizierungsvorgang im Allgemeinen, allerdings lässt es sich sehr komfortabel als SSO-Anwendung nutzen. Das MIT stellt eine kostenlose Implementierung dieses Protokolls zur Verfügung. Grundlegend sind auch bei einem Authentifizierungsvorgang unter Verwendung von Kerberos drei Parteien beteiligt: Principal, Key Distribution Center und der Service Anbieter [Wie08]. Principals sind die einzelnen Nutzer des Authentifizierungsmechanismus und werden im Rahmen von Kerberos über zwei Komponenten und einen Realm identifiziert. Die erste Komponente ist der Benutzername, die (optionale) zweite ist die Rolle. Der Realm gibt die Authentifizierungs-Domäne an (Beispiel: -> Die zweite Komponente kann also zum Zwecke der Autorisierung benutzt werden. Das Key Distribution Center (KDC) besteht aus der Principal Database (speichert Principals und Keys), Authentication Server (AS) und dem Ticket Granting Server (TGS) und ist zuständig für den eigentlichen Authentifizierungsvorgang. Zur Authentifizierung werden bei Kerberos so genannte Tickets benutzt. Der Anmeldevorgang unter Verwendung von Kerberos findet in zwei Stufen statt. In der ersten Stufe wird vom Nutzer ein so genanntes Ticket-Granting-Ticket (TGT) beim KDC angefordert. Mit Hilfe des TGT kann der Benutzer nun im zweiten Schritt Service Tickets (ST) anfordern, mit denen er sich bei den entsprechenden Service-Anbietern anmelden kann. Diese Schritte werden in Abb. 3 schematisch dargestellt. 12

13 In Anlehnung an [Ric08] Abb. 3: Schematischer Aufbau einer Anmeldung mit Kerberos Zunächst fordert der Client unter Angabe seiner Principal-ID (z.b. ein TGT beim Authentication Server des KDC an (1). Ist diese ID in der Principal Database vorhanden, schickt der AS eine Antwort, die das TGT (chiffriert mit dem geheimen Schlüssel des TGS, unter Verwendung des oben genannten DES) und den Session Key (chiffriert mit dem geheimen Schlüssel des Benutzers) beinhaltet (2). Das TGT kann der Client nun verwenden, um damit ein spezielles Service Ticket (ST) beim TGS anzufordern (3) (der TGS kann das TGT mit seinem geheimen Schlüssel dechiffrieren). Neben dem TGT schickt der Client dabei auch einen mit dem Session Key verschlüsselten Authenticator mit, womit er sich gegenüber dem TGS eindeutig identifiziert. Die Antwort des TGS beinhaltet das ST (chiffriert mit dem geheimen Schlüssel des Service-Anbieters) und einen Service Session Key (chiffriert mit dem zuvor vom AS generierten Session Key) (4). Daraufhin versucht der Client nun auf die Ziel-Ressource des Service-Anbieters zuzugreifen (5), und zwar mit Hilfe des zuvor erhaltenen ST und eines weiteren Authenticators (verschlüsselt mit dem vom TGS erhaltenen Service Session Key). Im letzten (optionalen) Schritt (6) identifiziert sich der Service-Anbieter beim Client, damit letzterer sicher sein kann, dass Missbrauch ausgeschlossen ist. Sind alle übergebenen Informationen korrekt, wird dem Benutzer daraufhin der Zugriff auf die Ressource gewährt. [Ric08] 13

14 Anfangs wurde erwähnt, dass Kerberos nicht ausschließlich als SSO-Mechanismus arbeitet. Die Frage ist nun also, wo in diesem Vorgang SSO-Charakteristika zu erkennen sind. Zunächst sind die Tickets den Tokens einer Token-basierten SSO- Anmeldung ähnlich. Darüber hinaus fungiert das spezielle Ticket Granting Ticket als die SSO-typische einmalige Anmeldung bei der Authentifizierungs-Autorität. Des Weiteren können mithilfe des so genannten Ticket Caches bereits erhaltene Service- Tickets auch eine gewisse Zeit lang zwischengespeichert werden, so dass wirklich nur eine einzige Anmeldung nötig ist. Abschließend werden noch die Vor- und Nachteile von Kerberos zusammengefasst: Vorteile: Ausserordentlich starke und sichere Kryptographie (DES, siehe oben) Daher eine sehr sichere gegenseitige Authentifizierung aller beteiligten Parteien Sehr performant wegen der geringen Belastung des KDC, da keine Verbindung zu den einzelnen Service-Anbietern nötig ist [Wie08] Ist bereits als Standard im RFC 1510 festgehalten [Koh93] Nachteile Nicht ohne weiteres mit NAT(Network Address Translation)-Firewalls einsetzbar [Wie08] Es ist sehr aufwändig, vorhandene Web-Applikationen so anzupassen, dass Kerberos eingesetzt werden kann Kein Single Sign-Out Mechanismus vorhanden OpenID OpenID ist ein etwas schlankerer SSO-Standard, dessen Funktionsumfang sich auf die grundlegenden SSO-Mechanismen beschränkt. Das ist vielleicht auch der Grund für die Popularität von OpenID. Viele kleinere Webseiten, Blogs und Communities sowie Yahoo unterstützen und verwenden OpenID bereits. Google, IBM und Microsoft haben verlauten lassen, dass sie planen, OpenID auch einzusetzen [Arr08]. Bei einem Anmeldevorgang unter Verwendung von OpenID sind vier Parteien beteiligt: ein Client, ein OpenID Server, ein Identity Server (manchmal auch Identity Provider 14

15 genannt) und ein Consumer (dieser Begriff ist synonym zu den bereits erwähnten Service-Anbietern zu verstehen). Der OpenID Server sorgt für die eigentliche Anmeldung, während der Identity Server für die eindeutige Identifizierung der Benutzer zuständig ist. In Anlehnung an [Win06] Abb. 4: Schematischer Aufbau einer Anmeldung mit OpenID Für die Anmeldung bei einem Consumer verwendet der Benutzer eine URL (seine so genannte OpenID), die lediglich in ein Formular eingegeben werden muss (1). Diese OpenID-URL schickt der Consumer weiter an einen Identity Server (2), welcher daraufhin eine valide URL zurückgibt, die zum Anmeldeformular des OpenID Servers führt (3). Als nächstes leitet der Consumer den Client zu dieser URL weiter (4), wo der Benutzer sich mit seinen Anmeldedaten einloggen muss (5) (hierbei handelt es sich um das SSO-typische einmalige einloggen bei einer Authentifizierungs-Autorität), gefolgt von einer erneuten Weiterleitung zum Consumer (6), wo dann im Falle einer erfolgreichen Authentifizierung der Zugriff auf die geschützte Ressource gewährt wird (7). OpenID ist zwar mittlerweile sehr weit verbreitet [Kle07], steht allerdings auch stark in der Kritik. Zum einen, weil der Identity Server alle Seiten speichert, für die man sich 15

16 mit seiner OpenID angemeldet hat [Ben07], zum anderen, weil sehr leicht Phishing- Attacken ausgeführt werden können. Für ein anschauliches Beispiel für eine solche Phishing-Attacke sei [Lau07] empfohlen. Die Single Sign-Out Problematik von Shibboleth und Kerberos besteht bei OpenID allerdings nicht, da man nicht automatisch bei allen Consumern angemeldet ist, sobald man sich authentifiziert hat. Mit anderen Worten: Single Sign-Out wird nicht benötigt. Vorteile: Weit verbreitet Leicht anzuwenden auf bereits vorhandene Webseiten Sehr intuitiv, da der Benutzer sich direkt beim Service-Anbieter anmeldet und nicht zuerst bei der Authentifizierungs-Autorität Single Sign-Out Problematik existiert nicht Nachteile: Phishing Attacken möglich Identity Server speichert alle Seiten, für die man sich mit OpenID authentifiziert hat Keine Möglichkeit weitere Benutzerdaten zu übermitteln Bietet nur sehr grundlegende SSO-Funktionen Evaluation der einzelnen SSO-Anbieter Die Frage ist nun, welche der drei Alternativen am besten geeignet ist für die Integration von E-Learning Plattformen. OpenID lässt sich in bereits vorhandene Web-Applications am einfachsten integrieren und ist mittlerweile sehr weit verbreitet. Es hat allerdings gerade im Bereich des E- Learnings signifikante Nachteile. Zum einen besteht die Gefahr von Phishing Attacken, was bei den teilweise sehr sensiblen Daten, die im Hochschulbetrieb ausgetauscht werden (Klausurergebnisse, Studentendaten usw.) sehr problematisch ist. Zum anderen gibt es derzeit keine Möglichkeit, Daten über einen Benutzer (wie z.b. Matrikelnummer 16

17 oder ZIV-ID) zu übermitteln, was aber in den allermeisten Fällen nötig ist. Allgemein verfügt OpenID nur über einen sehr geringen Funktionsumfang. Kerberos und Shibboleth sind zwar deutlich aufwändiger zu installieren und einzusetzen, bieten allerdings einen höheren Grad an Sicherheit sowie einen großen Umfang von Funktionen und sind sogar individuell erweiterbar. Kerberos legt einen besonderen Augenmerk auf die Sicherheit, was sich in einer starken Kryptographie widerspiegelt (siehe Abschnitt 2.3.2). Darüberhinaus ist es sehr performant, da keine Kommunikation zwischen Service-Anbieter und Authentifizierungs-Autorität stattfinden muss. Allerdings kann es zu Problemen kommen, wenn Kerberos in Verbindung mit NAT-Firewalls eingesetzt wird. Shibboleth hingegen bietet die Möglichkeit, beim Anmeldevorgang Attribute zu übermitteln, welche Zusatzinformationen zum Benutzer enthalten (z.b. Matrikelnummer oder adresse). Darüber hinaus ist die Anmeldung mit Shibboleth sehr intuitiv, da der Benutzer nicht zuerst auf die Authentifizierungs- Autorität zugreifen muss, um sich einzuloggen, sondern zuerst die Website des Service- Anbieters aufruft, von der er dann für die Anmeldung zum AA weitergeleitet wird. Die Benutzung weit verbreiteter Standards wie XML und SOAP ist gerade im Forschungsumfeld ein weiterer Pluspunkt. Des Weiteren wird Shibboleth schon an einigen Hochschulen eingesetzt und genießt allgemein ein hohes Ansehen aufgrund seiner offenen Schnittstellen und seiner Konzipierung für den universitären Kontext. Jedoch bietet Shibboleth keinen Single Sign-Out Mechanismus, was insbesondere im E- Learning Umfeld problematisch ist, weil dort häufig Pool-Rechner benutzt werden (siehe Abschnitt 3.2). Es bleibt festzuhalten, dass Kerberos und Shibboleth für die Integration von E-Learning Anwendungen besser geeignet sind als OpenID. Zwar ist Letzteres leichter zu handhaben, scheidet aufgrund seiner Sicherheitsschwächen und geringen Funktionsumfangs aber aus. Sowohl Kerberos als auch Shibboleth bieten (unter Inkaufnahme einiger Schwächen) eine große Zahl von Funktionen und sind gleichermaßen zu empfehlen. 17

18 3 SSO im E-Learning-Kontext 3.1 Vorteilhaftigkeit von SSO im E-Learning Kontext Nachdem in Kapitel 2 SSO im Allgemeinen und drei Anwendungen im Speziellen vorgestellt wurden, soll nun abgewogen werden, wie vorteilhaft SSO bei der Integration von E-Learning Anwendungen ist. Allgemein lassen sich folgende Vor- bzw. Nachteile beim Einsatz von SSO im E- Learning Kontext ausmachen: Vorteile: Höhere Sicherheit Höhere Benutzerfreundlichkeit Bei der Entwicklung neuer E-Learning Anwendungen muss kein Aufwand mehr betrieben werden für die Implementierung eines Authentifizierungsmechanismus [Sto07] Zentralisierte Verwaltung von Benutzerrollen und rechten Einheitliche Benutzerdatenbank Nachteile: Die Integration in eine bestehende E-Learning Landschaft einer Universität kann sehr aufwändig sein [Sto07] Bei der Nutzung kann es zu Sicherheitsproblemen kommen, wenn der Benutzer sich nicht komplett ausloggt (falls kein Single Sign-Out Mechanismus vorhanden ist) Im Folgenden wird nun am Beispiel der Westfälischen Wilhelms-Universität Münster, wo seit einiger Zeit Shibboleth als SSO-System eingesetzt wird, erörtert, ob die Voroder Nachteile überwiegen. 18

19 3.2 SSO an der Westfälischen Wilhelms-Universität SSO-Landschaft Seit 2007 wird Shibboleth an der Westfälischen Wilhelms-Universität (WWU) eingesetzt. Initiiert vom ZIV (die Zentrale Informations-Verarbeitung der WWU) [Sto07] gibt es mittlerweile einige universitäts-interne Anwendungen, die den SSO- Service benutzen. Dabei stellt das ZIV einen Identity-Provider zur Verfügung, so dass auf Seiten der E-Learning Anwendungen nur noch ein Service-Provider installiert werden muss, um den SSO-Service nutzen zu können (genaueres dazu in Abschnitt 3.2.2). Beispielanwendungen, die diesen Service bereits nutzen, sind xlx 2 [Xlx08] und Learnr [Lea07]. Während Studenten und Mitarbeiter zuvor für beide Services jeweils einen eigenen Account anlegen mussten, brauchen sie jetzt nur ihre ZIV-Anmeldedaten, die sie zu Beginn ihres Studiums bzw. Beschäftigungsverhältnisses erhalten haben, angeben, um sich eindeutig als Angehörige der WWU zu identifizieren und Zugriff zu erlangen. In diesem Falle müssen sich die Benutzer also nicht aktiv bei der Autorisierungs-Autorität (dem ZIV) registrieren, da dies automatisch zum Anfang des Studiums bzw. Beschäftigungsverhältnisses geschieht. Mit anderen Worten: jeder Studienanfänger und Mitarbeiter erhält automatisch Zugriff auf alle E-Learning Plattformen, die Shibboleth benutzen. Allerdings bieten beide Anwendungen auch noch eine herkömmliche Authentifizierung, damit sich universitäts-fremde Nutzer ebenfalls einloggen können. Das ist z.b. sinnvoll, wenn Gastdozenten bzw. hörer am Vorlesungsbetrieb teilnehmen. In dieser Konstellation bietet SSO einen weiteren Vorteil: da ausschließlich Studenten und Mitarbeiter der WWU eine ZIV-Kennung erhalten, können die Lehrstühle sicher sein, dass kein unerlaubter Zugriff auf ihre Materialien innerhalb dieser E-Learning Anwendungen stattfindet. Es ist daher nicht mehr nötig, Lehrmaterialien zusätzlich auf andere Art und Weise zu schützen. Allerdings werden auch die Nachteile des SSO deutlich. Zunächst einmal ist nicht zu erwarten, dass in absehbarer Zeit alle an der WWU vorhandenen E-Learning Anwendungen auf Shibboleth migriert werden, da die Umstellung einen tiefen Eingriff in die Authentifizierungs-Mechanismen der einzelnen Anwendungen mit sich bringt. Dass bedeutet, dass Studenten und Mitarbeiter auch in Zukunft noch viele unterschiedliche Accounts verwalten müssen. Darüberhinaus ist das Problem des nicht vorhandenen Single Sign-Outs zu lösen. Beim Logout-Vorgang von xlx2 wird der 19

20 Benutzer beispielsweise darauf hingewiesen, dass trotz des Logouts Personen, die den gleichen Rechner benutzen, immer noch Zugriff auf andere Anwendungen haben könnten (z.b. Learnr), bis die Session beendet, also der Browser geschlossen wird. Nichtsdestotrotz überwiegen die Vorteile hinsichtlich Komfort und Sicherheit. In Zukunft sollen die Benutzerdatenbanken verschiedener Universitäten vernetzt und so etwas wie ein inter-universitäres Shibboleth-Netz entwickelt wird, so dass auch die E- Learning Anwendungen anderer Universitäten über eine einheitliche Anmeldung benutzt werden können - so sind zumindest die Pläne des ZIV Kopplung mit dem zentralen Identitätsmanagement der Hochschulverwaltung Nachdem ein kleiner Einblick in die derzeitige SSO-Landschaft an der WWU gewährt wurde, beschäftigt sich dieser Abschnitt nun mit der Kopplung von SSO-Anwendungen mit dem Identitätsmanagement der Hochschulverwaltung (genauer: des ZIV). Da Shibboleth bereits seit längerer Zeit an der WWU eingesetzt wird, wird es hier als Beispielanwendung herangezogen. Wie in Abschnitt beschrieben, wird für das SSO mit Shibboleth von Seiten des ZIV ein Identity-Provider (IdP) zur Verfügung gestellt. Dieser IdP empfängt Authentifizierungsanfragen von den E-Learning Anwendungen (Service-Provider in der Sprache von Shibboleth), fordert die Benutzer zur Anmeldung auf und leitet sie ggf. weiter zu den geschützten Ressourcen der E- Learning Anwendungen (für eine detaillierte Beschreibung eines Authentifizierungsvorgangs mithilfe von Shibboleth, siehe Abschnitt 2.3.1). Von Seiten der Entwickler einer E-Learning Anwendung wird also nur verlangt, einen Service- Provider (SP) zu installieren, um auf den IdP des ZIV zugreifen zu können. Allerdings ist für die Kommunikation mit diesem IdP ein Zertifikat des ZIV nötig, welches man persönlich anfordern muss. Dieses Zertifikat wird aus Sicherheitsgründen nur an Projekte verteilt, die auch tatsächlich im Vorlesungsbetrieb eingesetzt werden. Ist diese Voraussetzung erfüllt, steht dem Einsatz von Shibboleth unter Verwendung des zentralen Identitätsmanagement des ZIV nichts mehr im Wege. Die Informationen, die dabei übermittelt werden, sind aus datenschutzrechtlichen Gründen allerdings sehr begrenzt. Tatsächlich werden nur der Nachname, die ZIV- Kennung und die Universitäts- -Adresse (in Form von Attributen) bei der Anmeldung eines Benutzers übermittelt. Andere relevante Informationen, wie z.b. 20

Identity Management mit OpenID

Identity Management mit OpenID Lehrstuhl Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München Identity Management mit OpenID Innovative Internet Technologien und Mobilkommunikation WS2008/2009 Verfasser:

Mehr

Web-Single-Sign-On in der LUH

Web-Single-Sign-On in der LUH Web-Single-Sign-On in der LUH Begriffsklärung Technischer Ablauf Umsetzung an der LUH Vor- und Nachteile Sascha Klopp Begriffsklärung Single Sign-on: Benutzer meldet sich zu Beginn seiner Sitzung an und

Mehr

Single-Sign-On mit Java und Kerberos. Michael Wiesner, SOFTCON IT-Service GmbH

Single-Sign-On mit Java und Kerberos. Michael Wiesner, SOFTCON IT-Service GmbH Single-Sign-On mit Java und Kerberos Michael Wiesner, SOFTCON IT-Service GmbH Über mich Softwareentwickler und Sicherheitsexperte bei der Firma SOFTCON Projekte: Enterprise Software, Webportale, Sicherheitslösungen,...

Mehr

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language.

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language. Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo Security Assertion Markup Language Björn Rathjens Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo 1 Einführung

Mehr

Konzepte von Betriebssystem-Komponenten Schwerpunkt Authentifizierung. Das Kerberos-Protokoll

Konzepte von Betriebssystem-Komponenten Schwerpunkt Authentifizierung. Das Kerberos-Protokoll Konzepte von Betriebssystem-Komponenten Schwerpunkt Authentifizierung Das Kerberos-Protokoll Guido Söldner guido@netlogix.de. Überblick über das Kerberos-Protokoll Ein Standardvorgang in der Computersicherheit

Mehr

Authentifizierung. Benutzerverwaltung mit Kerberos. Referent: Jochen Merhof

Authentifizierung. Benutzerverwaltung mit Kerberos. Referent: Jochen Merhof Authentifizierung Benutzerverwaltung mit Kerberos Referent: Jochen Merhof Überblick über Kerberos Entwickelt seit Mitte der 80er Jahre am MIT Netzwerk-Authentifikations-Protokoll (Needham-Schroeder) Open-Source

Mehr

Mike Wiesner mike@agile-entwicklung.de. Mike Wiesner 1

Mike Wiesner mike@agile-entwicklung.de. Mike Wiesner 1 Kerberos V5 mit Debian Mike Wiesner mike@agile-entwicklung.de Mike Wiesner 1 Agenda Einführung Implementierungen Installation Kerberized Services Windows Integration Mike Wiesner 2 Über mich Softwareentwickler

Mehr

Single-Sign-On mit Kerberos V

Single-Sign-On mit Kerberos V Single-Sign-On mit Kerberos V Jörg Rödel 21. Oktober 2005 Jörg Rödel Was ist Single-Sign-On? oft nur verstanden als ein Nutzer/Passwort-Paar für alle Dienste eines Netzwerkes so wird es

Mehr

Nachnutzung des Windows Login in einer SAML-basierten. Föderation mittels Shibboleth Kerberos Login Handler

Nachnutzung des Windows Login in einer SAML-basierten. Föderation mittels Shibboleth Kerberos Login Handler Nachnutzung des Windows Login in einer SAML-basierten Föderation mittels Shibboleth Kerberos Login Handler 56. DFN-Betriebstagung, Forum AAI Berlin, 13. März 2012 Peter Gietz, Martin Haase, DAASI International

Mehr

1. SaxIS-Shibboleth. Shibboleth-Workshop. Chemnitz, 15. Dezember 2006. Dipl. Wirt.-Inf. Lars Eberle, Projekt SaxIS und BPS GmbH

1. SaxIS-Shibboleth. Shibboleth-Workshop. Chemnitz, 15. Dezember 2006. Dipl. Wirt.-Inf. Lars Eberle, Projekt SaxIS und BPS GmbH 1. SaxIS-Shibboleth Shibboleth-Workshop Chemnitz, 15. Dezember 2006 1 Agenda Was ist Shibboleth? Warum ausgerechnet Shibboleth? Wie funktioniert es? Weg des Nutzers Weg der Daten Föderative Ansatz 2 Was

Mehr

Authentication im Web

Authentication im Web Authentication im Web Weiterführende Themen zu Internet- und WWW-Technologien 11.07.2011, Kai Fabian Inhalt 2 1. Begriffsabgrenzung 2. HTTP Basic Authentication (RFC 2617) 3. Single Sign-on-Techniken 3.1.

Mehr

Mozilla Persona. Hauptseminar Web Engineering. Vortrag. an identity system for the web. 10.12.2012 Nico Enderlein

Mozilla Persona. Hauptseminar Web Engineering. Vortrag. an identity system for the web. 10.12.2012 Nico Enderlein Mozilla Persona an identity system for the web Hauptseminar Web Engineering Vortrag 10.12.2012 Nico Enderlein 1 PASSWORT??? BENUTZERNAME??? 2 Idee IDEE Protokoll & Implementierung Voost ( Kalender für

Mehr

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS

Mehr

Das Kerberos-Protokoll

Das Kerberos-Protokoll Konzepte von Betriebssystemkomponenten Schwerpunkt Authentifizierung Das Kerberos-Protokoll Referent: Guido Söldner Überblick über Kerberos Network Authentication Protocol Am MIT Mitte der 80er Jahre entwickelt

Mehr

Sicheres Single Sign-On mit dem SAML Holder-of-Key Web Browser SSO Profile und SimpleSAMLphp

Sicheres Single Sign-On mit dem SAML Holder-of-Key Web Browser SSO Profile und SimpleSAMLphp Sicheres Single Sign-On mit dem SAML Holder-of-Key Web Browser SSO Profile und SimpleSAMLphp Andreas Mayer Adolf Würth GmbH & Co. KG Künzelsau-Gaisbach Prof. Dr. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit

Mehr

Single Sign On mit Forms direkt gegen ein Active Directory

Single Sign On mit Forms direkt gegen ein Active Directory Single Sign On mit Forms direkt gegen ein Active Directory Wolf G. Beckmann TEAM GmbH Paderborn Schlüsselworte Forms, SSO, Kerberos Einleitung Sicherheit ist zurzeit ein hochaktuelles Thema und gerät deshalb

Mehr

Organisationsübergreifendes Single Sign On mit shibboleth. Tobias Marquart Universität Basel

Organisationsübergreifendes Single Sign On mit shibboleth. Tobias Marquart Universität Basel Organisationsübergreifendes Single Sign On mit shibboleth Tobias Marquart Universität Basel Überblick Einordnung von Shibboleth, Abgrenzung zu OpenID Organisatorische und technische Komponenten einer Federation

Mehr

Raoul Borenius, DFN-AAI-Team hotline@aai.dfn.de

Raoul Borenius, DFN-AAI-Team hotline@aai.dfn.de Shibboleth als technische Grundlage für föderative Angebote Funktionalität und Einsatzbereiche am Beispiel der Authentifizierungs- und Autorisierungs-Infrastruktur des Deutschen Forschungsnetzes (DFN-AAI)

Mehr

Modul 8 Kerberos. Prof. Dr. Martin Leischner Netzwerksysteme und TK. Fachhochschule Bonn-Rhein-Sieg

Modul 8 Kerberos. Prof. Dr. Martin Leischner Netzwerksysteme und TK. Fachhochschule Bonn-Rhein-Sieg Modul 8 Kerberos M. Leischner Sicherheit in Netzen Folie 1 Steckbrief Kerberos Woher kommt der Name "Kerberos" aus der griechischen Mythologie - dreiköpfiger Hund, der den Eingang des Hades bewacht. Wagt

Mehr

Modul 8 Kerberos. Fachhochschule Bonn-Rhein-Sieg. Prof. Dr. Martin Leischner Fachbereich Informatik

Modul 8 Kerberos. Fachhochschule Bonn-Rhein-Sieg. Prof. Dr. Martin Leischner Fachbereich Informatik Modul 8 Kerberos M. Leischner Sicherheit in Netzen Folie 1 Steckbrief Kerberos Woher kommt der Name "Kerberos" aus der griechischen Mythologie - dreiköpfiger Hund, der den Eingang des Hades bewacht. Wagt

Mehr

(c) 2014, Peter Sturm, Universität Trier

(c) 2014, Peter Sturm, Universität Trier Soziotechnische Informationssysteme 6. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 1 Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung Nachweis einer behaupteten

Mehr

!"#$"%&'()*$+()',!-+.'/',

!#$%&'()*$+()',!-+.'/', Soziotechnische Informationssysteme 7. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 4(5,12316,7'.'0,!.80/6,9*$:'0+$.;.,&0$'0, 3, Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung!

Mehr

Föderiertes Identity Management

Föderiertes Identity Management Föderiertes Identity Management 10. Tagung der DFN-Nutzergruppe Hochschulverwaltung Berlin, 09.05.-11.05.2011 Peter Gietz, CEO, DAASI International GmbH Peter.gietz@daasi.de 1 von 23 (c) Mai 2011 DAASI

Mehr

Von der Testumgebung zum produktiven Einsatz von Shibboleth

Von der Testumgebung zum produktiven Einsatz von Shibboleth Authentifizierung, Autorisierung und Rechteverwaltung Von der Testumgebung zum produktiven Einsatz von Shibboleth 3. Shibboleth-Workshop Freiburg, 10. Oktober 2006 Bernd Oberknapp, UB Freiburg E-Mail:

Mehr

Kerberos. Kerberos. Folien unter. http://www.tu-berlin.de/zrz/mitarbeiter/stsc4000/tubit_kerberos_infrastruktur.pdf. 1 Stefan Schnieber 23.05.

Kerberos. Kerberos. Folien unter. http://www.tu-berlin.de/zrz/mitarbeiter/stsc4000/tubit_kerberos_infrastruktur.pdf. 1 Stefan Schnieber 23.05. Kerberos Folien unter http://www.tu-berlin.de/zrz/mitarbeiter/stsc4000/tubit_kerberos_infrastruktur.pdf 1 Stefan Schnieber Authentication of Unknown Entities on an Insecure Network of Untrusted Workstations

Mehr

B E N U T Z E R D O K U M E N TA T I O N ( A L E P H I N O

B E N U T Z E R D O K U M E N TA T I O N ( A L E P H I N O B E N U T Z E R D O K U M E N TA T I O N ( A L E P H I N O 5. 0 ) Single-Sign-On Alephino Version 5.0 1/9 zuletzt aktualisiert: 04.07.2014 Inhalt 1 Wirkungsweise...3 2 Konfigurationsbeispiele mit Apache

Mehr

B E N U T Z E R D O K U M E N TA T I O N ( A L E P H I N O

B E N U T Z E R D O K U M E N TA T I O N ( A L E P H I N O B E N U T Z E R D O K U M E N TA T I O N ( A L E P H I N O 5. 0 ) Single-Sign-On Alephino Version 5.0 1/10 zuletzt aktualisiert: 04.07.2014 Inhalt 1 Wirkungsweise...3 2 Windows Benutzer (Domain User)...4

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Anwendungen schützen mit Shibboleth

Anwendungen schützen mit Shibboleth Anwendungen schützen mit Shibboleth 4. Shibboleth-Workshop Berlin, 28. Februar 2007 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht Unterstützte Plattformen Nutzungsvarianten

Mehr

Identity and Access Management for Complex Research Data Workflows

Identity and Access Management for Complex Research Data Workflows Identity and Access Management for Complex Research Data Workflows Richard Zahoransky, Saher Semaan, Klaus Rechert richard.zahoransky@rz.uni-freiburg.de, semaan@uni-freiburg.de, klaus.rechert@rz.uni-freiburg.de

Mehr

Ein technischer Überblick

Ein technischer Überblick Wie funktioniert Shibboleth? Ein technischer Überblick 3. AAR-Workshop Freiburg, 10. Oktober 2006 Franck Borel, UB Freiburg E-Mail: borel@ub.uni-freiburg.de Übersicht Was ist Shibboleth? Warum Shibboleth?

Mehr

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de Grundlagen AAI, Web-SSO, Metadaten und Föderationen Wolfgang Pempe, DFN-Verein pempe@dfn.de DFN-AAI IdP-Workshop, 24./25. Juni 2015, HS Amberg-Weiden Was ist DFN-AAI? AAI Authentifizierung Autorisierung

Mehr

Inhaltsverzeichnis. Open-Xchange Authentication & Sessionhandling

Inhaltsverzeichnis. Open-Xchange Authentication & Sessionhandling Open-Xchange Authentication & Sessionhandling Version Date Author Changes 1.0 28.08.2006 Stephan Martin Initiale Version 1.1 29.08.2006 Marcus Klein Details Authentication via JSON 1.2 04.09.2006 Stephan

Mehr

Version 4.1. licensemanager. What's New

Version 4.1. licensemanager. What's New Version 4.1 licensemanager What's New 1 Neue Features der Version 4.1 3 2 Neue Features der Version 4.0 4 3 Neue Features der Version 3.2 5 4 Neue Features der Version 3.1.1 6 5 Neue Features der Version

Mehr

Ausblick auf Shibboleth 2.0

Ausblick auf Shibboleth 2.0 Ausblick auf Shibboleth 2.0 4. Shibboleth-Workshop Berlin, 28. Februar 2007 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht OpenSAML 2.0 Stand der Entwicklung Shibboleth

Mehr

Federated Identity Management

Federated Identity Management Federated Identity Management Verwendung von SAML, Liberty und XACML in einem Inter Campus Szenario d.marinescu@gmx.de 1 Fachbereich Informatik Inhalt Grundlagen Analyse Design Implementierung Demo Zusammenfassung

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

OAuth Ein offener Standard für die sichere Autentifizierung in APIs

OAuth Ein offener Standard für die sichere Autentifizierung in APIs OAuth Ein offener Standard für die sichere Autentifizierung in APIs Max Horváth, Andre Zayarni, Bastian Hofmann 1 Vorstellung der Speaker 2 Was ist OAuth?? 3 Was ist OAuth? OAuth ermöglicht dem Endnutzer

Mehr

Modul 8 Kerberos. Prof. Dr. Martin Leischner Netzwerksysteme und TK. Hochschule Bonn-Rhein-Sieg

Modul 8 Kerberos. Prof. Dr. Martin Leischner Netzwerksysteme und TK. Hochschule Bonn-Rhein-Sieg Modul 8 Kerberos Auch den Kerberos sah ich, mit bissigen Zähnen bewaffnet Böse rollt er die Augen, den Schlund des Hades bewachend. Wagt es einer der Toten an ihm vorbei sich zu schleichen, So schlägt

Mehr

Herzlich Willkommen! Seminar Web Engineering: Vortrag Thema: Federated Identity Management Systems Von: Thomas Blasek Betreuer: Stefan Wild

Herzlich Willkommen! Seminar Web Engineering: Vortrag Thema: Federated Identity Management Systems Von: Thomas Blasek Betreuer: Stefan Wild Herzlich Willkommen! Seminar Web Engineering: Vortrag Thema: Federated Identity Management Systems Von: Betreuer: Stefan Wild Einleitung Federated System -> Verbund von Teilnehmern Austausch von Identitätseigenschaften

Mehr

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen Thomas Lenggenhager thomas.lenggenhager@switch.ch Bern, 11. Juni 2010 Übersicht Die Shibboleth basierte SWITCHaai

Mehr

Version 4.4. security.manager. Systemvoraussetzungen

Version 4.4. security.manager. Systemvoraussetzungen Version 4.4 security.manager Systemvoraussetzungen Version 4.4 Urheberschutz Der rechtmäßige Erwerb der con terra Softwareprodukte und der zugehörigen Dokumente berechtigt den Lizenznehmer zur Nutzung

Mehr

GecMeGUI. Eine SSO-enabled Cloud WebGUI mit clientseitiger Schlüsselgenerierung

GecMeGUI. Eine SSO-enabled Cloud WebGUI mit clientseitiger Schlüsselgenerierung GecMeGUI Eine SSO-enabled WebGUI mit clientseitiger Schlüsselgenerierung Hochschule Furtwangen Frank Dölitzscher 04.04.2011 Agenda Web GUI 1. Einführung 2. Absicherung des Service Zugangs 3. Web GUI Sicherung

Mehr

Neuerungen bei Shibboleth 2

Neuerungen bei Shibboleth 2 Neuerungen bei Shibboleth 2 Shibboleth-Workshop BW Stuttgart, 7. Februar 2008 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht Aktueller Status Kommunikation IdP

Mehr

Di 8.3. Windows CardSpace und das Identity Metasystem Philosophie, Technik und Praxis. Dominick Baier

Di 8.3. Windows CardSpace und das Identity Metasystem Philosophie, Technik und Praxis. Dominick Baier Di 8.3 January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich Windows CardSpace und das Identity Metasystem Philosophie, Technik und Praxis Dominick Baier In-depth support and

Mehr

Accelerate your esales in the Digital Marketplace.

Accelerate your esales in the Digital Marketplace. Accelerate your esales in the Digital Marketplace. Shibboleth auf Umwegen Ein Erfahrungsbericht über die Integration eines Service Providers in ein hochverfügbares Multi Softwareportal System 6. Oktober

Mehr

Kobil Roundtable 2013. Identity Federation. Konzepte und Einsatz

Kobil Roundtable 2013. Identity Federation. Konzepte und Einsatz Kobil Roundtable 2013 Identity Federation Konzepte und Einsatz Basel, 23. Oktober 2013 3 AD domain controller AD domain controller csi-domäne File server Exchange server Basel, 23. Oktober 2013 4 cnlab-domäne

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Identity Propagation in Fusion Middleware

Identity Propagation in Fusion Middleware Identity Propagation in Fusion Middleware Klaus Scherbach Oracle Deutschland B.V. & Co. KG Hamborner Str. 51, 40472 Düsseldorf Schlüsselworte Oracle Fusion Middleware, Oracle Access Management, Identity

Mehr

Anwendungen schützen mit Shibboleth 2

Anwendungen schützen mit Shibboleth 2 Anwendungen schützen mit Shibboleth 2 7. Shibboleth-Workshop Karlsruhe, 13. November 2008 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht Unterstützte Plattformen

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr

1. Integration von Liferay & Alfresco 2. Single Sign On mit CAS

1. Integration von Liferay & Alfresco 2. Single Sign On mit CAS 1. Integration von Liferay & Alfresco 2. Single Sign On mit CAS Vortrag zum 4. LUGD Tag, am 21.1.2010 form4 GmbH & Co. KG Oliver Charlet, Hajo Passon Tel.: 040.20 93 27 88-0 E-Mail: oliver.charlet@form4.de

Mehr

für E-Learning in Bayern

für E-Learning in Bayern Konzept zum Shibboleth-Einsatz für E-Learning in Bayern 4. Shibboleth-Workshop, Berlin 28. Februar 2007 Wolfgang Hommel, Leibniz-Rechenzentrum 28. Februar 2007 Konzept zum Shibboleth-Einsatz für E-Learning

Mehr

OpenID und der neue, elektronische Personalausweis

OpenID und der neue, elektronische Personalausweis OpenID und der neue, elektronische Personalausweis Über sichere Identitäten im Internet CeBIT 2010, Hannover Linux Media AG Open Source Forum 05.03.2010 Sebastian Feld feld @ internet-sicherheit. de Institut

Mehr

Single Sign-On für SaaS-Dienste auf Basis von Open Source Software. Prof. Dr. René Peinl 22.08.2013

Single Sign-On für SaaS-Dienste auf Basis von Open Source Software. Prof. Dr. René Peinl 22.08.2013 Single Sign-On für SaaS-Dienste auf Basis von Open Source Software Prof. Dr. René Peinl 22.08.2013 iisys - Institut für Informationssysteme Mission: Das Institut ist ein Kompetenzzentrum für betriebliche

Mehr

Kerberos: Prinzip und Umsetzung. Sascha Klopp

Kerberos: Prinzip und Umsetzung. Sascha Klopp Kerberos: Prinzip und Umsetzung Sascha Klopp Inhalt Prinzip Umsetzung Anwendungen Vor- und Nachteile Sascha Klopp, Kerberos: Prinzip und Umsetzung, 18.11.2008 Seite 2 Historie Das Kerberos-Protokoll wurde

Mehr

Benutzer- und Gruppenverwaltung, Registrierung

Benutzer- und Gruppenverwaltung, Registrierung OS Content Management mit Zope/Plone Benutzer- und Gruppenverwaltung, Registrierung in Plone 4.0 Jennifer Meyer, Christopher Oehmig Inhalt 1. Benutzer- und Gruppenverwaltung a. Allgemeine Arbeitsweise

Mehr

Single Sign-On Step 1

Single Sign-On Step 1 Single Sign-On Step 1 Novell Tour 2006 Stefan Stiehl Senior Technology Specialist sstiehl@novell.com Holger Dopp Senior Consultant hdopp@novell.com Was ist Single Sign-On? Eine Befugnisverwaltungstechnologie,

Mehr

KvBK: Authentifizierung und Autorisierung im Web: BasicAuth, DigestAuth, OAuth

KvBK: Authentifizierung und Autorisierung im Web: BasicAuth, DigestAuth, OAuth KvBK: Authentifizierung und Autorisierung im Web: BasicAuth, DigestAuth, OAuth Julian Reisser 21. Juli 2010 Inhaltsverzeichnis 1 Authentifizierung und Autorisierung im Web 2 2 Basic Authentication 2 3

Mehr

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen FAEL-Seminar Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte

Mehr

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung

Mehr

2 Verwalten einer Active Directory

2 Verwalten einer Active Directory Einführung 2 Verwalten einer Active Directory Infrastruktur Lernziele Active Directory und DNS Besonderheiten beim Anmeldevorgang Vertrauensstellungen Sichern von Active Directory Wiederherstellen von

Mehr

Einrichten eines SSH - Server

Einrichten eines SSH - Server Einrichten eines SSH - Server Um den Server weiter einzurichten bzw. später bequem warten zu können ist es erforderlich, eine Schnittstelle für die Fernwartung / den Fernzugriff zu schaffen. Im Linux -

Mehr

Lokal, national, international: Single Sign-On mit Shibboleth. 9. Sun Summit Bibliotheken Franck Borel, UB Freiburg 13.11.

Lokal, national, international: Single Sign-On mit Shibboleth. 9. Sun Summit Bibliotheken Franck Borel, UB Freiburg 13.11. Lokal, national, international: Single Sign-On mit Shibboleth 9. Sun Summit Bibliotheken 13.11.2007, Frankfurt Übersicht Kurze Einführung in Shibboleth Lokal mylogin an der Universität Freiburg National

Mehr

Abschlussvortrag zur Diplomarbeit Aufbau und Analyse einer Shibboleth/GridShib-Infrastruktur

Abschlussvortrag zur Diplomarbeit Aufbau und Analyse einer Shibboleth/GridShib-Infrastruktur Abschlussvortrag zur Diplomarbeit Aufbau und Analyse einer Shibboleth/GridShib-Infrastruktur Stefan Marienfeld Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze Stefan Marienfeld Gliederung

Mehr

Shibboleth IdP-Erweiterungen an der Freien Universität Berlin

Shibboleth IdP-Erweiterungen an der Freien Universität Berlin Steffen Hofmann (Dipl.-Inf.) ZEDAT, Identity and Customer Management (ICM) Shibboleth IdP-Erweiterungen an der Freien Universität Berlin Informative Login-Webseiten, JAAS-Login- Module, Login-Handler,

Mehr

Enterprise Web-SSO mit CAS und OpenSSO

Enterprise Web-SSO mit CAS und OpenSSO Enterprise Web-SSO mit CAS und OpenSSO Agenda Gründe für SSO Web-SSO selbst gemacht Enterprise Web-SSO mit CAS Enterprise Web-SSO mit SUN OpenSSO Federation-Management Zusammenfassung Gründe für SSO Logins

Mehr

Kerberos. Markus Schade

Kerberos. Markus Schade Kerberos Markus Schade Agenda Einleitung Authentifizierung Protokoll Implementierungen Anwendungen Vertraust Du mir? Oder mir? Historie 1988 am MIT im Rahmen des Athena Projekts entwickelt Client/Server-Architektur

Mehr

Kundenleitfaden Secure E-Mail

Kundenleitfaden Secure E-Mail Vorwort Wir leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns elektronische

Mehr

MOA-ID Hands-On Workshop

MOA-ID Hands-On Workshop MOA-ID Hands-On Workshop Architektur und Neuerungen Wien, 27.05.2014 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Neuerungen Datenbankbasierte

Mehr

Authentication as a Service (AaaS)

Authentication as a Service (AaaS) Authentication as a Service (AaaS) Abendseminar «Innovative Alternativen zum Passwort» 26.10.2010, Hotel Novotel, Zürich Anton Virtic CEO, Clavid AG Information Security Society Switzerland 1 Agenda Cloud

Mehr

Single Sign-On mit Kerberos V5

Single Sign-On mit Kerberos V5 Froscon 2006 Michael Wiesner SOFTCON IT Service GmbH Über mich Softwareentwickler und Sicherheitsexperte bei der Firma SOFTCON Projekte: Enterprise Software, Webportale, Sicherheitslösungen,... Trainings

Mehr

Kundeninformation zu Secure E-Mail

Kundeninformation zu Secure E-Mail Kundeninformation zu Secure E-Mail Einleitung Das sogenannte Sniffen, Ausspähen von E-Mailinhalten und Authentifizierungs-dateien sowie das E-Mail Spoofing, das Erstellen einer E-Mail mit gefälschtem Absender,

Mehr

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut E-Mails versenden aber sicher! Secure E-Mail Kundenleitfaden S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie

Mehr

LDAP-Server. Jederzeit und überall auf Adressen von CAS genesisworld zugreifen

LDAP-Server. Jederzeit und überall auf Adressen von CAS genesisworld zugreifen LDAP-Server Jederzeit und überall auf Adressen von CAS genesisworld zugreifen Copyright Die hier enthaltenen Angaben und Daten können ohne vorherige Ankündigung geändert werden. Die in den Beispielen verwendeten

Mehr

Der lange Weg vom SSO-Server zu SAML und Identity Federation

Der lange Weg vom SSO-Server zu SAML und Identity Federation Der lange Weg vom SSO-Server zu SAML und Identity Federation Marc Brenkmann SüdLeasing GmbH Mannheim Dr. Joachim Reising PROMATIS software GmbH Ettlingen Schlüsselworte: Oracle Fusion Middleware 11g, Identity

Mehr

Erste Schritte nach der Installation

Erste Schritte nach der Installation Erste Schritte nach der Installation Für cosymap 30 Tage Version, Basic, Teamwork und Enterprise Diese Dokumentation unterstützt Sie bei wichtigen Einstellungen nach der Installation. 2013-2015 copyright

Mehr

Identitätskonzepte. Hauptseminar Web Engineering Vortrag. OpenID, WebID und OAuth. Robert Unger

Identitätskonzepte. Hauptseminar Web Engineering Vortrag. OpenID, WebID und OAuth. Robert Unger Identitätskonzepte OpenID, WebID und OAuth Hauptseminar Web Engineering Vortrag Robert Unger WS 12/13 07.12.2012 Inhalt Einführung OpenID WebID OAuth Fazit Quellen TU-Chemnitz - Hauptseminar Web Engineering

Mehr

Kundeninformation zu Secure E-Mail

Kundeninformation zu Secure E-Mail S Stadtsparkasse Felsberg Kundeninformation zu Secure E-Mail Einleitung Das sogenannte Sniffen, Ausspähen von E-Mailinhalten und Authentifizierungsdateien sowie das E-Mail Spoofing, das Erstellen einer

Mehr

Multicast Security Group Key Management Architecture (MSEC GKMArch)

Multicast Security Group Key Management Architecture (MSEC GKMArch) Multicast Security Group Key Management Architecture (MSEC GKMArch) draft-ietf-msec-gkmarch-07.txt Internet Security Tobias Engelbrecht Einführung Bei diversen Internetanwendungen, wie zum Beispiel Telefonkonferenzen

Mehr

E-Mails versenden - aber sicher! Sichere E-Mail mit Secure E-Mail - Kundenleitfaden -

E-Mails versenden - aber sicher! Sichere E-Mail mit Secure E-Mail - Kundenleitfaden - E-Mails versenden - aber sicher! Sichere E-Mail mit Secure E-Mail - Kundenleitfaden - Sparkasse Rosenheim-Bad Aibing Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen,

Mehr

Projekt bwidm Vereinfachter Zugang zu Landesdiensten

Projekt bwidm Vereinfachter Zugang zu Landesdiensten Projekt bwidm Vereinfachter Zugang zu Landesdiensten Vortragender: Michael Simon (KIT) Projektleiter: Martin Nußbaumer (KIT) Vision Motivation: Beobachtbarer Trend zu verteilten Diensten in Baden-Württemberg

Mehr

meinfhd 2.2 Anleitung für den Login

meinfhd 2.2 Anleitung für den Login meinfhd 2.2 Anleitung für den Login Version: R18 Datum: 12.03.2014 Status: Final Seite ii Inhaltsverzeichnis 1 Einleitung 1 2 Zentrale / übergreifende Funktionen 1 2.1 Login-Seite / Zugang zum System...

Mehr

Anlegen eines DLRG Accounts

Anlegen eines DLRG Accounts Anlegen eines DLRG Accounts Seite 1 von 6 Auf der Startseite des Internet Service Centers (https:\\dlrg.de) führt der Link DLRG-Account anlegen zu einer Eingabemaske, mit der sich jedes DLRG-Mitglied genau

Mehr

Weiterleiten von Bildern und Texten zum Abruf mit einem Browser

Weiterleiten von Bildern und Texten zum Abruf mit einem Browser EBÜS WebExport Weiterleiten von Bildern und Texten zum Abruf mit einem Browser Status: Freigegeben Dieses Dokument ist geistiges Eigentum der Accellence Technologies GmbH und darf nur mit unserer ausdrücklichen

Mehr

Dezentrales Identity Management für Web- und Desktop-Anwendungen

Dezentrales Identity Management für Web- und Desktop-Anwendungen Dezentrales Identity Management für Web- und Desktop-Anwendungen Sebastian Rieger, Thorsten Hindermann srieger1@gwdg.de, thinder@gwdg.de Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen,

Mehr

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause 1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management Deckblatt Bremen, E-Government in medias res, 12. Juli 2007 Internationale Standards zu Identity Management 3 Dataport 12.Juli 2007

Mehr

Einführung in Identitätsmanagement

Einführung in Identitätsmanagement E-Businesskommunikation René Marx, Michael Günther 1 Gliederung Einleitung Was ist Identitätsmanagement Identität im Netz Verknüpfungsmethoden des ID-Managements Motive für Kunden und Unternehmen Datenschutz

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

Hinweise zu A-Plan 2009 SQL

Hinweise zu A-Plan 2009 SQL Hinweise zu A-Plan 2009 SQL Für Microsoft Windows Copyright Copyright 2008 BRainTool Software GmbH Inhalt INHALT 2 EINLEITUNG 3 WAS IST A-PLAN 2009 SQL? 3 WANN SOLLTE A-PLAN 2009 SQL EINGESETZT WERDEN?

Mehr

webbank+ Handbuch Module & Rechner, Kapitel 1 Version 5.2 29. Januar 2015

webbank+ Handbuch Module & Rechner, Kapitel 1 Version 5.2 29. Januar 2015 // Ein Passwort für alle odule - Single Sign-on Rollen & Rechte, Bank-Admin, Applikations-Admin, Benutzer anlegen & verwalten, Applikationen verwalten, Kapitel 1 Version 5.2 29. Januar 2015 2 // Ein Passwort

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

Apache HTTP-Server Teil 2

Apache HTTP-Server Teil 2 Apache HTTP-Server Teil 2 Zinching Dang 04. Juli 2014 1 Benutzer-Authentifizierung Benutzer-Authentifizierung ermöglicht es, den Zugriff auf die Webseite zu schützen Authentifizierung mit Benutzer und

Mehr

Inhalt. TEIL I Grundlagen 1.1 1.2 1.3 1.4 1.5. TEIL II Single-Sign-on für Benutzerschnittstellen. Vorwort 13 Einleitung 15

Inhalt. TEIL I Grundlagen 1.1 1.2 1.3 1.4 1.5. TEIL II Single-Sign-on für Benutzerschnittstellen. Vorwort 13 Einleitung 15 Vorwort 13 Einleitung 15 TEIL I Grundlagen 1.1 1.2 1.3 1.4 1.5 SSO und verwandte Konzepte Chancen und Risiken Terminologie 1.3.1 Security Assertion 1.3.2 Identity Provider 1.3.3 Security Token Service

Mehr

Cloud Control, Single Sign On in Active Directory Umfeld

Cloud Control, Single Sign On in Active Directory Umfeld Cloud Control, Single Sign On in Active Directory Umfeld Abdi Mohammadi ORACLE Deutschland B.V. & Co. KG Hamburg Schlüsselworte Cloud Control, SSO, SPNEGO,, Enterprise User Security, Web SSO, Oracle Access

Mehr

mitho -Framework für plenty PHP-Framework zur Anbindung an die plenty API

mitho -Framework für plenty PHP-Framework zur Anbindung an die plenty API PHP-Framework zur Anbindung an die plenty API Inhaltsverzeichnis 1 Kurzbeschreibung...3 2 Integration...4 3 Möglichkeiten...5 3.1 Artikel...5 3.2 Aufträge...5 3.3 Kunden...5 4 Interne Funktionsweise...7

Mehr

NEVARIS Benutzerverwaltung

NEVARIS Benutzerverwaltung NEVARIS Benutzerverwaltung Integrierte Lösungen für das Bauwesen Diese Dokumentation wurde mit der größtmöglichen Sorgfalt erstellt; jedwede Haftung muss jedoch ausgeschlossen werden. Die Dokumentationen

Mehr

Black Box erklärt: Sicherheit nach IEEE 802.1x?

Black Box erklärt: Sicherheit nach IEEE 802.1x? Black Box erklärt: Sicherheit nach IEEE 802.1x? Bei Wireless LAN Netzwerken kennt jeder die Gefahr einer unbefugten Benutzung der Daten im Netzwerk durch Fremde. Aus diesem Grund gibt es in diesem Bereich

Mehr