Handling claims transformation in an OWIN middleware in .NET MVC part 2

In the previous post we laid the foundations for this short series. We went through a refresher of claims and OWIN and started building a simple ASP.NET MVC web project to investigate what’s available about the user of the current thread in a controller. We saw that by default the only claim available about a user might be their name, unless they are anonymous of course.

In this post we’ll continue to explore claims of authenticated users.

Authenticated users and their default claims

We can easily check how the output of the code we tested in the previous part changes for authenticated users. Open the demo web app and start it in Visual Studio. Use the Register link in the top right hand corner to register a user and log in automatically. Check the Debug window when you are redirected to the home page. You’ll see something along these lines:

I’m building the demo in Visual Studio 2013 but 2012 and 2015 may give different results. Let’s see what each claim means in turn:

nameidentifier: this is the unique identifier of the user in the current system. Where is it coming from? The project saved the user in an SQL table. Below you’ll find a description how to find it.

name: this is the user name. I had to provide an email address as the user name on the registration page and it was set as my name claim

identityprovider: ASP.NET Identity is the successor of the well-know and by now outdated ASP.NET Membership provider. You can find more details about Identity here.

SecurityStamp: this is the most difficult one to figure out. I’ve found a useful thread on StackOverflow available here. Here comes a quote from that thread: “So this is basically meant to represent the current snapshot of your user’s credentials. So if nothing changes, the stamp will stay the same. But if the user’s password is changed, or a login is removed (unlink your google/fb account), the stamp will change. This is needed for things like automatically signing users/rejecting old cookies when this occurs, which is a feature that’s coming in 2.0.“

As promised let’s see where to find the user name and user identifier claims. The default ASP.NET Identity mechanism will set up the user and membership related tables for you when the first user is registered. The tables look somewhat like the ones that the old Membership mechanism created but they are more streamlined now.

Click the Show All Files icon in the Solution Explorer and expand the App_Data folder. You’ll find the .mdf file there:

If you double-click the .mdf file the database will open in the Server Explorer window. Open the Tables folder of the DefaultConnection node, right-click the AspNetUsers table and click Show Table Data:

The Id column will hold the name identifier claim. There’s also a UserName column all the way to the right which holds the name claim.

A side note: if you’d like to know more about the new Identify framework in ASP.NET MVC5 I have an intro series on that topic starting here.

So now we know what kind of claims are available by default in an ASP.NET MVC5 project. It is possible that the above set of claims will be enough for you in your web project. However, most often than not you’ll want to dig further and find other types of claims in the database and/or suppress some of the existing ones. E.g. you might not need to know the identity provider claim.

Starting with claims transformation

We’re given an initial set of claims and we’d like to build a custom-made one, a list that only contains the claims that we’re interested in. As mentioned before the MVC5 template already includes a lot of security-related infrastructure. In fact if you add a couple of claims into the AspNetUserClaims table in the mdf database mentioned above those will be automatically retrieved for you when a user logs in, i.e. they will be visible in the…

IEnumerable<Claim> claimsCollection = claimsPrincipal.Claims;

…variable. However, for educational purposes we’ll see how to achieve something similar manually. This process helps you understand claims and OWIN better.

Add a new folder called ClaimsTransformation to the project. Insert a class called ClaimsTransformationService into it:

We first check whether the user ID is available among the initial claims. That indicates that the user is authenticated. If it’s not available then we simply return the incoming list of claims. Otherwise we add a couple of custom claims that we’re pretending to get from a data store. Those could in reality come from a web service, the Amazon file storage, MongoDb, what have you. Also, this is where you can remove some unnecessary claims from the incoming list. Here we simply keep the original list and extend it with some custom-made ones.

Let’s test this service from HomeController with the following modifications:

Start the application and the new service code should be invoked. Make sure you first test the home page without logging in. You’ll see that we have a single claim after the transformation which is expected: