Getting the normal domain username from the claims username in SharePoint 2013

ntroduction to the problem

It’s not uncommon when upgrading to SharePoint 2013 from a previous version of SharePoint that you’ll get encoded claims usernames in the places you may have seen normal usernames (DOMAIN\Username) syntaxes before. In my case it was a matter of finding a ton of custom code and have it check whether the username was a claims encoded username or not.

This is what we saw:

i:0#.w|POINTBIRD\tobiaszimmergren

view rawClaims username hosted with  by GitHub

However, what we really wanted our code to output was this:

POINTBIRD\tobiaszimmergren

view rawDomain username hosted with  by GitHub

There’s a good reason for why the username that is claims encoded look the way it does. The format tells us what type of claim it is. Wictor has done a nice breakdown and explained the claims here: http://www.wictorwilen.se/Post/How-Claims-encoding-works-in-SharePoint-2010.aspx

The solution to this problem

There’s a pretty simple solution for this that it looks like a lot of people are missing out on. The code snippets I’ve seen in the last project are all parsing the string manually with custom logic and then trying to determine on a string.split() if it is a claim and what type of claim it is.

Instead of going down that dark and horrible road, you should take a look at the built-in functions in the API that does this just fine for us:

	private string GetUsernameFromClaim(string claimsEncodedUsername)
	{
	using (new SPMonitoredScope("GetUsernameFromClaim method start"))
	{
	try
	{
	SPClaimProviderManager spClaimProviderManager = SPClaimProviderManager.Local;
	if (spClaimProviderManager != null)
	{
	if (SPClaimProviderManager.IsEncodedClaim(claimsEncodedUsername))
	{
	// return the normal domain/username without any claims identification data
	return spClaimProviderManager.ConvertClaimToIdentifier(claimsEncodedUsername);
	}
	}
	}
	catch (Exception ex)
	{
	// You should handle any exceptions in here instead of ignoring them!
	// Logger.Log("An exception occured in the GetUsernameFromClaim() method");
	return claimsUsername; // Or just return the original username.
	}
	// Return the original username value if it couldn't be resolved as a claims username
	return claimsUsername;
	}
	}

view rawSPClaimsHelper.cs hosted with  by GitHub

Summary

Since I saw so many places in the previous few projects where people have been referencing custom methods for string-splits to sort out the claims usernames into default domain\username formats, I thought you’d benefit from knowing that there’s a built-in method for that. Nothing fancy, but worth to know about it.

Programmatically converting login name to claim and vice versa

SharePoint 2010 introduced Claims Based Authentication. One of the consequences of this is the fact that in order to use Forms Based Authentication (FBA) you need to configure your Web Application to use Claims instead of Classic Authentication. One of the many changes that you notice while working with claims are different login names: while in SharePoint 2007 you used something like myprovider:myuser, SharePoint 2010 makes the claims-soup of it: i:0#.f|myprovider|myuser. And while this is something you can take into account for newly created solutions, it can get confusing when upgrading SharePoint 2007 solutions to SharePoint 2010, especially if all you need is the user name. So is String.Replace the only way to get it out or is there a better way?

It turns out that retrieving the user name from its claims representation is pretty straight forward and can be done using the following code snippet:

?

1 2 3 4 5 6

string userName = null; SPClaimProviderManager mgr = SPClaimProviderManager.Local; if (mgr != null) {     userName = mgr.DecodeClaim(SPContext.Current.Web.CurrentUser.LoginName).Value; }

First we retrieve a reference to the Claims Provider Manager configured with the current Web Application. Then, using the DecodeClaim(string) method, we convert the string into SPClaim and retrieve its value, which contains the login name of the current user.

So, assuming you were logged in with the myuser account and the value of the SPContext.Current.Web.CurrentUser.LoginName property was something similar to i:0#.f|myprovider|myuser, calling the code snippet above would return myuser.

Claims back and forth

In some scenario’s you might want to do the exact opposite: you might be starting off with a login name and will need to turn it over into the claims-based name. Just like in the previous scenario this can be easily done using the SPClaimProviderManager:

?

1 2 3 4 5 6 7

string userName = null; SPClaimProviderManager mgr = SPClaimProviderManager.Local; if (mgr != null) {     SPClaim claim = new SPClaim(SPClaimTypes.UserLogonName, "myuser", "http://www.w3.org/2001/XMLSchema#string", SPOriginalIssuers.Format(SPOriginalIssuerType.Forms, "myprovider"));     userName = mgr.EncodeClaim(claim); }

Just as in the previous example we start off by getting a reference to the current Claims Provider Manager. The next step is to create a claim based on the login name of the current user. You can do this using the constructor of the SPClaim class. As the type you have to provide SPClaimTypes.UserLogonName, as the value – the login name of the user, as the value type, the XML type for string and finally, as the originalIssuer the name of your Membership Provider. In this sample I used a custom Forms Based Membership Provider but you might need some other type depending on your scenario.

In our example, if you needed the claims representation for the the myuserclaims account, calling the above code snippet would returni:0#.f|myprovider|myuser.

And that’s it: converting the login names to claims and vice versa is that simple. And using the DecodeClaim and EncodeClaim methods makes it more reliable than parsing or building the strings manually.