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
de:common_attributes [2018/05/07 13:27]
Steffen Klemer
de:common_attributes [2019/01/29 16:09]
Wolfgang Pempe [Empfohlene Attribute]
Zeile 188: Zeile 188:
 | 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 verarbeitenwird allgemein empfohlenanstatt dieses Attributs die **SAML2 Persistent NameID** ​zu verwendendie 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 230:
 | 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]]|
  • Zuletzt geändert: vor 7 Monaten