Dies ist eine alte Version des Dokuments!


Attribute

Diese Seite bietet eine Übersicht über die Attributschemata, die in der DFN-AAI verwendet werden. Diese Schemata müssen nicht in Ihr IdM-System bzw. Nutzerverzeichnis integriert werden. Die Übersetzung zwischen IdM-Attributen und AAI-Attributen kann im IdP konfiguriert werden. Wie das grundsätzlich funktioniert, erklären wir unter Attribute in a Nutshell.

Im Hochschul- und Forschungsbereich haben sich verschiedene Attributschemata etabliert, die sich inhaltlich weitestgehend ergänzen. Die gängigsten Attribute sind in den Schemata eduPerson, person, inetOrgPerson und organizationalPerson definiert.

Attribute, die jeder IdP unterstützen sollte

Bitte schauen Sie sich unsere kommentierte Liste an, die die Attribute zeigt, die jeder Identity Provider für einen reibungslosen Betrieb liefern können sollte.

Weitere Informationen zu den Schemata bzw. Klassen finden Sie hier:

In den Bereichen E-Learning und Lernmanagementsysteme bestehen speziellere Anforderungen an die inhaltliche Aussagekraft von Attributen. Auch dafür haben wir eine kommentierte Liste der DFN-spezifischen und der gängigsten Attribute aus dem Bereich E-Learning.

Die einschlägigen Schemata sind unter folgenden Links zu finden:

FIXME (Das steht schon mind. 2x woanders hier im Wiki.) Nationale und internationale Forschungsprojekte nutzen in zunehmendem Maße zentrale Dienste, die über „Federated Login“ bzw. SAML-basiertes Web-Single-Sign-On zugänglich sind. Um im Sinne guter wissenschaftlicher Praxis einzelne Beiträge eindeutig einem Nutzer zuordnen zu können, müssen in der Regel Attribute mit personenbezogenen Angaben an den jeweiligen Service Provider übertragen werden. Siehe hierzu auch unter Attribut-Konfiguration für E-Research SPs.

Ein weiterer Anwendungsfall sind sog. Attribute Authorities, über die Community- bzw. Projekt-spezifische Attribute abgerufen werden können. Um das Mapping zwischen dem/der bei der jeweiligen Heimateinrichtung angemeldeten Nutzer(in) und diesen Attributen herzustellen, ist ein global gültiger, eindeutiger Identifier erforderlich, z.B. eduPersonPrincipalName, E-Mail-Adresse oder eduPersonUniqueId. Zu technischen Details siehe auch die betreffenden Seiten im eduGAIN- sowie im Shibboleth Wiki.

FIXME

Um den Anforderungen virtueller Organisationen zu genügen, die z.B. eine Infrastruktur gemäß der AARC Blueprint Architecture betreiben, wurde 2018 das voPerson Schema definiert.

Work in Progress

Diese Liste ist noch im Aufbau begriffen!

Konfigurationsbeispiele für Attribute Resolver und Filter sowie Relying Party finden sich hier.

1. Name Identifier und funktionsanaloge Attribute
(siehe hierzu auch SAML2int Profile V2.0, Abschnitt „3.1.3. Subject Identification“)
1.1 Omni-directional, non-targeted
urn:oasis:names:tc:SAML:attribute:subject-id Doku empfohlen
eduPersonUniqueId Doku deprecated - Wert muss identisch mit subject-id sein
eduPersonPrincipalName nicht verwenden!
mail nicht zur Identifizierung verwenden!
1.2 Pairwise / targeted
urn:oasis:names:tc:SAML:attribute:pairwise-id Doku empfohlen - Stored Id!
eduPersonTargetedID Doku deprecated - Wert muss identisch mit pairwise-id sein
persistent Id (SAML2 Name ID) deprecated - Wert muss identisch mit pairwise-id sein
1.3 Sonstige
transient Id ( SAML2 Name ID) empfohlen (für Logout benötigt)
2. Personennamen
displayName Doku empfohlen
3. E-Mail-Adresse(n) - nicht als Identifier verwenden!
mail Doku empfohlen (idealerweise ein Wert)
4. Name der Heimateinrichtung
schacHomeOrganization und o Doku empfohlen
5. Sonstige Attribute, die grundsätzlich definiert (Attribute Resolver) sein müssen
eduPersonAssurance Doku siehe REFEDS Assurance Framework
eduPersonEntitlement Doku
eduPersonOrcid Doku bleibt ggf. leer
eduPersonScopedAffiliation Doku
schacUserStatus Doku insbes. zur SP-seitigen Deprovisionierung
  • Zuletzt geändert: vor 4 Jahren