The Name claim: sometimes it’s the simple things

In short: we just updated the list of claims we issue from Windows Azure AD to provide the UPN of the user (“user@domain”) in the Name claim (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name).

If it is present, WIF automatically assigns the value of the Name claim to the Name property of the Principal in the current thread.
Why is that different from any other claims? Well, the Name property comes from the IPrincipal interface, which pre-dates claims support in .NET by many years. There’s a lot of existing code (ASP.NET templates, components, etc) which rely solely on IPrincipal for things such as displaying the name of the current user, keying profile stores, and similar. Therefore, issuing the Name claim means that all of that existing code relying on the Name property will work seamlessly out of the box, without the need for you to create explicit mappings between an arbitrary claim type and the Name property.

Why did we pick the UPN as the value for the Name claim? Well, mostly because it is both human-readable (hence it works well when displayed) and unique within a tenant (hence it can be used for things like anti-forgery or existing code keying things per user).

Please note: the UPN is a decent compromise to meet the requirements of the overloaded semantic of the Name property of IPrincipal, and the ocean of existing code relying on it. However, it would be much cleaner to separate the “user display” and the user identification functions. For example: the UPN is not a perfect user identifier. It is unique, which is useful, but it is non-immutable: that means that on occasions the same value can be reassigned to different people in the org, though that typically happens fairly rarely (say that your UPN is bob@contoso.com; say that a new VP comes on board, his name is Robert, and he really wants the 3-letters alias; your admin reassigns bob@contoso.com to the VP. If Web applications used the UPN to key a local profile, and assuming that the VP is also a user there, now the VP will have access to your local profile).
A really good identifier would be unique and immutable, but also very likely not very human readable. There’s not much that can be done for existing code, but moving forward you’ll see more guidance on how to handle identifiers and the like.

For the time being, I hope you’ll enjoy the name of your Windows Azure AD users showing up on your pages straight from the template