Einführung in das Verfahren Shibboleth Schwerpunkt Iden:ty Provider

Transkript

1 Einführung in das Verfahren Shibboleth Schwerpunkt Iden:ty Provider , 9. Shibboleth Workshop in Köln Franck Borel,

2 Übersicht Einführung in Shibboleth Betriebsumfeld Architektur des IdP Standardanbindungen Metadaten Ausblick 2.2 Franck Borel 2

3 Einführung in Shibboleth Shibboleth ist ein einrichtungsübergreifender SSO Dienst für den Zugriff auf geschützte Web Ressourcen Wird von Internet2 entwickelt hop://shibboleth.internet2.edu Basiert auf SAML (Security Asser:on Markup Language) Open Source Lizenz Franck Borel 3

4 Wie funk:oniert Shibboleth? Anbieter Erstzugriff 1 Shibboleth Sitzung vorhanden? 3 2 nein Discovery Service 4 6 Authen:fizierungs abfrage Login 5 8 Heimateinrichtung Franck Borel borel@gbv.de AuthN & AOribute ja 7 nein Zugriff 4

5 Wie funk:oniert Shibboleth? Anbieter Zweitzugriff, gleicher Anbieter 1 Shibboleth Sitzung vorhanden? 2 ja ja nein Zugriff Heimateinrichtung Franck Borel borel@gbv.de 5

6 Wie funk:oniert Shibboleth? Anbieter Zweitzugriff, anderer Anbieter 1 Shibboleth Sitzung vorhanden? 2 nein Discovery Service 3 Authen:fizierungs abfrage 4 6 Heimateinrichtung Franck Borel borel@gbv.de AuthN & AOribute ja 5 nein Zugriff 6

7 Demo hops://proxy.na:onallizenzen.de/login? url=hop:// hop://ovidsp.ovid.com/ Franck Borel 7

8 Bestandteile/Sobware Unterstützte Betriebssysteme: Linux Mac OS X Solaris Windows Typische Sobware: Iden:ty Provider: Tomcat 5.5.x/6.0.x Apache 2.2 mit mod_ssl oder mod_proxy (Verbindung zum Tomcat) JDK 1.5/1.6 Service Provider: Apache + mod_ssl (für HTTPS) Franck Borel borel@gbv.de 8

9 Bestandteile Heimateinrichtung Anbieter Apache mod_proxy Tomcat IdP SSO Profile Tomcat Discovery Service Apache Shib Modul Shib Daemon AOribute Authority Authen :ca:on Handler Zer:fikate Service Provider Zugriffskontrolle IdM Web Ressource Franck Borel 9

10 Authen:fizierung Bei Shibboleth 2 übernimmt der IdP die Kontrolle über die Authentifizierung. Authentifizierung erfolgt über Authentication-Handler, die an verschiedenen Authentifizierungsendpunkten horchen: UsernamePassword IPAddress RemoteUser (ähnlich wie beim IdP 1.3) Eigene Authen9fizierungsverfahren können implemen:ert werden Franck Borel borel@gbv.de 10

11 Authen:fizierung Service-Provider kann vorgeben, welche Authentifizierungsmethode verwendet werden darf verlangen, dass der Benutzer sich erneut authentifiziert (IdP muss dies unterstützen) verlangen, dass am IdP keine Interaktion mit dem Benutzer erfolgt (passive Authentifizierung) Franck Borel 11

12 Autorisierung A?ribute bilden die Grundlage für die Autorisierung und Zugriffskontrolle in Shibboleth: Iden:ty Provider stellen mit AOributen die notwendigen Informa:onen über ihre Benutzer zur Verfügung. Service Provider werten die AOribute anhand ihrer Regeln aus und gestaoen oder verweigern je nach Ergebnis den Zugriff. Hierfür sind Absprachen zwischen Iden9ty und Service Providern notwendig, die durch Verwendung eines einheitlichen Schemas vereinfacht werden Franck Borel 12

