Replacing the out of box Name Resolution in SharePoint 2010 – Part 2

A while ago I posted an entry on how to configure your custom claims provider to replace the out of the box claims provider (http://blogs.technet.com/speschka/archive/2010/04/28/how-to-override-the-default-name-resolution-and-claims-provider-in-sharepoint-2010.aspx).  I wanted / need to follow up on that posting, because we found some additional details that you will want to have in hand should you go down this route.  If you don’t follow these steps, you may find that the claims you resolve in the search dialog or type-in control don’t map to the account name or other claim that someone logs in with.  For some of the reasons why you might want to replace the out of the box provider, see the original blog posting I’ve linked to above.

Now, if you want to replace the out of the box provider and have the account names and claims match what is actually used at login time, there are some additional steps and information you need to be aware of.  Here is a quick checklist of rules that I’ve come up with to ensure that my custom claims provider can successfully supplant the out of  the box provider.  These rules do not cover every type of claims provider scenario – they are the minimum that need to be implemented for this replacement scenario.

IMPORTANT UPDATE – Hi all, I just found out that a few of the methods below changed from when this post was written and when the RTM code was delivered.  I have updated this post with the latest info, that I have recently re-verified and have working. 

1.       The ClaimProviderName of the Get-SPTrustedIdentityTokenIssuer should be the Name of the custom claims provider.  Instructions for how to configure this are at http://blogs.technet.com/speschka/archive/2010/04/28/how-to-override-the-default-name-resolution-and-claims-provider-in-sharepoint-2010.aspx.

2.       Make sure that the Name property of your custom provider is NOT the same value as the Name property of the Get-SPTrustedIdentityTokenIssuer.  You will need the name of the SPTrustedIdentityTokenIssuer when you are creating the claim for the PickerEntity, so I recommend you add another static string property to your custom claim provder that is the name of the SPTrustedIdentityTokenIssuer.  For example, here’s what I used in my custom claim provider:

        internal static string SPTrustedIdentityTokenIssuerName

        {

            get

            {

                return “ADFS with Roles”;

            }

        }

 

3.       When you create a custom claim provider to replace the out of box provider, you are going to want to override the FillSearch and FillResolve methods.  In those overrides you will need to create a PickerEntry instance.  Normally for these methods I use the CreateClaim helper method; however, if your provider is going to replace the out of the box provider you do not want to use the CreateClaim helper.  Instead you should:

a.       Use the new SPClaim constructor.

b.      Determine if the claim is an identity claim or not.  For example, if the identity claim for the SPTrustedIdentityTokenIssuer is email, then you know that if the claim value is an email address it is an identity claim.

c.       For an identity claim, the claimType for the new SPClaim constructor should match the identity claim for your SPTrustedIdentityTokenIssuer.  For example, if your identity claim is email, then your claimType parameter should be http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

i.         For an identity claim, the EntityType property of the PickerEntity should be SPClaimEntityTypes.User

d.      If it is NOT an identity claim, the claimType should be whatever claim makes sense for your application

i.         If it is NOT an identity claim, the EntityType property of the PickerEntity should be SPClaimEntityType.WhateverMakesSenseForYourApplication (probably FormsRole in many cases)

e.      For the last parameter of the new SPClaim constructor, use the following:  SPOriginalIssuers.Format(SPOriginalIssuerType.TrustedProvider, SPTrustedIdentityTokenIssuerName)

f.        Here’s an example of an identity claim with all of these pieces put together: 

myPickerEntity.Claim = new SPClaim(“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”, “speschka@microsoft.com”, Microsoft.IdentityModel.Claims.ClaimValueTypes.String, SPOriginalIssuers.Format(SPOriginalIssuerType.TrustedProvider, SPTrustedIdentityTokenIssuerName));

IMPORTANT NOTE:  If you are the default claims provider for an SPTrustedIdentityTokenIssuer, you should use this method to create the PickerEntity claim irrespective of the type of claim; meaning, use this method whether it’s an identity claim, role claim, etc.

So the key takeaways from this should be:

1.       Add a new property to your claim provider that is the name of the SPTrustedIdentityTokenIssuer where the provider will be used.

2.       When you are resolving an identity claim, make sure the EntityType is SPClaimEntityTypes.User

3.       Don’t use the CreateClaim helper method; use the new constructor for an SPClaim

4.       For the last parameter of the SPClaim constructor, use the SPOriginalIssuerType enum.

I’ve tested this in my environment and have it working successfully, and I’ve also worked with one of our MVP’s who was able to make it work for his customer following this same set of rules.

2 thoughts on “Replacing the out of box Name Resolution in SharePoint 2010 – Part 2

  1. Could you please explain why the people picker implements an overridable class instead of simply validating user ID’s with the users in the UPS store?

    When you create a Trusted Login Provider (TLP) it adds external users to the UPS store in the same way a UPS sync adds AD users to the UPS store. So why is a CCP needed at all?

    Given that you are not interested in implementing role based claims, all you want to do it have the people picker recognise external users in the UPS that have been added by the TLP, why does the people picker fail to validate these users when they exist in the UPS store just like AD users do?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s