Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste ÜberarbeitungBeide Seiten der Revision
de:common_attributes [2018/05/07 13:27] – Steffen Klemerde:common_attributes [2018/12/06 11:54] – Wolfgang Pempe
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 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. |
  • Zuletzt geändert: vor 10 Monaten