Intro to Identity Claim-based Authentication

What is i:0#.w|

If you’re here, you wondering “what is i:0#.w|”? This is a identity claim authentication encoding. It’s used by websites to determine where a claim based authentication is used. It’s main purpose is security access control lists (ACL) and an application needs code to support the method. Earlier Forms Based Authentication and LDAP are early predecessors and is incorporated into claim-based authentication methods.

Typically seen in SharePoint sites but other applications using the .NET technology also use the same encoding. There are several popular identity claim authentication frameworks. Not all frameworks support all functions of claim-based Identity but here is a small list:

• Active Directory Federation Services
• OAuth v2
• Security Assertion Markup Language (SAML) v2
• WS-Federation

What is a Claim-Based Identity

A secure application needs to satisfy at least two of these four common goals.

• Authentication: “Who are you?”
• Authorization: “Are you allowed to do this?”
• Personalization: “How can I personalize your experience?”
• Information sharing: “Can you view this data?”

A claim-based identity framework can support one or more of the four goals.

There are several terms used to describe Identity Claim authentications, but they are all the same. Claims-based identity isn’t new. It’s been being designed and implemented from the early 2000’s but has become popular with the rise of cloud based deployments.

Some of the more popular terms that are used when talking about Identity Claims :

• Claim-based Authentication (CBA)
• Identity Claim(s)
• Federated Identity or Federated Identity Claim(s)
• Claim Token(s) or Claim-based Token(s)

Several authentication methods have been incorporating claims methods into their standard for example, Kerberos, LDAP, WS-Federation, SAML, as well as others.

What’s the purpose

The purpose is a better architecture for identity in applications. The idea is to simplify security claims across various systems and organizations while allowing multiple systems to add claims in a security token.

A security token can have multiple claims about a user in an application. This allows for a robust authentication system. For example in a school system for a K-12, a student’s security token could contain clams for each class they’re taking, their email, who their parents are, the year they graduate, or any other claim needed to satisfy the applications needs.

Azure services and Office356 are examples of blending on-premise with cloud based services. Social logins and social account linking are other examples.

Decoding the encoding

Microsoft .NET uses this basic format of the encoding:

<IdentityClaim>:0<ClaimType><ClaimValueType><AuthMode>|<OriginalIssuer (optional)>|<ClaimValue>

Several other claim systems use this format as well.

<IdentityClaim>

<IdentityClaim> indicates the type of claim and is the following:

• “i” for an identity claim
• “c” for any other claim

<ClaimType>

<ClaimType> indicates the format for the claim value and is the following:

