Why not simply federate the SP STS with other companies STS directly?
I looked high and low for this answer but couldn't find anything that completely answered this for me.
Then the SP chapters for the excellent Claims Based Identity & Access Control Guide were published.
(Aside: If you have any interest whatsoever in the claims world, I urge you to read this guide and look at the accompanying samples!)
This includes a diagram of the "hub model" viz:
Notice that Adatum has both a SP STS and a ADFS.
But then they show the "direct trust model" viz:
Notice that although Adatum has an ADFS, it plays no part in the federation to other companies STS.
So the answer would seem to be "No".
However, as per the guide, the advantages of the hub model are:
- It's easier to manage multiple trust relationships in ADFS rather than SharePoint.
- It's simpler to manage a single trust relationship in SharePoint and it avoids the requirement for multiple custom claims providers.
- You can reuse the trust relationships in the FP with other relying parties.
- You can leverage ADFS features such as integration with auditing tools to track token issuing.
- ADFS supports the SAMLP protocol in addition to WS-Federation.
From my experience, the ADFS GUI is far easier to use than SP Powershell commands. The last point is potentially also a deal-breaker. It means that you can't use the SP STS directly if the other companies use non-ADFS products to do the federation e.g. PingIdentity. OpenSSO, OpenAM, Tivoli Identity Manager etc.
Enjoy!
4 comments:
Hello -
Found this post while googling for any SP2010 deployments that use a non-ADFS Fed tool for generating claims. Have you worked on this any further? I'm interested in setting up an SP2010 environment that uses Oracle Federation (OIF) as its claims provider instead of ADFS, and then uses that OIF to Federate with other IdPs (so that OIF is the 'hub'). What do you think?
If you do this, you have to set up OIF to use WS-Fed not SAML.
Other than that, it should work.
However, if you then want to bind ASP.NET with WIF to OIF, you'll find that OIF doesn't have a claims language like ADFS does so you won't be able to do any of that.
You lost me... I'm not a .Net developer. Why would one need to "bind ASP.NET with WIF to OIF"?
Is that for doing look-ups of user information beyond what is provided in the assertion?
Thanks for your input.
If you one day want to go beyond SP and integrate other ASP.NET applications with OIF and configure what claims are provided to the app. from AD, you'll find that ADFS has a much richer claims rules language (and can do more e.g. concatenate, transform) than is provided by OIF. The same is true for SP but (in my experience) SP apps. are configured with far fewer claims.
Post a Comment