nWhile working with MVC application , I came across an interesting thing and got something to learn from it so thought to share.
n
n
n
n
n
n
nScenario :
n
nTypically when you implement any MVC web application , younwant to implement some security features in it and hence usenof anti-forgery token is one of the approach I was trying to implement innone of my MVC web application.
n
n
n
nHow it works?
n
nInternally how it works is , in traditional web applicationnwhich are not claims aware – it simply uses User.Identity.Name asnanti-forgery token to validate form submitted.
n
nBut when we try the same with claims aware applications– it throws an error.
n
nWhy?
n
nBecause now it tries to use the claims of type NameIdentifiernand IdentityProvider (by default).
n
n
n
nError:
n
n‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name’nwas not present on the provided ClaimsIdentity.
n
n
n
nSolution:
n
nEither your claims provider should send you the claims ofntype NameIdentifier as well as IdentityProvider , but in my case I was notnhaving both claims with me.
n
nSo I had to use the following workaround to resolventhis issue –
n
n
n
n
n
nAdd the following line in the App_Start method of thenapplication.
n
n
n
n
n
n
nAs the name suggest – it makes application aware that thenunique claim type provider is EmailAddress and not the default one.
n
n
n
n
nAfter this change , you can see then__RequestVerificationToken on the details page source information.
n
n
n
nConclusion:
n
nThis Error can be solved by letting application know that which is the claim type you want to use as unique identifier. In my case I am using EmailAddress because I had this type of claim available with me so you can also use any other claim type which your sts is providing you.
n