Share-n-dipity

SharePoint serendipity is the effect by which one accidentally discovers something fortunate, especially while looking for something else entirely. In this case, it is the occassional musings, observations, and Ouija board readings about the phabulously

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

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

  • Comments 13
  • Likes

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.

Comments
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment