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

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? 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 AufbaueinerFö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:http://www.incommonfederation.org/ 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: member@uni-freiburg.de • „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: oberknap@uni-freiburg.de • 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:1 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 derBenutzerdatenbank • in einer eigenen Rechtedatenbank(beim Anbieter oder bei der Heimateinrichtung) • imAAR-Rechteserver Bernd Oberknapp, UB Freiburg