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 Überarbeitung Beide Seiten der Revision
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 5 Monaten