Name Identifiers in SAML assertions

  • [アーティクル]

In this post I will show how to setup your Relying Party Trust issuance policy to create name identifier in assertion. For AD FS 2.0 the name identifier is yet another claim but you may want to generate name identifiers if you plan to:

· Use SAML 2.0 protocol (particularly name identifier is necessary if you plan to take advantage of SAML logout protocol),

· Federate with non-AD FS 2.0 deployment.

I will show name identifier configuration on two privacy sensitive scenarios: persistent identifier, transient identifier. Persistent identifier is meant to obfuscate the real user identity, so it’s not possible to link user activities across different relying parties. At the same time the STS guarantees that persistent id will remain the same each time same the user logs in again. In SAML 2.0 assertion, it may look similar to:

<Assertion ID=”_90bd669e-4a85-412d-9969-90e43e031fac” IssueInstant=”2010-01-07T02:50:48.719Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">

  <Issuer>https://mysts/adfs/services/trust</Issuer>

  [...]

  <Subject>

    <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">zbonsm0Yn9Gnw14uQEEPr6AO7d+IvxwCQN3t+o24jYs=</NameID>

    [...]

  </Subject>

  [...]

</Assertion>

 

Transient identifier has similar properties but it’s only valid for single login session (i.e. it will be different each time the user authenticates again, but will stay the same as long as the user is authenticated).

 

Before I start I assume you already configured sample Relying Party Trust with basic policy. In case you don’t, here is some recommended reading:

· Configuring Relying Parties

· AD FS 2.0 policy language

Persistent name identifier

Step 1. Choose your Relying Party Trust and make a custom issuance transform rule to create unique user identifier claim

For the first rule we have to create advanced rule that will use custom built-in store for generating opaque identifiers. Sample rule below will use Windows Account Name Claim as a seed to generate unique identifier that will persist across all sessions.

c:[type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname" ]

=> add(

  store = "_OpaqueIdStore",

  types = ("https://mycompany/internal/persistentId"),

  query = "{0};{1};{2}",

  param = "ppid",

  param = c.Value,

  param = c.OriginalIssuer);

 

Note about technical detail: the rule that we are using is attribute extraction rule from one of the built-in attribute stores. The store takes 3 parameters: mode (“ppid”) and 2 parameters that are used as a seed for generating pseudo-random identifier. The result is also mixed with AD FS installation specific secret entropy.

 

Step 2. Transform persistent identifier claim into Name Identifier claim

 

We can use built-in rule to transform the persistent identifier claim created in Step 1 into name identifier claim (see screenshot below).

 

Transient name identifier

Step 1. Create custom rule to create per session identifier

For identifier we will use second mode of opaque store where it takes extra entropy to mix into result. In addition to Windows Account Name, we will also use authentication instant to generate identifier that will persist only for current login session.

c1:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] &&

c2:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant"]

 => add(

       store = "_OpaqueIdStore",

       types = ("https://mycompany/internal/sessionid"),

       query = "{0};{1};{2};{3};{4}",

       param = "useEntropy",

       param = c1.Value,

       param = c1.OriginalIssuer,

       param = "",

       param = c2.Value);

Note about technical detail: this time we also extract values from built-in store. This time the mode is “useEntropy” – which basically means that we will use 2 extra parameters (3rd and 4th) to additionally mix into returned identifier. Parameter 3 – is site specific entropy (empty means use relying party identifier). Parameter 4 is any other entropy - we use authentication instant.

Step 2. Transform temporary claim into Name Identifier claim

We will use similar rule as for persistent name identifier. This time we will change the format of the claim to indicate that Name Identifier will be transient.

Mieszko Matkowski

SDET, AD FS 2.0 Protocols

Comments

  • Anonymous
    February 24, 2010
    The comment has been removed
  • Anonymous
    February 24, 2010
    And more:http://ctp.social.msdn.microsoft.com/Forums/en-US/Geneva/thread/7d997b28-f8a7-4854-8ab8-2b9ef935f507http://social.msdn.microsoft.com/Forums/en/Geneva/thread/c3bbc969-02b7-43ac-8ac3-335e0a282f13
  • Anonymous
    February 02, 2012
    With the Transient Name Identifier, what URL does the incoming claim type refer to?types = ("http://mycompany/internal/sessionid"),Meaning what URL is this?
  • Anonymous
    February 04, 2013
    i'm wondering the same as none the wiser and will this help with event 362:Encountered error during federation passive sign-out.Additional DataException details:Microsoft.IdentityServer.Web.RequestFailedException: MSIS7055: Not all SAML session participants logged out properly. It is recommended to close your browser.  at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSamlLogoutResponse(HttpSamlMessage samlMessage)  at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SingleLogout(Uri returnUrl, Boolean wsFedInitiated)