Can you do that!? Yes, and in fact, the University of Missouri has a working demo of this that I’ve seen (and in fact, I have 10GB of virtual images of that demo environment). In terms of the coming Sharepoint service offer, it isn’t immediately clear today whether we’ll be able to offer federated authentication at the time of the initial offer, but I do think it’s a feature we need to support.
There are two general use cases for using federated authentication with Sharepoint:
a) All your collaborators have a UW NetID, but for some reason their OS and browser can’t do Windows Integrated authentication (Kerberos, NTLMv2, or NTLMv1).
b) All your collaborators don’t have a UW NetID, but they have credentials elsewhere via either an ADFS or Shibboleth infrastructure.
Most of this blog post will focus on b), but let’s talk just a bit about a) first.
An overwhelming majority of browsers and operating systems do permit Windows Integrated authentication of some flavor, so there isn’t a large demand for this, however, it is an option for that small set of clients.
In this scenario, you’d permit pubcookie authentication via the UW’s Shibboleth IdP. IdP is the terminology for the server which issues the authentication token in this technology.
For either a) or b) you need to have a second web application which has another authentication provider than Windows Integrated. That other web application can point at the
same site content, but because of the security details underneath both federation technologies, you are required to have a different URL if you have access to any given site
via both Windows Integrated and a federated authentication provider. Some of this is noted here, in this ADFS and MOSS configuration link, http://technet2.microsoft.com/Office/en-us/library/61799f9a-da01-4c11-b930-52e5114324451033.mspx?mfr=true
For either a) or b) there are side-effects/limitations/broken features. For example, the Office document library integration breaks. Which brings me to the second of many external links, Unsupported SharePoint features with ADFS, http://go.microsoft.com/fwlink/?LinkId=58576. And yes, that list is relevant for both a) and b). So generally speaking, if
you can help it, you want to do Windows Integrated authentication. And while I’m back on that topic, I should also mention that those clients which can’t do Windows Integrated auth have another option which is do basic auth together with ssl.
Moving onto b), we’ll get a bit into the architecture, and then later on, I’ll talk about how there are actually two possible solutions for a) and b) (which makes talking about this
already complex topic much more complicated).
So … for a general overview of Shibboleth and ADFS, there are a number of good online resources:
Understanding Shibboleth, https://spaces.internet2.edu/display/SHIB/UnderstandingShibboleth
ADFS Design Guide, http://technet2.microsoft.com/windowsserver/en/library/a6635040-3121-47ce-a819-f73c89dafc571033.mspx?mfr=true
Doing the interoperability between ADFS and Shibboleth requires installing the Shibboleth extension for ADFS, https://spaces.internet2.edu/display/SHIB/ShibADFS, on your IdP, and on every IdP you’d like to accept authentication claims from.
This link has probably the best information available anywhere about the actual interoperability between ADFS and SHibboleth, Shibboleth and ADFS Interoperability
From a quick overview of the architecture components involved, let’s talk about an imaginary use case. Say you’ve got a collaborative group that includes folks from Stanford and the UW.
The Stanford folks would go to the Sharepoint site, and the ADFS Web Agent would redirect them to authenticate with their Shibboleth IdP (using their local webauth sso provider) and present that claim to a UW ADFS-R server. That server would take the claims, perform any translations specified in a trust agreement, and issue a new set of claims to present to the Sharepoint server which has the ADFS Web Agent installed. That ADFS Web Agent takes those claims, and translates them to the Sharepoint security model.
Both of these links talk about this last step:
Now the description I’ve just shared is one of two possible solutions for b) (and to some extent a)). The other solution drops ADFS from the mix. That one goes like this:
The Stanford folks would go to the Sharepoint site, and the Shibboleth agent would redirect them to authenticate with their Shibboleth IdP (using their local webauth sso provider) and present that claim to our Shibboleth SP server. That server would take the claims, perform any translations specified in a trust agreement, and issue a new set of claims to present to the Sharepoint server which has the Windows Shibboleth agent on it. The Windows Shibboleth agent takes those claims, and pass them to a custom asp.net membership provider which translates them to the Sharepoint security model.
There is a vendor which has something that I think is (or is close to) the custom asp.net membership provider needed. You can read more about it at http://www.9starresearch.com/activesharefs.html.
I suspect the solution which includes ADFS is going to be preferable, but that’s still to be fully considered.