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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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