ADFS + Shibboleth federation

[Cantor, Scott]

On 8/5/14, 11:37 AM, "Domènec Sos i Vallès" <DSV at nextret.net> wrote:

>If the user is authenticated by Shibboleth, he/she can access any relying
>party of both ADFS and Shibboleth.
>If the user is authenticated by ADFS, when accessing a Shibboleth relying
>party a second login into Shibboleth will be needed the first time.
>The organization prefers to leave ADFS as the main login site, not
>allowing the users to choose what IdP.

The best way to do that from where you are is to stop authenticating
directly with ADFS and simply have it relay all authentication requests on
to the Shibboleth IdP, so that anybody accessing an ADFS RP is going to
get a session with the Shibboleth IdP.

To make ADFS the main login site, you have to either just get rid of the
Shibboleth IdP and use the ADFS service alone as the SAML IdP, or you will
have to turn the Shibboleth deployment into a much more complex system by
adding an SP to the mix and changing its authentication configuration,
*and* come up with extensions and add-ons to get the attributes resolved
by that IdP from the SP half of things.

>I have to read in depth the "AD FS 2.0 Step-by-Step Guide: Federation
>with Shibboleth 2 and the InCommon Federation" pointed by Aaron's wiki
>suggestion (and reviewed by Scott Cantor himself).

Review does not mean "like". That document is a mess.

>Question: Will installing the Shibboleth SP in my current Shibboleth IdP
>(as per step 2) allow it to work as a relying party of the ADFS IdP?

Yes, but only after a lot of additional effort. Just don't.

If you want to use ADFS as the IdP, then just stop using Shibboleth. Or
replace Shibboleth with simpleSAML.php, which is designed to be a proxy
much like ADFS is designed to be.

-- Scott