13 eduperson Schema Schemata legen eine Menge von A?ributen, die zulässigen Werte und deren Bedeutung fest. InCommon empfiehlt das auf eduperson basierende Schema für den Austausch von AOributen: hop:// docs/policies/federatedaoributes.pdf Födera9onen und interna9onale Anbieter orien:eren sich üblicherweise an dieses Schema: DFN AAI SWITCH (swisseduperson) HAKA (funeteduperson) Franck Borel 13

14 eduperson Schema Service Provider kommen in den meisten Fällen mit folgenden A?ributen aus: edupersonaffiliadon edupersonen*tlement edupersonprincipalname Franck Borel 14

15 edupersonen:tlement Ermöglicht den Austausch beliebiger Benutzerinforma:onen. Zulässige Werte: URIs, d.h. URNs oder URLs, wobei meistens URNs verwendet werden. Die Bedeutung der En:tlement Werte muss zwischen Iden:ty und Service Providern abgesprochen werden Absprachen auf Födera:onsebene oder sogar födera9onsübergreifend sind wünschenswert! Franck Borel 15

16 edupersonen:tlement Wich:gster En:tlementwert im Bibliotheksbereich: urn:mace:dir:en:tlement:common lib terms Bedeutung: Nutzer ist berech:gt, die von seiner Einrichtung im Rahmen einer Standardlizenz lizenzierten Inhalte zu nutzen (bei Hochschulen: Mitglieder/Angehörige der Hochschule oder Walkin Patrons). Die meisten (kommerziellen) Anbieter unterstützen oder erwarten sogar, dass dieser En:tlementwert verwendet wird. Franck Borel 16

17 edupersonscopedaffilia:on Ermöglicht die Zuordnung der Nutzer einer Einrichtung zu einigen grundlegenden Rollen. Zulässige Werte sind: member, faculty, staff, employee, student, alum, affiliate, librarywalk in. Beispiel: Probleme: Die Bedeutung der Werte ist auf interna:onaler Ebene nicht einheitlich festgelegt (z.b.: Was ist ein student?) Franck Borel 17

18 edupersonprincipalname Eindeu:ge, persistente Iden:tät des Nutzers inklusive Domain ( NetID ). Beispiel: borel@gbv.de Sollte aus Datenschutzgründen nur verwendet werden, wenn die Nutzung eines Dienstes nicht anonym oder pseudonym erfolgen kann! Beispiel: Schreibender Zugriff auf eine Anwendung, z.b. ein Wiki oder Forum Franck Borel borel@gbv.de 18

19 AOribute und Zugriffskontrolle Heimateinrichtung Anbieter Iden:ty Provider AOribute Authority AFP AOribute Filter AOribute Resolver IdM AOribute push Erhält spezifische AOribute und entscheidet über den Zugriff Apache Shib Module Shib Daemon AOribute Policy AOribute Map Service Provider Zugriffskontrolle Web Ressource Franck Borel 19

20 AOribute Resolver AGribute Resolver erzeugt AOributliste Konnektoren: sta:scher Konnektor Datenbank Konnektor LDAP Konnektor Stored ID Data Connector: eindeu:ge, persistente und opake Kennung für den Benutzer Bei Bedarf können eigene Konnektoren eingebunden werden Übernimmt das Encoding (Base64, XMLObject) Iden:ty Provider AOribute Authority AFP AOribute Filter AOribute Resolver IdM Franck Borel 20

21 AOribute Filter Attribut-Filter Liste der benötigten Attribute filtert Attribute und Attributwerte filtert NameIDs abhängig von der Relying-Party Möglichkeit eigene Filter zu definieren Attribute Release Policies (ARP) Einrichtungsübergreifend Benutzergruppen Gruppen von SPs Iden:ty Provider AOribute Authority AFP AOribute Filter AOribute Resolver IdM Franck Borel 21

22 NameIden:fier Wich:gste EigenschaQen (Unterschiede zum AOribut): Eindeu9gkeit: NameIden:fier kann eindeu9g einem IdP zugeordnet werden Umkehrbarkeit: Der IdP kann einen NameIden:fier einen Benutzer zuordnen (solange der NameIden:fier gül:g ist) Können genauso erzeugt werden wie AOribute! Zwei Typen: transient NameIdeniDfier (Lebenszeit 5 Minuten) und persistent NameIdenDfier Franck Borel borel@gbv.de 22

