Dienste nutzen (IdP)

Im Rahmen der DFN-AAI steht eine Vielzahl von Diensten zur Verfügung, die ein breites Spektrum von Anwendungsszenarien bedienen. Eine Übersicht über die verfügbaren Service Provider in den verschiedenen Metadaten-Aggregaten bietet der DFN-AAI Metadata Viewer.

Als technische Voraussetzung müssen IdP-seitig die entsprechenden MetadataProvider konfiguriert sein, siehe hierzu die Hinweise zum Produktivbetrieb. Weiterhin muss der jeweilige IdP technisch in der Lage sein, die zur Nutzung des jeweiligen Dienstes erforderlichen Attribute zu generieren (attribute-resolver.xml) und zu übertragen (attribute-filter.xml). Siehe hierzu die Konfigurationsbeispiele zum Shibboleth IdP, sowie die Dokumentation und die Beispiele im Shibboleth Wiki. Eine Übersicht zum Attribut-Fluss findet sich in dieser Präsentation.

Beachten Sie bitte bei der Übertragung personenbezogener Daten die Aspekte des Datenschutzes. Wir raten in jedem Fall dazu, ein User Consent Modul einzusetzen. Der Shibboleth IdP bringt es ab Version 3 mit.

Der Zugang zu einem Dienst kann im Einzelfall eingeschränkt sein, sowohl auf bestimmte IdPs bzw. Einrichtungen, als auch auf einzelne Nutzer*innen und Gruppen.

Zu den im folgenden erwähnten Attributen siehe auch diese Übersicht.

Eine Reihe von Diensten stehen prinzipiell allen Nutzer*innen und Einrichtungen offen. Allerdings sind sie in der Regel nur personalisiert nutzbar: Der IdP muss personenbezogene Angaben übertragen, z.B. Namen, E-Mail-Adresse und/oder eindeutige Identifier (eduPersonPrincipalName, persistentId, eduPersonTargetedID, eduPersonUniqueId). Dienste dieser Art sind zum Beispiel:

• Gigamove (DFN-AAI)
• TextGrid (DFN-AAI-Basic)
• WebLicht (DFN-AAI)

Andere Dienste stehen zwar grundsätzlich allen IdPs/Einrichtungen offen, allerdings sind nur bestimmte Nutzergruppen zugriffsberechtigt. I.d.R. handelt es sich hierbei um Angehörige der jeweiligen Einrichtung im engeren Sinne, d.h. gemäß des jeweiligen Landeshochschulgesetzes. Zur Autorisierung werden normalerweise die Attribute eduPersonScopedAffiliation und/oder eduPersonEntitlement abgefragt. Ein Beispiel ist der vom DFN angebotene Konferenzdienst DFNconf, bei dem nur bestimmte Nutzergruppen Meetingräume einrichten dürfen:

• Konferenzdienste (DFNconf) (DFN-AAI-Basic)

Eine weitere, sehr große Gruppe, stellen die klassischen Bibliotheksdienste dar, also Inhaltsanbieter (Content Providers) die nur von Angehörigen von Einrichtungen genutzt werden können, mit denen ein meist kostenpflichtiger Lizenzvertrag abgeschlossen wurde. Normalerweise sind gemäß den Lizenzbestimmungen nur bestimmte Nutzergruppen berechtigt, auf die jeweiligen Inhalte zuzugreifen, d.h. auch hier ist eine Autorisierung anhand bestimmter Attribute erforderlich. Bei den berechtigten Nutzergruppen handelt es sich in aller Regel um Angehörige der jeweiligen Einrichtung gemäß des jeweiligen Landeshochschulgesetzes und fallweise um Bibliotheksnutzer*innen, die von Bibliotheksterminals aus auf lizenzierte Inhalte zugreifen (Library Walk-In). Zur Autorisierung werden wahlweise die Attribute eduPersonScopedAffiliation mit den anonymen Werten „member@…“ bzw. „library-walk-in@…“ oder eduPersonEntitlement mit „urn:mace:dir:entitlement:common-lib-terms“ ausgewertet. Ein Beispiel für eine entsprechende Attribute Filter Policy findet sich in der IdP-Dokumentation. Hier eine kleine Auswahl solcher Dienste:

• EBSCOhost (DFN-AAI)
• ProQuest (DFN-AAI)
• SpringerLink (DFN-AAI)

Seit einiger Zeit setzen internationale Forschungsinfrastrukturen vermehrt auf föderierten Zugang zu ihren Diensten. In manchen Fällen stehen solche Dienste einer breiten wissenschaftlichen Öffentlichkeit zur Verfügung (z.B. TextGrid oder WebLicht, s.o.). In anderen Fällen sind spezielle, mitunter temporäre Berechtigungen erforderlich, die häufig über Entitlements abgebildet und von der jeweiligen wissenschaftlichen Community gepflegt werden. Diese Attribute werden üblicherweise nicht von den IdPs der jeweiligen Heimatorganisation vorgehalten, sondern in Attribute Authorities hinterlegt, die vom jeweiligen Projekt gepflegt werden. Nicht nur der guten wissenschaftlichen Praxis wegen, sondern auch um das Mapping zwischen den bei der jeweiligen Heimateinrichtung angemeldeten Nutzer*innen und den in einer dienst-/projektspezifischen Attribute Authority hinterlegten Attributen herzustellen, ist neben Angaben zu Personennamen, Einrichtung und eMail ein global gültiger, eindeutiger Identifier erforderlich, z.B. eduPersonPrincipalName, eMail-Adresse oder eduPersonUniqueId (siehe auch unter Attribute).