ADFS + Shibboleth federation

[Domènec Sos i Vallès]

Hello,

the organization I am working at has two IdP in a test stage about to go to production as part of an ongoing SSO initiative:

- ADFS v2, whose relying parties are Sharepoint sites (previously using MS TMG SSO), ASP .Net applications (no previous SSO), ex-novo Wordpress sites using the plugin based on simpleSAMLphp, Outlook mail (we leveraged the initial ADFS installation), and one external application in the cloud, Salesforce (no previous SSO).

- Shibboleth 2.4, whose relying parties are several applications that will be migrated from CAS in the coming months, several cloud services (Blackboard, Zendesk, Google Apps...) and one relying party as a PHP application with simpleSAMLphp (BTW, nice little piece of software it is)

Reasons for having two IdP include long internal discussions that I don't want you to be bored with.

As of now, and following a Microsoft guide, Shibboleth is a trusted claims provider for ADFS, and ADFS is a relying party for Shibboleth. This means that people can log in Shibboleth and access Sharepoint sites, ASP .Net apps, etc (except Outlook, which would have been too much sorcery to watch for the Microsoft guys, but I guess it would work with some proper claims transformation rule in ADFS).

All of this (except the CAS apps) has been tested in a laptop based VirtualBox laboratory environment and in a pre-production test environment.

What is missing is to have ADFS as a valid IdP for the Shibboleth relying parties, and that sounds as "federation". I have done some RTFM and tried to learn from example, and at this point I will highly appreciate some "been there, done that" point of view, ideas, criticism, and URL formatted values for M in further RTFM.

For setting up the federation I got much enlightenment and an example from
https://www.switch.ch/aai/docs/shibboleth/SWITCH/latest/idp/deployment/#shibboleth-idp-configuration
and some ideas from this, although it is Tivoli oriented.
http://technet.microsoft.com/en-us/library/gg749921(v=ws.10).aspx

This seems to be not what I am looking for, as it sets a Shibboleth *SP* as a relying party of the ADFS, but not a federation between both IdP. The InCommon Appendix is a bit incomplete in comparison to the body of the article:
http://technet.microsoft.com/en-us/library/gg317734(WS.10).aspx

So, my view of what should be done is:

For Shibboleth;

- For the Shibboleth IdP, a federation metadata setup similar to the one explained by SWITCH.ch, including both ADFS and Shibboleth as IDPSSODescriptors. ADFS metadata will be prepared as in the Tivoli example (which I trust to be SAML 2.0 compliant). This is the mirror of declaring Shibboleth as a trusted claims provider in ADFS.

- Remove the definition of ADFS as a Shibboleth relying party, considering it will now be a federation peer as per the federation metadata.

- No need to add a Shibboleth SP anywhere for federation purposes (applications moving from CAS may, but in order to become Shibboleth relying parties)

For ADFS:

- Leave "as is" the ADFS claims provider trust for Shibboleth. That would be the part of importing federation metadata, provided ADFS does not allow importing multiple entity descriptors. I should check the results of applying the FEMMA tool to the federation metadata and see if the result would be similar to what I have.

I understand that the effect for Shibboleth of declaring ADFS a part of the federation mirrors declaring Shibboleth as a trusted claims provider for ADFS. From here, each IdP will transfer to their relying parties the claims that were received by the opposite trusted claims provider or federation peer.

All ideas are welcome and appreciated, thanks in advance.

/Domenec

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140805/3f7b5249/attachment-0001.html