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

More Info on an Old Friend - the Custom Claims Provider, Uri Parameters and EntityTypes in SharePoint 2013

More Info on an Old Friend - the Custom Claims Provider, Uri Parameters and EntityTypes in SharePoint 2013

  • Comments 1
  • Likes

Back to oldie but a goodie - the custom claims provider for SharePoint.  I believe this applies to SharePoint 2010 as well but honestly I have only tested what I'm about to describe on SharePoint 2013 and don't have the bandwidth to go back and do a 2010 test as well.  What I wanted to describe today is the values you may expect to get, and the values you actually get, in a custom claims provider method for FillClaimsForEntity, FillResolve and FillSearch.  Chances are they may not be what you expect.

  • FillClaimsForEntity - this method is invoked at login time and is used for claims augmentation.  The Uri parameter that you get ("context") will NOT tell you what site a person is authenticating into.  The value you will get back is the root of the web application zone.  So if a user is trying to get into https://www.contoso.com/sites/accounting, the value for the "context" parameter will be https://www.contoso.com.
  • FillResolve - this method has two different overrides, but both include a Uri parameter ("context").  The value you get for this parameter varies.  When you're in a site collection the Uri will be for the site collection you are in.  When you are in central admin and you are invoked when picking a site collection administrator, "it varies".  When you are first selecting a site collection administrator, the Uri value will be of the root site collection again - NOT the site collection you are trying to set the admin for.  Unfortunately, this gets a bit more convoluted yet - when you click on the OK button to save your changes, the FillResolve method will get invoked again.  This time however, the Uri value WILL BE the actual site collection Url for which you just changed the site collection admin.
  • FillSearch - this method is invoked when someone is doing a search in people picker.  It exhibits the same behavior as FillResolve above - when you're in a site collection you get the correct site collection Uri.  When you're in central admin and you are trying to search for an entity to add as a site collection admin, the value for the Uri parameter is the root site collection - NOT the site collection for which you are setting the admin.

All of the details above apply to the Uri parameter in those methods.  There's one other thing to be aware of as well however, and that's the array of entity types that are provided in these methods.  The string[] entityTypes parameter is important to understand because that lets you know what type of result (i.e. PickerEntity) you should return when FillResolve or FillSearch is invoked.  The main scenario where it matters is when you are setting the site collection administrator.  To this day, SharePoint has a limitation that only an individual user (or better stated really - only an identity claim) can be added as a site collection administrator.  What I've found is that when you are trying to set the site collection administrator and your custom claims provider is invoked from within central admin, the entityType array correctly contains only one value - SPClaimEntityTypes.User.  HOWEVER...if you are in a site collection and you try and change the site collection administrators from within it, the entityType is returning five different entity types, instead of just User.  At this point I don't know of a good way to distinguish that from a legitimate request within the site collection where all of those entity types would be appropriate - such as when you're adding a user / claim to a SharePoint group or permission level.

I don't know if or how much any of this may change in the future (i.e. are they considered bugs or not), so for now I just wanted to document the behavior so as you're creating your designs around your farm implementations you know better exactly what info you'll have within your custom claims provider to help make fine grained security decisions.

Comments
  • Thanks.
    So we could distinguish intranet and extranet Zone and augment Claims differently... authorize access based on the Zone.

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