Föderationen: Richtlinien, Zertifikate und Attribute

Präsentation zum Thema: "Föderationen: Richtlinien, Zertifikate und Attribute"—  Präsentation transkript:

1 Föderationen: Richtlinien, Zertifikate und Attribute
Shibboleth-Workshop Freiburg, 12. Oktober 2005 Bernd Oberknapp, UB Freiburg

2 Übersicht Was ist eine Föderation? Aufgaben einer Föderation
Aufbau einer Föderation Richtlinien Zertifikate Attribute Bernd Oberknapp, UB Freiburg

3 Was ist eine Föderation?
Einrichtung en Anbieter Bernd Oberknapp, UB Freiburg

4 Was ist eine Föderation?
Eine Föderation ist ein Zusammenschluss von Einrichtungen und Anbietern auf Basis gemeinsamer Richtlinien. Eine Föderation schafft das für Shibboleth notwendige Vertrauensverhältnis zwischen Einrichtungen und Anbietern und einen organisatorischen Rahmen für den Austausch von Benutzerinformationen. Bernd Oberknapp, UB Freiburg

5 Aufgaben einer Föderation
Aufgaben einer Föderation sind: Vorgabe von Richtlinien (Policies) Verwaltung der Metadaten der Mitglieder Betrieb des Lokalisierungsdienstes (WAYF) Betrieb einer Zertifizierungsstelle Technischer Support Bernd Oberknapp, UB Freiburg

6 Aufbau einer Föderation
Einrichtungen aus dem Hochschulbereich schließen sich üblicherweise landesweit zu Föderationen zusammen, zum Beispiel: USA (InCommon), Großbritannien (SDSS), Schweiz (SWITCH), Finnland (HAKA) Einrichtungen und Anbieter können jeweils zu mehreren Föderationen gehören! Aufbau einer deutschlandweiten Föderation im Rahmen des DFN wird angestrebt Bernd Oberknapp, UB Freiburg

7 Aufbau einer Föderation
Für den Aufbau einer Föderation müssen (mindestens) festgelegt werden: Organisationsstruktur Voraussetzungen für die Mitgliedschaft Rechte und Pflichten der Föderation Rechte und Pflichten der Mitglieder Richtlinien Bernd Oberknapp, UB Freiburg

8 Richtlinien In den Richtlinien sollten unter anderem
folgende Punkte geregelt werden: Aufnahmeverfahren für neue Mitglieder Aktualisierung der Metadaten akzeptierte (CA-)Zertifikate Standardattribute Vorgehensweise bei Missbrauch Bernd Oberknapp, UB Freiburg

9 Richtlinien Mitglieder der Föderation müssen üblicherweise
folgende Punkte dokumentieren bzw. es werden Mindeststandards festgesetzt für: Identity Provider: Benutzerverwaltung Authentifizierungssystem Service Provider: benötigte Attribute Datenschutzrichtlinien Bernd Oberknapp, UB Freiburg

10 Föderationen: Beispiele
Schweiz/SWITCH (Stiftung): AAI Service Agreement AAI Policy AAI Federation Partner Agreement USA/InCommon (GmbH): Participation Agreement Participant Operational Practices Federation Operating Practices and Procedures Bernd Oberknapp, UB Freiburg

11 Zertifikate Zertifikate werden bei Shibboleth zum Signieren
von Dokumenten und zum Verschlüsseln der Kommunikation (TLS/SSL) verwendet: Kommunikation Browser mit Webserver Kommunikation shibd mit AA Signieren von SAML-Dokumenten Signieren der Metadaten der Föderation (Shibboleth extkeytool) Bernd Oberknapp, UB Freiburg

12 Zertifikate für die Webserver (IdPs, SPs, WAYF) können im Prinzip beliebige Zertifikate verwendet werden Zertifikate für die interne Kommunikation bzw. die entsprechenden CA-Zertifikate müssen in den Metadaten eingetragen sein welche Zertifikate verwendet werden dürfen, wird üblicherweise in den Richtlinien festgelegt Beispiel SWITCHaai CA Acceptance Policy: SwissSign, TC TrustCenter (Class 2 und 3), Thawte Server (Premium), Verisign (Class 3) Bernd Oberknapp, UB Freiburg

13 Shibboleth-Standardattribute
Shibboleth/InCommon-Standardattribute basieren auf dem eduPerson-Schema: docs/policies/federatedattributes.html Internationale Anbieter halten sich üblicherweise an diesen Standard Service Provider kommen meistens mit einigen wenigen Attributen aus, die in der Shibboleth-Software bereits weitgehend vorkonfiguriert sind Bernd Oberknapp, UB Freiburg

14 Shibboleth-Standardattribute
eduPersonScopedAffiliation: Beispiel: „Grobzuordnung“ der Benutzer zu Mitglieder (member), Mitarbeiter (staff), Studierende (student), usw. der Einrichtung bei vielen nicht personalisierten Anwendungen das einzige Attribut, das benötigt wird Anwendungsbeispiel: Campuslizenz für eine Hochschule mit Zugriff für alle Mitglieder Bernd Oberknapp, UB Freiburg

15 Shibboleth-Standardattribute
eduPersonPrincipalName: Beispiel: eindeutiger, persistenter Identifier des Benutzers inklusive Domain („NetID“) sollte aus Datenschutzgründen nur verwendet werden, wenn die Nutzung einer Anwendung nicht anonym oder pseudonym erfolgen kann Anwendungsbeispiel: Zugriff auf eine Anwendung (z.B. Wiki oder Webseite) mit Schreibrechten Bernd Oberknapp, UB Freiburg

16 Shibboleth-Standardattribute
eduPersonTargetedID: eindeutiges, persistentes Pseudonym des Benutzers für einen Service Provider ermöglicht die Wiederkennung des Benutzers (z.B. für personalisierte Anwendungen notwendig) ohne die Identität des Benutzers kennen zu müssen und ohne dass zwei Anbieter Informationen über den Benutzer zusammenführen könnten Anwendungsbeispiel: diverse kommerzielle Anbieter wie Napster Bernd Oberknapp, UB Freiburg

17 Shibboleth-Standardattribute
eduPersonEntitlement: Beispiele: urn:mace:incommon:entitlement:common: urn:mace:aar:entitlement:redi:unifr:jura urn:mace:aar:entitlement:ezb:admin urn:mace:ebsco.com:<EBSCO-Account> beliebige Rechteinformationen, Bedeutung muss zwischen Heimateinrichtung und Anbieter oder im Rahmen der Föderation vereinbart werden Anwendungsbeispiele: InCommon, ReDI, EZB, JVCS Booking System, EBSCO, ... Bernd Oberknapp, UB Freiburg

18 Attribute: Offene Fragen
Welche Attribute werden überhaupt für welche Anwendungen benötigt? Welche Standardattribute sollten im Rahmen der Föderation definiert werden? Wo werden die Attribute gespeichert? Alternativen: in der Benutzerdatenbank in einer eigenen Rechtedatenbank (beim Anbieter oder bei der Heimateinrichtung) im AAR-Rechteserver Bernd Oberknapp, UB Freiburg