| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
| de:common_attributes [2018/05/07 13:27] – Steffen Klemer | de:common_attributes [2019/08/28 10:35] – [Übersicht über empfohlene Attribute] Wolfgang Pempe |
|---|
| | [[#a13|13]] | ORCID ID(s) | eduPersonOrcid | eduPerson | | | [[#a13|13]] | ORCID ID(s) | eduPersonOrcid | eduPerson | |
| | [[#a14|14]] | Level of Assurance / Verlässlichkeitsklasse | eduPersonAssurance | eduPerson | | | [[#a14|14]] | Level of Assurance / Verlässlichkeitsklasse | eduPersonAssurance | eduPerson | |
| | | [[#a15|15]] | User Status | schacUserStatus | SCHAC | |
| </datatables> | </datatables> |
| |
| | 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. | |
| | 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]]| |