More Information on Adding and Changing Custom Claims Providers in SharePoint 2010

  • Article

This is a topic that continues to generate swirl, because as soon as you make one change you may want to make another or remove a change you made. I've blogged about this topic before: https://blogs.technet.com/speschka/archive/2010/04/28/how-to-override-the-default-name-resolution-and-claims-provider-in-sharepoint-2010.aspx and https://blogs.technet.com/b/speschka/archive/2010/05/25/replacing-the-out-of-box-name-resolution-in-sharepoint-2010-part-2.aspx. I thought I'd try to summarize and add a few final thoughts here. So here are the main scenarios that I current think are interesting.

$trusted = Get-SPTrustedIdentityTokenIssuer -Identity "Trusted Login Provider Name Goes Here"
$trusted.ClaimProviderName = “name of your custom claim provider” //in your claim provider you need to override the SPClaimProvider.Name; use that value here
$trusted.Update()

  • I want to update a custom claims provider I developed: this is just the more common case where I've written a custom provider, and now I've made changes to it (bug fixes, changes in functionality, etc.). In that case you do something like this:

1. Re-add the assembly to the GAC. I usually remove it and add it again, but doing both isn't necessarily required..
2. Reset IIS

  • I've configured my SPTrustedIdentityTokenIssuer to use my custom claims provider as the default provider, but now I want to remove it and use the out of the box claims provider.  This one is unfortunately more difficult - there isn't a direct way to change it back.  So you have to go through this process:

1. Change your web apps to no longer use the SPTrustedIdentityTokenIssuer. For example, change them to use Windows claims.
2. Delete the SPTrustedIdentityTokenIssuer.
3. Create a new SPTrustedIdentityTokenIssuer with the same settings, only don't configure it to use your custom claims provider as the default provider.
4. Reconfigure your web apps to use the recreated SPTrustedIdentityTokenIssuer.

The takeaway from this last point is that you want to make sure you wrap up your steps for creating a new SPTrustedIdentityTokenIssuer into a PowerShell cmdlet that you can re-run as needed.

Those are the basic options and steps. Hopefully this topic is covered sufficiently now.