0

Section 8.3.7 of the SAML Core Specification states that the persistent nameID format is used for privacy protection:

Persistent identifiers are intended as a privacy protection mechanism; as such they MUST NOT be shared in clear text with providers other than the providers that have established the shared identifier. Furthermore, they MUST NOT appear in log files or similar locations without appropriate controls and protections.

I'm not certain that I understand the intent behind the use of persistent identifiers as a privacy protection mechanism - particularly in light of the fact that most of the other NameID types (email, SN, qualified name, kerb principal, etc.) will be the same across all SP's.

How is the unique NameID per-SP a 'privacy protection mechanism'? Specifically, what attack vectors would be mitigated by the use of a persistent NameID field over another type (particularly when protections like correct audience restrictions and signatures are in place)?

josh-cain
  • 4,997
  • 7
  • 35
  • 55

1 Answers1

-1

It is a privacy protection mechanism because it doesn't transfer your real identifier from the IdP to the SP. Meanwhile, the Email NameID type, for example, transfers your email from the IdP to the SP.

One online resource that I can find which explains this pretty good is http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html section 5.4.3 Federation Using Persistent Pseudonym Identifiers.

The processing is as follows:

  1. The user attempts to access a resource on cars.example.co.uk. The user does not have any current logon session (i.e. security context) on this site, and is unknown to it. The resource that the user attempted to access is saved as RelayState information.

  2. The service provider uses the HTTP Redirect Binding to send the user to the Single Sign-On Service at the identity provider (airline.example.com). The HTTP redirect includes a SAML message requesting that the identity provider provide an assertion using a persistent name identifier for the user. As the service provider desires the IdP have the flexibility to generate a new identifiier for the user should one not already exist, the SP sets the AllowCreate attribute on the NameIDPolicy element to 'true”.

  3. The user will be challenged to provide valid credentials.
  4. The user provides valid credentials identifying himself as john and a local security context is created for the user at the IdP.
  5. The Single Sign-On Service looks up user john in its identity store and, seeing that the AllowCreate attribute allows it to, creates a persistent name identifier (61611) to be used for the session at the service provider. It then builds a signed SAML web SSO assertion where the subject uses a transient name identifier format. The name john is not contained anywhere in the assertion. Note that depending on the partner agreements, the assertion might also contain an attribute statement describing identity attributes about the user (e.g. their membership level).
  6. The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the service provider's Assertion Consumer Service.
  7. The cars.example.co.uk service provider's Assertion Consumer service validates the digital signature on the SAML Response and validates the SAML assertion. The supplied name identifier is then used to determine whether a previous federation has been established. If a previous federation has been established (because the name identifier maps to a local account) then go to step 9. If no federation exists for the persistent identifier in the assertion, then the SP needs to determine the local identity to which it should be assigned. The user will be challenged to provide local credentials at the SP. Optionally the user might first be asked whether he would like to federate the two accounts.
  8. The user provides valid credentials and identifies his account at the SP as jdoe. The persistent name identifier is then stored and registered with the jdoe account along with the name of the identity provider that created the name identifier.
  9. A local logon session is created for user jdoe and an access check is then made to establish whether the user jdoe has the correct authorization to access the desired resource at the cars.example.co.uk web site (the resource URL was retrieved from state information identified by the RelayState information. If the access check passes, the desired resource is returned to the browser.

I do think there is a typo at step 5 though. It should be "use persistent name identifier format" instead of "use transient name identifier format".

Thuan
  • 1,618
  • 1
  • 10
  • 21
  • ok... These identifiers can be used outside of federation flows (per the example you gave me), and I wasn't really asking how the flow works. Instead, I was asking specifically about the security concerns and attack vectors. It seems like your response postulates that the sole purpose of the privacy protection mechanism that the spec speaks of is confidentiality. Can you give some reasoning/examples as to why this is important? For instance, are there any attack vectors available when using a shared identifier across SP's? – josh-cain Jan 04 '17 at 18:50
  • I answered using the flow because I hoped it was clear enough to understand the role of using it to protect *privacy*. How does it help? For example, you trust StackOverflow and provide it your name which is Josh. Then you want to use StackOverflow as an IdP to login to another SP. By using persistent identifier, you can guarantee a few things: – Thuan Jan 05 '17 at 03:02
  • 1. The token returning to the SP doesn't contain your real identity. If the token is leaked, an attacker can't tell it is from you. 2. The SP doesn't know your real identity. This reduce the chance the can abuse your SO identity. 3. If the SP site is compromised, it makes it harder for the attacker to know what your SO identity actually is. That's all I can add based on my own experience on this matter :) – Thuan Jan 05 '17 at 03:08
  • Thanks for clarifying. I suppose I'm still at a loss as to how these points are helpful. Let me explain a bit on each point: 1. If the token is leaked, most assertions are going to contain some form of identifying information anway. Even if the token doesn't, how could an attacker 'abuse' your SO identity with an identifier? Our usernames are published on our profile and are commonly considered as somewhat public information. Why is this identifier treated differently? – josh-cain Jan 05 '17 at 17:58
  • Same goes for 2. & 3. - what forms of 'abuse' do you have in mind? Also, what sort of compromise are you speaking of in 3. ? If an IDP or SP is compromised I can think of alot bigger problems than a revealed link identifier... – josh-cain Jan 05 '17 at 18:00