Windows Azure Active Directory Authentication: User Principal Name is Suddenly Null

Last week, after I had already written my guide on setting up your ASP.NET MVC web application to use WAAD authentication, Microsoft changed the configuration of WAAD in a way that broke my demo application: logging in worked, but the user principal had “null” for its name.

After looking into the problem for a moment, I realized that the application was configured to expect an email address claim from the identity provider. The configuration is in web.config:

<add type="System.IdentityModel.Tokens.Saml2SecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
	<samlSecurityTokenRequirement>
		<nameClaimType value="http://schemas.xmlsoap.org/claims/EmailAddress" />
	</samlSecurityTokenRequirement>
</add>

This configuration says that the thing that names our user principal is the email address claim. After the update, we no longer get that claim, so the configuration needs to change to this:

<add type="System.IdentityModel.Tokens.Saml2SecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
	<samlSecurityTokenRequirement>
		<nameClaimType value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" />
	</samlSecurityTokenRequirement>
</add>

This does make more sense: the new claim is a “upn” or “user principal name”, which makes sense because, well… it’s the name of our user principal.

After this change, you’ll also want to add this line somewhere, most likely your Application_Start event handler:

AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Upn;

This ensures that your anti-forgery tokens keep functioning.

What sucks about this is that I didn’t receive any kind of notification about the change. I hope this helps someone avoid the headache of debugging through the issue. Smile

Leave a Reply

Your email address will not be published. Required fields are marked *