Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

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 Klemerde:common_attributes [2019/08/28 11:03] – [Empfohlene Attribute] Wolfgang Pempe
Zeile 24: Zeile 24:
 | [[#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>
  
Zeile 188: Zeile 189:
 | 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. |
Zeile 230: Zeile 231:
 | 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]]| 
 + 
 +[[#a00|nach oben]] 
 +^ {{anchor:a15:15 User Status (schacUserStatus)}} ^^ 
 +| Beschreibung | Angaben zur Verlässlichkeit einer Identität und ggf. zum aktuellen Login-Vorgang | 
 +| aus Objektklasse | SCHAC | 
 +| Semantik | Angaben zur Qualität der Prozesse zur Pflege von Identitäten im IdM, der Attribut- und Identifier-Vergabe, zum aktuellen Authentifizierungsvorgang sowie anderer sicherheitsrelevanter Aspekte | 
 +| LDAP Syntax | DirectoryString | 
 +| Anzahl der Werte | mehrere | 
 +| erlaubte Werte | Liste von URNs des Typs urn:schac:userStatus:<country-code>:<domain>:<iNSS> (siehe [[https://wiki.refeds.org/display/STAN/SCHAC+Releases|offizielle Doku]])| 
 +| Bemerkungen | Das Attribut liefert Informationen zum aktuellen Status der betreffenden identität, die von SPs z.B. für Autorisierungsentscheidungen ausgewertet werden können. Ein weiterer Anwendungsfall ist die Deprovisionierung dienstlokaler Identitäten. Ein solches Szenario ist auf der Seite [[de:shibidp3userdepro#verlaesslichkeit_von_queries|User Deprovisionierung via Attribute Query]] dokumentiert. | 
 +| Beispiel | urn:schac:userStatus:de:aai.dfn.de:idmStatus:disabled | 
 +| Verwendungszweck | Anhand der übertragenen Attributwerte können SPs Autorisierungsentscheidungen treffen oder auch dienstlokale User deprovisionieren. | 
 +| OID | 1.3.6.1.4.1.25178.1.2.19 | 
 +| Referenzen | [[https://wiki.refeds.org/display/STAN/SCHAC+Releases|SCHAC-Doku]] |
  • Zuletzt geändert: vor 11 Monaten