Partager via

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.

Comments

  • Anonymous
    January 01, 2003
    I seem to remember that there was a Search Service (PowersShell) only setting/property that controls how the security trimming is stored ( force claims ). But cannot seem to find it anymore on the web. Do you know of this?

  • Anonymous
    January 01, 2003
    thanks

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    June 03, 2010
    Hello, Can you help me? I tried to create a provider like your. I have a problem with compile this piece of code. protected override void FillSearch(System.Uri context, string[] entityTypes, string searchPattern, string hierarchyNodeID, int maxCount, SPProviderHierarchyTree searchTree) { . . matchNode = searchTree.Children.Where(....... } Error message: 'System.Array' does not contain a definition for 'Where' and no extension method 'Where' accepting a first argument of type 'System.Array' could be found (are you missing a using directive or an assembly reference?) Pls, Help me!!!! R

  • Anonymous
    November 30, 2011
    Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh Huh

  • Anonymous
    August 09, 2012
    The comment has been removed

  • Anonymous
    August 29, 2012
    @Sven: brilliant idea to use reflection here. Thanks!