23 Betriebsumfeld IdP JVM Apache Server Tomcat Server Service Host ajp Context IdP JAAS mod_jk IdM Franck Borel 23

24 Architektur des IdP IdPSession Filter Profile Authen:fizierung Principal Autorisierung SchniOstelle zum IdM Iden:ty Management Franck Borel 24

25 Konfigura:on des IdP web.xml IdPSession Filter Profile service.xml handler.xml Principal Autorisierung Encoding aoributeresolver.xml web.xml Authen:fizierung Filter Resolver aoributefilter.xml aoributeresolver.xml SchniOstelle zum IdM Iden:ty Management Franck Borel 25

26 Standardanbindung Authen:fizierung RemoteUser UsernamePassword IPAddress PreviousSession (Single Sign On) Autorisierung Konnektor für sta:sche Daten Konnektor zum Speichern von persistenten IDs mit Hilfe einer Datenbank Konnektor für rela:onale Datenbanken LDAP Konnektor Franck Borel 26

27 StandardschniOstellen zum IdM JAAS LDAP, Ac:ve Directory Kerberos JDBC Rela:onale Datenbanken (nur Autorisierung) Franck Borel 27

28 Standardanbindung Was kann man mit der Standardanbindung alles machen? Authen:fizierung mit Benutzername und Passwort mit der IP Adresse verschiedene IdMs mit JAAS abfragen. Hierbei gelten die Regeln die JAAS vorgibt! LDAP Server, Kerberos, Ac:ve Directory und rela:onale Datenbanken Autorisierung LDAP Server, Ac:ve Directory und rela9onale Datenbanken IdMs in Reihe schalten Franck Borel 28

29 Standardanbindung Was geht nicht? Authen:fizierung: AuthNHandler kombinieren: z.b. Benutzername/Passwort + IP Adresse IdMs in Reihe schalten Andere Parameter neben den Benutzernamen und dem Passwort verwenden (z.b. IP Adresse, Organisa:on) Beliebige Protokolle zur Abfrage des IdM verwenden (z.b. SOAP, (X)SLNP) Kombinierte Abfragen: Zusammentragen von Informa:onen und diese auswerten. X.509 Authen:fizierung Rela:onale Datenbank Autorisierung Beliebige Protokolle zur Abfrage des IdM verwenden (z.b. SOAP, (X)SLNP) Kombinierte Abfragen: Zusammentragen von Informa:onen und diese auswerten. Franck Borel borel@gbv.de 29

30 Metadaten Die Metadaten bilden die Födera9on auf technischer Ebene ab Sie beinhalten eine vollständige Liste aller teilnehmenden Provider (IdP, SP) Zer9fikate und en*tyid garan:eren, dass die Provider immer wissen, wer gerade mit Ihm spricht Metadaten werden signiert, um Ihre Authen9zität und Integrität zu gewährleisten Metadaten müssen aktuell sein, sonst klappt die Interoperabilität nicht Franck Borel 30

31 Metadaten Heimateinrichtung Anbieter IdP Service Provider Discovery Service Metadaten Metadaten Metadaten Franck Borel 31

32 Ausblick 2.2 IP Authen:fizierung und REMOTE_USER soll ebenfalls über JAAS laufen Verbesserte PKIX Validierung X.509 Authen:fizierung Service Provider kann A?ribute, die er benö:gt in die Metadaten eintragen lassen. Ein Filter wie ArpViewer (uapprove) soll dafür sorgen, dass der Nutzer die Übertragung der AOribute akzep:eren oder verweigern kann. IdP: Installa:on mit Je?y (op:onal) IdP: Automa:sche Sobware Updates, automa:sche Konfigura9onsskripte Franck Borel 32

33 Fer:g! Danke, dass Sie zugehört haben! Franck Borel Anzutreffen auf: hop:// hop://aar.ub.uni freiburg.de hop:// Franck Borel 33