Enabling Claims Based authentication on your ASP.NET MVC project is easy:
- Create a new ASP.NET MVC web application
- Right click on the project and choose the Identity and Access… option(if you don’t see this option, make sure that you have the Identity and Access Tool extension installed)
- Walk through the configuration wizard and… done!
But when I tried to do this on a new project, it failed with the following error:
“A claim of type 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier' or 'http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider' was not present on the provided ClaimsIdentity. To enable anti-forgery token support with claims-based authentication, please verify that the configured claims provider is providing both of these claims on the ClaimsIdentity instances it generates. If the configured claims provider instead uses a different claim type as a unique identifier, it can be configured by setting the static property AntiForgeryConfig.UniqueClaimTypeIdentifier.”
Woops! This approach has always worked for me. So something must have been changed. And indeed, I was using an ASP.NET MVC 4 project where before I was using ASP.NET MVC 3.
Using Html.AntiForgeryToken in MVC 4 has changed slightly from the previous version if you’re building a claims-aware application. In prior versions User.Identity.Name was included in the anti-forgery token as a way to validate the <form> being submitted, but in MVC 4 if the identity is IClaimsIdentity (WIF) or ClaimsIdentity (.NET 4.5) then the anti-forgery token attempts to put one or more claim values into the anti-forgery token.
The problem is which claim(s) should it use? The value needs to uniquely identifier the user, so by default MVC expects the nameidentifier and the identityprovider If you’re using the Windows AzureACS as your STS then you’re all set. If you’re not using ACS then you’ll see the same error I had.
You can solve it by telling ASP.NET MVC which claim you want to use to uniquely identify the user. You do this by setting the AntiForgeryConfig.UniqueClaimTypeIdentifier property: