Warum werden persistente SAML-Identifikatoren als "Datenschutzmechanismus" verwendet? Core-Spezifikation

Question

Abschnitt 8.3.7 der SAML besagt, dass das persistent NameID Format für den Schutz der Privatsphäre verwendet wird:

Persistent Identifier werden als Datenschutzmechanismus vorgesehen; als solche dürfen sie NICHT im Klartext mit anderen Providern als den Providern geteilt werden, die den gemeinsamen Identifier eingerichtet haben. Darüber hinaus dürfen sie NICHT in Protokolldateien oder ähnlichen Speicherorten ohne entsprechende Steuerelemente und Schutzmaßnahmen angezeigt werden.

Ich bin nicht sicher, dass ich die Absicht hinter der Verwendung von persistenten Identifikatoren als Datenschutzmechanismus verstehe - vor allem in Anbetracht der Tatsache, dass die meisten der anderen NameID Typen (E-Mail, SN, qualifizierte Namen, Kandare Prinzipal usw.) wird in allen SPs gleich sein.

Wie ist die eindeutige NameID per-SP ein "Datenschutzmechanismus"? Insbesondere, welche Angriffsvektoren würden durch die Verwendung eines persistent NameID-Felds gegenüber einem anderen Typ gemildert werden (insbesondere wenn Schutzmechanismen wie korrekte Zuschauereinschränkungen und Signaturen vorhanden sind)?

Answer 1

Es handelt sich um einen Mechanismus zum Schutz der Privatsphäre, da der echte Bezeichner nicht vom IdP zum SP übertragen wird. In der Zwischenzeit überträgt der E-Mail-Name-ID-Typ Ihre E-Mail beispielsweise vom IdP an den SP.

Eine Online-Ressource, die ich finden kann, die diese ziemlich gut erklärt, ist http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html Abschnitt 5.4.3 Federation mit Persistent Pseudonym Identifiers.

Die Verarbeitung ist wie folgt:

1. Der Benutzer versucht, auf eine Ressource auf cars.example.co.uk zuzugreifen. Der Benutzer hat keine aktuelle Anmeldesitzung (d. H. Sicherheitskontext) auf dieser Site und ist ihm unbekannt. Die Ressource, auf die der Benutzer zugreifen wollte, wird als RelayState-Information gespeichert.

2. Der Service Provider verwendet die HTTP-Redirect-Bindung, um den Benutzer an den Identity-Provider (airline.example.com) zum Single Sign-On Service zu senden. Die HTTP-Umleitung enthält eine SAML-Nachricht, die anfordert, dass der Identitätsanbieter eine Assertion unter Verwendung einer dauerhaften Namenskennung für den Benutzer bereitstellt. Da der Dienstanbieter wünscht, dass der IdP die Flexibilität hat, einen neuen Identifizierer für den Benutzer zu erzeugen, sollte einer noch nicht existieren, setzt der SP das AllowCreate-Attribut für das NameIDPolicy-Element auf 'true'.

3. Der Benutzer wird aufgefordert, gültige Anmeldeinformationen anzugeben.
4. Der Benutzer stellt gültige Anmeldeinformationen zur Verfügung, die ihn als John identifizieren, und für den Benutzer wird am IdP ein lokaler Sicherheitskontext erstellt.
5. Der Dienst für einmaliges Anmelden sucht Benutzer John in seinem Identitätsspeicher und erstellt, da das Attribut AllowCreate dies zulässt, eine beständige Namenskennung (61611), die für die Sitzung beim Dienstanbieter verwendet wird. Es erstellt dann eine signierte SAML-Web-SSO-Assertion, wobei das Subjekt ein transientes Namensidentifizierungsformat verwendet. Der Name John ist nirgendwo in der Behauptung enthalten. Beachten Sie, dass die Assertion abhängig von den Partnervereinbarungen auch eine Attributanweisung enthalten kann, die Identitätsattribute über den Benutzer beschreibt (z. B. deren Mitgliedschaftsstufe).
6. Der Browser gibt aufgrund einer Benutzeraktion oder Ausführung eines Skripts zum automatischen Senden eine HTTP POST-Anforderung aus, um das Formular an den Assertion Consumer Service des Dienstanbieters zu senden.
7. Der Assertion Consumer-Dienst des cars.example.co.uk-Dienstanbieters validiert die digitale Signatur in der SAML-Antwort und validiert die SAML-Zusicherung. Die angegebene Namenskennung wird dann verwendet, um festzustellen, ob eine vorherige Föderation eingerichtet wurde. Wenn eine frühere Föderation eingerichtet wurde (weil die Namenskennung einem lokalen Konto zugeordnet ist), fahren Sie mit Schritt 9 fort. Wenn keine Föderation für die persistente Kennung in der Assertion vorhanden ist, muss das SP die lokale Identität ermitteln, zu der es gehören sollte zugewiesen. Der Benutzer wird aufgefordert, lokale Anmeldeinformationen im SP bereitzustellen. Optional kann der Benutzer zuerst gefragt werden, ob er die zwei Konten verbinden möchte.
8. Der Benutzer bietet gültige Anmeldeinformationen und identifiziert sein Konto bei der SP als jdoe. Die beständige Namenskennung wird dann zusammen mit dem Namen des Identitätsanbieters, der die Namenskennung erstellt hat, gespeichert und beim jdoe-Konto registriert.
9. Eine lokale Anmeldesitzung wird für den Benutzer jdoe erstellt und anschließend wird eine Zugriffsprüfung durchgeführt, um festzustellen, ob der Benutzer jdoe die richtige Berechtigung zum Zugriff auf die gewünschte Ressource auf der Website cars.example.co.uk hat (die URL der Ressource war abgerufen aus den Relaystate-Informationen identifiziert Zustandsinformationen. Wenn die Zugriffsprüfung passiert, wird die gewünschte Ressource an den Browser zurückgegeben.

ich es glaube ein Tippfehler in Schritt 5 though. Es sollte " Verwenden Sie das Format für die persistente Namenskennung "anstelle von" transient name identifier format ".