• “#” for a user logon name
• “.” for  an anonymous user
• “5” for an email address
• “!” for an identity provider
• “+” for a Group security identifier (SID)
• “–“ for a role, typically the friendly name of the security group ACL
• “%” for a farm ID
• “?” for a name identifier
• “\” for a private personal identifier (PPID)
• “e” for a user principal name (UPN)
• ““” double-quote for a user ID
• “$” for a distribution list security identifier (SID)
• “&” for a process identity security identifier (SID)
• “‘” single-quote for a process identity logon name
• “(” for an authenticated user
• “)” for a primary security identifier (SID)
• “*” for a primary group security identifier (SID)
• “0” for an authorization decision
• “1” for a country
• “2” for a date of birth
• “3” for a deny only security identifier (SID)
• “4” for DNS
• “5” for an email address
• “6” for a gender
• “7” for a given name
• “8” for a hash
• “9” for a home phone
• “<” for a locality
• “=” for a mobile phone
• “>” for a name
• “@” for other phone
• “[” for a postal code
• “]” for RSA
• “^” for a secure identifier (SID)
• “_” for a service principal name (SPN)
• “`” for a state or province
• “a” for a street address
• “b” for a surname
• “c” for a system
• “d” for a thumbprint
• “f” for a uniform resource name (URI)
• “g” for a web page

Custom Claim Providers

Additional custom claim types can be encoded for a application. Custom claim types get generated ID by starting with the value 500 and adding 1 for the first custom claim type, each additional custom claim type then adds 1 to the ID. This results in ǵ (0x01F5) being the first custom claim registration because 501 translates to 0x01F5 and in the UNICODE table that’s the “ǵ” character.

It is important to remember that custom claims types are not uniform between SharePoint Farms or other applications. You must make sure that custom claim types are added in the same order across different systems or your authentication claims will fail.

<ClaimValueType>

<ClaimValueType> indicates the type of formatting for the claim value and is the following:

• “.” for a string
• “+” for an RFC 822-formatted name
• “)”  for an integer
• ““” for a Boolean
• “#” for a date
• “$” for a date with time
• “&” for a double
• “!” for a Base64 formatted binary
• “0” for a X.500 formatted name

<AuthMode>

<AuthMode> indicates the type of authentication used to obtain the identity claim and is the following:

• “w” for Windows claims (no original issuer)
• “s” for the local SharePoint security token service (STS) (no original issuer)
• “t” for a trusted issuer
• “m” for a membership issuer
• “r” for a role provider issuer
• “f” for forms-based authentication
• “c” for a claim provider

<OriginalIssuer>

<OriginalIssuer> indicates the original issuer of the claim and is typically a alphanumeric string value. Only used when AuthMode uses “t”. This allows for a trust be passed from an outside source aka the Original Issuer.

<ClaimValueType>

<ClaimValueType> indicates the value of the claim in the <ClaimType> format. and is typically an alphanumeric string value with limited support for symbols. It is possible to pass encode values for non-supported characters.

Examples

Type of claim	Encoded claim	Claim encoding breakdown
Windows User	i:0#.w|contoso\bgates	“i” for an identity claim, “#” for the user logon name format for the claim value, “.” for a string value, “w” for Windows claims, “contoso\bgates” for the identity claim value (aka the Windows account name)
Windows Authenticated Users group	c:0!.s|windows	“c” for a claim other than identity, “!” for an identity provider, “.” for a string, “s” for the local SharePoint STS, “windows” for the Windows Authenticated Users group
Active Directory Users group with SID	c:0+.w|s-1-2-34-1234567890-1234567890-1234567890-1234	“c” for a claim other than identity, “+” for Group security identifier, “.” for a string, “w” for Windows claims, “s-1-2-34-123…” for the Active Directory Users group SID
Federated Auth with email	i:05.t|Azure|bgates@microsoft.com	“i” for identity claim, “5” for email address, “.” for a string, “t” for trusted provider, “Azure” for the original issuer, “bgates@…” for the email address string value.
Federated Auth with a Role claim	c:0-.t|Azure|My Role	“c:” for a claim other than identity, “-” for a role, “.” for a string value, “t” for a trusted provider, “Azure” for the original issuer, “My role” for the role.
Custom ADFS claim provider	i:0ǵ.t|custom-adfs|First.Last	“i” for an identity claim, “ǵ” for custom claim provider (see the information on custom claims providers above), “.” for a string, “t” for a trusted issuer, “custom-adfs” identifies the original issuer of the identity claim, “First.Last” for the identity claim value
SAML authentication (Trusted User)	i:05.t|adfs|bgates@contoso.com	“i” for an identity claim, “5” for the email address format for the claim value, “.” for a string, “t” for a trusted issuer, “adfs” identifies the original issuer of the identity claim, “bgates@contoso.com” for the identity claim value
Forms-based authentication	i:0#.f|mymembershipprovider|bgates	“i” for an identity claim, “#”for the user logon name format for the claim value, “.” for string, “f” for forms-based authentication, “mymembershipprovider” identifies the original issuer of the identity claim, “bgates” for the user logon name

Troubleshooting

PowerShell and Claim-based authentication.

Using PowerShell doesn’t pass the claim-based encoding without help. You can not just pass the DOMAIN\USERNAME string without encoding it. For example in a SharePoint PowerShell script:

$claim = New-SPClaimsPrincipal -Identity conteso\bgates -IdentityType WindowsSamAccountName
$foo.EnsureUser($claim.ToEncodedString());

Reference

• https://archive.codeplex.com/?p=claimsid#DownloadId=246826
  • was http://claimsid.codeplex.com/releases/view/67606#DownloadId=246826
• https://en.wikipedia.org/wiki/Claims-based_identity
• https://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-20102013-claims-encoding.aspx

Further Research

• https://www.wictorwilen.se/blog/visual-guide-to-azure-access-controls-services-authentication-with-sharepoint-2010-index-post/