| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
| de:common_attributes [2018/05/07 10:53] – ePUI: Format genauer spezifiziert Steffen Klemer | de:common_attributes [2019/01/29 16:09] – [Empfohlene Attribute] Wolfgang Pempe |
|---|
| | Anzahl der Werte | mehrere | | | Anzahl der Werte | mehrere | |
| | erlaubte Werte | entfällt | | | erlaubte Werte | entfällt | |
| | Bemerkungen | Der Anbieter erkennt unter dem Pseudonym eine bestimmte Person, ohne dass sich aus dem Attributwert die Identität dieser Person ableiten ließe. Der Wert ist ein anonymisierter, unumkehrbarer Wert (Hash), der aus der Entity ID des IdP, der Entity ID des SP und einer eindeutigen ID des Nutzers generiert wird. \\ In neueren IdP-Implementierungen wird dieser Wert in einer Datenbank abgelegt. Man spricht hier von einer **Persistent ID**. \\ Auch wenn die meisten Service Provider noch in der Lage sind, dieses Attribut zu verarbeiten, wird allgemein empfohlen, anstatt dieses Attributs die **SAML2 Persistent NameID** zu verwenden, die nicht als Attribut, sondern im Subject der SAML Assertion übertragen wird. Siehe unter [[de:shibidp3storage|Server-Side-Storage und Persistent Identifier]]. | | | Bemerkungen | Der Anbieter erkennt unter dem Pseudonym eine bestimmte Person, ohne dass sich aus dem Attributwert die Identität dieser Person ableiten ließe. Der Wert ist ein anonymisierter, unumkehrbarer Wert (Hash), der aus der Entity ID des IdP, der Entity ID des SP und einer eindeutigen ID des Nutzers generiert wird. \\ In neueren IdP-Implementierungen wird dieser Wert häufig in einer Datenbank abgelegt. Man spricht hier von einer **Persistent ID**. Eine Persistent Id kann nicht nur als Attribut, sondern auch als Name ID, **SAML2 Persistent NameID**, dann im Subject der SAML Assertion übertragen werden. Siehe unter [[de:shibidp3storage|Server-Side-Storage und Persistent Identifier]]. | |
| | Beispiel | entfällt (wird i.d.R. nicht im IdM / NutzerverzeichniMultifactor Authentication Profiles abgelegt) | | | Beispiel | entfällt (wird i.d.R. nicht im IdM / NutzerverzeichniMultifactor Authentication Profiles abgelegt) | |
| | Verwendungszweck | Funktionalitäten wie zum Beispiel die Personalisierung einer Anwendung, für die die Anwendung den Benutzer wiedererkennen können muss, für die aber die Identität des Benutzers nicht bekannt sein muss. | | | Verwendungszweck | Funktionalitäten wie zum Beispiel die Personalisierung einer Anwendung, für die die Anwendung den Benutzer wiedererkennen können muss, für die aber die Identität des Benutzers nicht bekannt sein muss. | |
| | erlaubte Werte | Es handelt sich um ein //Scoped Attribute// (s. [[#a07|eduPersonPrincipalName]]), bei dem der linke Teil (uniqueID) aus einem eindeutigen, max. 64 Zeichen langen, alphanumerischen String (nur [a-z],[A-Z],[0-9]) besteht, während der rechte, durch '@' abgetrennte Teil (Scope) den Domain Namen der betreffenden Einrichtung repräsentiert. | | | erlaubte Werte | Es handelt sich um ein //Scoped Attribute// (s. [[#a07|eduPersonPrincipalName]]), bei dem der linke Teil (uniqueID) aus einem eindeutigen, max. 64 Zeichen langen, alphanumerischen String (nur [a-z],[A-Z],[0-9]) besteht, während der rechte, durch '@' abgetrennte Teil (Scope) den Domain Namen der betreffenden Einrichtung repräsentiert. | |
| | Bemerkungen | Üblicherweise handelt es sich um einen pseudonymen Identifier, bei dem die Rückführung auf die Identität des Nutzers jedoch einfacher möglich ist, als bei einer targeted ID, da der Wert des Attributs über alle Anwendungen hinweg unverändert bleibt. | | | Bemerkungen | Üblicherweise handelt es sich um einen pseudonymen Identifier, bei dem die Rückführung auf die Identität des Nutzers jedoch einfacher möglich ist, als bei einer targeted ID, da der Wert des Attributs über alle Anwendungen hinweg unverändert bleibt. | |
| | Beispiel | 28c5353b8bb34984a8bd4169ba94c606@uni-musterstadt.de (wird i.d.R. aber nicht als ganzes im IdM / Nutzerverzeichnis abgelegt!) | | | Beispiel | 28c5353b8bb34984a8bd4169ba94c606@uni-musterstadt.de (wird i.d.R. aber nicht als ganzes im IdM / Nutzerverzeichnis abgelegt, sondern mittels Hash(+SALT) aus bestehenden Attributen berechnet!) | |
| | Verwendungszweck | Personalisierte Nutzung einer Gruppe von Anwendungen z.B. im Kontext eines Projekts oder einer Forschungsinfrastruktur, ggf. mit Zugriff auf spezifische Attributquellen. Siehe hierzu auch unter [[https://wiki.aai.dfn.de/de:attributes#e-research_forschungsinfrastrukturen|Attribute > E-Research / Forschungsinfrastrukturen]] | | | Verwendungszweck | Personalisierte Nutzung einer Gruppe von Anwendungen z.B. im Kontext eines Projekts oder einer Forschungsinfrastruktur, ggf. mit Zugriff auf spezifische Attributquellen. Siehe hierzu auch unter [[https://wiki.aai.dfn.de/de:attributes#e-research_forschungsinfrastrukturen|Attribute > E-Research / Forschungsinfrastrukturen]] | |
| | OID | 1.3.6.1.4.1.5923.1.1.1.13 | | | OID | 1.3.6.1.4.1.5923.1.1.1.13 | |
| | Anzahl der Werte | mehrere | | | Anzahl der Werte | mehrere | |
| | erlaubte Werte | Liste von URIs, die das jeweilige LoA-Kriterium eindeutig bezeichnen, siehe Beispiel | | | erlaubte Werte | Liste von URIs, die das jeweilige LoA-Kriterium eindeutig bezeichnen, siehe Beispiel | |
| | Bemerkungen | IdP- und SP-Betreiber müssen sich auf ein gemeinsames, kontrolliertes Vokabular einigen. Als Basis bietet sich hierfür das REFEDS Assurance Framework an, das mehrere LoA-relevante Aspekte abdeckt, siehe unter Referenzen. \\ Bedeutung der URIs im folgenden Beispiel: \\ https://refeds.org/assurance/ID/no-eppn-reassign : [[#a07|eduPersonPrincipalName]] wird auch nach dem Ausscheiden aus der Heimateinrichtung nicht neu vergeben \\ https://refeds.org/assurance/ATP/ePA-1m : nach Statuswechsel (z.B. Exmatrikulation) werden die Werte von [[#a08|eduPerson(Scoped)Affiliation]] innerhalb höchstens eines Monats aktualisiert/gelöscht \\ https://refeds.org/profile/mfa : Zusicherung, dass beim aktuellen Loginvorgang das REFEDS Multifactor Authentication Profile zur Anwendung kam (siehe unter Referenzen) | | | Bemerkungen | IdP- und SP-Betreiber müssen sich auf ein gemeinsames, kontrolliertes Vokabular einigen. Als Basis bietet sich hierfür das REFEDS Assurance Framework an, das mehrere LoA-relevante Aspekte abdeckt, siehe unter Referenzen. \\ Bedeutung der URIs im folgenden Beispiel: \\ https://refeds.org/assurance/ID/eppn-unique-no-reassign : [[#a07|eduPersonPrincipalName]] wird auch nach dem Ausscheiden aus der Heimateinrichtung nicht neu vergeben \\ https://refeds.org/assurance/ATP/ePA-1m : nach Statuswechsel (z.B. Exmatrikulation) werden die Werte von [[#a08|eduPerson(Scoped)Affiliation]] innerhalb höchstens eines Monats aktualisiert/gelöscht | |
| | Beispiel | https://refeds.org/assurance/ID/no-eppn-reassign; https://refeds.org/assurance/ATP/ePA-1m; https://refeds.org/profile/mfa | | | Beispiel | https://refeds.org/assurance/ID/no-eppn-reassign; https://refeds.org/assurance/ATP/ePA-1m | |
| | Verwendungszweck | Anhand der übertragenen Attributwerte können SPs Autorisierungsentscheidungen treffen. | | | Verwendungszweck | Anhand der übertragenen Attributwerte können SPs Autorisierungsentscheidungen treffen. | |
| | OID | 1.3.6.1.4.1.5923.1.1.1.11 | | | OID | 1.3.6.1.4.1.5923.1.1.1.11 | |
| | Referenzen | [[http://macedir.org/specs/eduperson/#eduPersonAssurance|eduPerson-Doku]] \\ [[https://wiki.refeds.org/display/CON/Consultation:+REFEDS+Assurance+Framework|REFEDS Assurance Framework (Entwurf)]] \\ [[https://wiki.refeds.org/display/PRO/MFA|REFEDS Multifactor Authentication Profile]]| | | Referenzen | [[http://macedir.org/specs/eduperson/#eduPersonAssurance|eduPerson-Doku]] \\ [[https://refeds.org/assurance|REFEDS Assurance Framework]]| |