Access Control Service – Why not to rely on the nameidentifier claim

Over the past week, while preparing for a migration to our production account on windows azure, I learned an important lesson that I would like to share with you, so that you don’t have to make the same mistake as I did.

The web front end, outsources authentication to various identity providers using the windows azure access control service. All of these identity providers provide a common claim that can be used to authenticate the user, being the nameidentifier claim. The value of the name identifier is unique for every user and each application. But in the scenario where there is a man in the middle, such as the access control service, this means that the value of the nameidentifier is actually unique per user per access control instance (as that is considered the application by the identity provider).

This prevents you from doing a certain number of operations with your access control service namespace as the value of the nameidentifier changes when you switch access control service instance, aka you loose your customers.

Things you can no longer provide are:

  • Migration of your namespace
  • Disaster recovery
  • High availability
  • Geographic proximity for travelling users

Therefore it’s better to correlate the user’s information with an identity on another claim, email address for example, which remains stable across different access control service instances.

The live id provider, does however not provide any additional information besides the nameidentifier, so I’m sad to report that I will have to stop supporting it!

And to make matters worse, I did not save any of the other claims. so now I have to go beg all of my users to help me upgrade their account 😦

So if you are a user of , please help me update your account:

  • For LiveId users: Login with your account, navigate to profile > identities and associate any of the other providers.
  • For Non LiveId users: Just login with your account, this will automatically fix your identity.

Thanks in advance…

11 Responses to Access Control Service – Why not to rely on the nameidentifier claim

  1. ryancrawcour says:

    really? I was under the impression that this claim was unique per Identity Provider … not per application.

    so Live user XYZ on myapplication does not equal Live user XYZ on anotherapplication?

    • Correct, nameidentitiers do not transfer from one app to the other, you will get another identifier for the same user. This is true for all identity providers btw, not just Live, but the others provide other claims that do stay stable.

  2. Alex Lazic says:

    Hi Yves,
    This is interesting that you have mentioned this – we had a similar problem in the past.
    We looked at transferring the identity claims into OpenID canonical forms, and that way avoiding issue when migrating between the name providers (we are currently using an intermediary and they provide this capability for us).
    Let me know if any further details would help.
    Kind Regards

    • Thanks, that definitly sounds interesting and something I would like to look into. Feel free to send me the details by mail (yves ad goeleven dot com) or post them here if it’s appropriate.

  3. Pingback: Windows Azure and Cloud Computing Posts for 3/9/2012+ - Windows Azure Blog

  4. Jignesh says:

    What do you mean by access control “instance”? Is it the other name for access control “namespace”?

  5. Mick says:

    Why do you need to change namespaces? Why not just add another relaying party?

    • There are many reasons:

      The most common one is an administrative change, f.e. when you switch from a paid subscription to an enterprise agreement you will have to move to another subscription & namespaces. The same thing happens when there are departemental changes in your organization (a new boss who pays f.e.) or with mergers and acquisitions.

      Secondly it happens when you want to load level your logins, every namespace has a limited capacity of logins/second that it can handle. If you have to cross this limit you will have to provision multiple namespaces.

      Another reason is geographic proximity. Namespaces are tied to a datacenter and if you want to allow americans to log in in an american datacenter and europeans in europe, you will notice that travellers will get into trouble.

  6. Mick says:

    Furthermore, I see this as a privacy feature, the less ability people have to correlate your data across different web sites the better.

    • Agree that it is a privacy feature, and initially I was happy with this as well. But the problem is that technically the relationship you build is not with the relying party, but with the namespace as well. It should have imho generated the same identifier for the same relying party instead of the combination namespace/rp.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: