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:

• Windows claims – if you are using Windows claims, then for the most part everything you need is in the user profile.  It has your account name and it has your AD group memberships.  What I mean by “for the most part”, I’ll explain in a bit.  But the short version is if you’re using Windows claims then you’re pretty much good.
• Forms Based Auth claims – if you are using FBA then there are a couple of things you need to know.  The first is that you need a way to populate your UPA and keep it up to date.  If you just happen to be using FBA with the LDAP provider and your directory is actually Windows Active Directory, then you’re in a pretty good state.  You can create a profile connection to Active Directory and just associate it with the FBA provider in a manner similar to what I described in the post I linked to above.  In most cases though, AD is not going to be your provider, which means you will have to write some custom code to populate the UPA.  That should be enough to get you the only attribute we should really care about for FBA users, which is account name.  As you all know though, “for the most part” (again, to be explained in a bit), the rest of your data comes from your role provider.  Well the really cool thing we do here is that when we rehydrate an FBA user, we also invoke the associated role provider, so it’s just like the FBA user logged on locally.  That allows us to grab all of the role claims for an FBA user.
• SAML claims – this story is similar to FBA, in that the first thing you need to do is to populate your UPA.  If you’re lucky, your users are in AD and you can just import them directly following the guidance in the linked blog post above.  If you’re not lucky, then you’ll need to find a way to connect to a source directory and import from there.  This of course is probably most complicated with SAML claims because you could have one to many directories, and you may not even own all of them (i.e. maybe you have partners, are federating with ACS and using Facebook or another provider, etc.).  Be that as it may, if you want all this “stuff” to work, then you will need to find a way to populate your UPA.  There’s a second more important point here though – when you log in as a SAML user, you get a set of claims from your Identity Provider (IdP).   This user rehydration process has no way to simulate that login.  That’s just the nature of SAML, right – you could get redirected one to many times and provide any number of authentication prompts and authentication types (like two factor auth) that we could never account for.  So what does that mean to you?  You really need to add your claims via claims augmentation if you want to use them to secure your content and authorize access to that content via this user rehydration process.  You are not going to get claims from the IdP during rehydration so if you want them, you grant them locally.  This is the “for the most part” that I was mentioning above, which I will explain now.
• “For the most part” – what does that mean?  Well by now hopefully it’s become clear – whether you’re a Windows user, FBA user or SAML user, in addition to the claims you get from your authentication provider, you can also have additional claims added via augmentation:  http://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx.  The one other thing that we do during the rehydration process is to invoke all of the registered custom claims providers, so that we can also grab any additional claims for the rehydrated user that they would have received if they had logged on locally and had those providers invoked.

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.