Tag: custom claims

SharePoint & Custom Claims when consuming service applications

Wictor Wilen has two great blogs out there that discuss the claim type encoding and a lot of the information I’ve gathered is from those blogs.

These were written for 2010 but a lot of it still applies. In fact, 99% of it still applies to 2013, and 2016. I can imagine the same will be for 2019.

http://www.wictorwilen.se/Post/How-Claims-encoding-works-in-SharePoint-2010.aspx

http://www.wictorwilen.se/introducing-the-sharepoint-2010-get-spclaimtypeencoding-and-new-spclaimtypeencoding-cmdlets

Consider the following configuration:

We have two farms configured. One farm is an Enterprise Services farm publishing service applications like Managed Metadata, User Profile Services, and Search. The other farm is the consuming farm or Content Farm. The consuming farm is authenticated via custom Claims from a third-party Identity provider like SiteMinder or Ping. When we are performing a search, we are getting no results returned when we are expecting to get many search results. When we are logged in with our windows account and not SAML we get results without issue.

  • Customer is logged in as: i:0g.t|siteminder|b0000001
  • Claim added to query: c:0?.t|siteminder|b0000001

For those of you who do not wish to read the whole blog the following two points are the cause of the issue

  • The underlying cause of this issue is due to custom claims and claim type encoding between the two farms.
  • In order to use custom claims between two or more farms their claim type encoding character must be the same between all the farms

But let’s walk through this a little so we know how to troubleshoot this

  • To begin troubleshooting this issue we must know what claim types our farm knows about, and what is the associated Encoding Character.
  • We simply run the following PowerShell command
  • This will give you the following output: (Example from SharePoint 2016)

    This will convert the encoding character to a more manageable value

  • Get-SPClaimTypeEncoding | ft @{Label=”Character”;Expression={[Convert]::ToInt32($_.EncodingCharacter)}}, ClaimType | ft -autosize

    New-SPClaimTypeEncoding

  • Using the New-SPClaimTypeEncoding cmdlet we can add our own claim types and use our own encoding character.
  • The cmdlet takes two arguments the -EncodingCharacter which is the encoded value and the -ClaimType.
    • New-SPClaimTypeEncoding -EncodingCharacter ([Convert]::ToChar(513)) -ClaimType “urn:another-claim-type” -Confirm:$false

  • If you get an Argument Exception, it can be for many different reasons.
    • Make sure that your encoding character is not currently in use.
    • Make sure you’re starting above 500 for your encoding character.
    • We cannot use upper case characters or white space characters.

    Note:

    • The use of the encoding character is the most important part here. We must use an encoding character that is not currently in use in the publishing farm or the consuming farm.
    • This is crucial because you can’t remove a custom claim once added so the encoding character cannot be reused.
    • This encoding character must be the same between farms for our custom claims.
      • If they are not, then when we go to match our custom claim type to our known claim types by the encoding character they will not match up and we will get security trimmed or access denied as the result.

    Clarification:

  • Publishing farm has custom claim “customID” with a claim type of http://somecustomclaim/claims/customID using encoding character 509.

  • Consuming farm has the same custom claim “customID” with a claim type of http://somecustomclaim/claims/customID but it’s using encoding character 505.

  • Between farms this “customID” claim is not the same claim even though they have the same claim name and claim type.
  • Since we map our claim type to our known claims list by the encoding character and not by claim type, or name, these would be treated as two different claims using the same claim name and claim type.

    So, the real question now is how do we fix this??

    Well since you can’t remove a claim once it’s been added

    And you can’t add a claim type if it already exists

    The only tangible way to fix this is to do one of two things

    • Rebuild the farm and add the claim type with the correct encoding character
    • Use a different OOTB claim or custom claim that has the same encoding character between farms

    Rebuilding the farm is straightforward, but what if that’s not an option and you can’t change the incoming claim type sent from the third-party identity provider on the consuming farm?

    • Well I suppose you can use SharePoint to transform the incoming claim type to a different claim type. Perhaps one that exists in the enterprise services farm.
      • I would suggest using an out of the box claim type and not a custom claim type.
    • This process would be done on the consuming farm and it would be done on the trusted identity provider.
    • The easiest way to accomplish this is when create our trusted identity provider when we are creating our claim mappings.
    • I won’t go into detail on how to add a trusted identity token issuer, or how to add a claim mapping to an existing trusted identity token issuer as that is outside the scope of this article. However, the claim mapping would look something like this where we take the incoming claim of “customID” and transform the claim to UPN. Since this is an out of the box claim and if we have permission to resources via the UPN claim type search results will start displaying proper results.