ADFS + Shibboleth federation

[Aaron Howell]

We made the ADFS IdP subordinate to the Shibboleth IdP. To get an ADFS session, you have to log into Shibboleth. This meant there was no need to make the Shibboleth IdP authenticate from the ADFS IdP. It made the set up quite simple. It has been working very well and has kept the ’S’ into SSO when we were basically forced to put in ADFS.

It was documented what we did here: https://wiki.shibboleth.net/confluence/display/SHIB2/MicrosoftInterop#MicrosoftInterop-UsingShibbolethIdPasauthenticationsourceforADFS

Hope that helps



On 6 Aug 2014, at 12:22 am, Domènec Sos i Vallès <DSV at nextret.net<mailto:DSV at nextret.net>> wrote:

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<http://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

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>


Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.

Deakin University does not warrant that this email and any attachments are error or virus free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140805/f912cb75/attachment-0001.html