First let me say that one of the things I like about blogging about random SharePoint mystery meat is the fact that I can use completely colloquial language like my blog title. Something that’s nearly impossible to get away with, unless, say, you are creating a new version of SharePoint. Anyone see the amusingly social messages in SharePoint 2013? “Sorry about the wait, I’m almost done”, and similar such things. I find it all the more amusing because it’s interspersed with things like the HRESULT my friend Tom got the other day. Hmm…the more things change, the more they stay the same.
But onto the topic at hand. I’ve mentioned oAuth a time or two in this blog already when discussing some of the new SharePoint 2013 features. And while I’m still not going to go whole hog into “what is oAuth”, because we have a whole team of writers working on that, I do want to expand again ever so slightly on some of the ways in which it is used. The best example of an oAuth trust is probably for a Remote SharePoint Index for search – that’s what allows a person in one farm to issue a query that gets routed to another SharePoint farm, and in that remote SharePoint farm it’s able to reconstruct the user’s identity so that search results can be properly security trimmed. It’s also used in other scenarios like the new app model (i.e. does this user have rights to access the content the app is requesting), between server applications like SharePoint and Exchange (does this user have rights to the mailbox content), and many others. Remote SharePoint Index is a good example to me though because I think it’s perhaps the best scenario to use to envision why we need to do the things we do in order to make this all work as expected.
So let’s start at the beginning – how can FarmA “make a Steve” that looks “Steve” on FarmB? Well it all starts with the User Profile Application. So let’s say that Steve is on FarmB and issues a query. That query gets sent over to FarmA, and along with that query are some attributes about Steve. By default, those attributes are going to be Steve’s SMTP address, SIP address, account name, and name identifier. When FarmA gets that request, the first thing it’s going to do is a lookup in its local User Profile Application; it’s going to look for a profile that matches the values for Steve that were sent over. This is why it’s so important to make sure your UPA is healthy and populated in SharePoint 2013, and why I wrote this blog article about doing that: http://blogs.technet.com/b/speschka/archive/2012/08/08/mapping-user-profiles-for-saml-users-with-an-ad-import-in-sharepoint-2013.aspx.
Okay, so now FarmA has found the Steve user profile, what can it do with that? Well the answer from here is “it depends”, and thus why it’s so important to do the planning for this aspect of your organization. The thing it depends on is the authentication type you are using – here’s how:
This is why I like the Remote SharePoint Index scenario so much for explaining the planning required here. As you can imagine, within a farm you may grant rights to content based on a Windows group, an FBA role, a SAML claim, or any claim added via augmentation. If you don’t possess those claims when you query for content, then it will be security trimmed out and you will not see it. So you can see how important it is that every claim you are granted when you log in locally, you also get when we rehydrate a version of you.
There’s a lot of potential planning that goes into making all of this work, so hopefully this will help you identify the major moving parts so you know what to focus on.
Awesome explanation... Very informative post... :)
Great article, but what happens in the scenario where one uses SAML and there is no way to sync users from the (third party) repository.How can we set up an SPHA? Can we only use apponly security model (and thus losing the users security context) or can we byass the User Profile sync requirement somehow...