This is a question that has been puzzling me for a while. Given that SP 2010 has its own STS, what value is derived from federating the SP STS with the company ADFS and then federating this ADFS with other companies STS?
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!