ADFS + Shibboleth federation

[Cantor, Scott]

On 8/5/14, 10:22 AM, "Domènec Sos i Vallès" <DSV at nextret.net> wrote:
>What is missing is to have ADFS as a valid IdP for the Shibboleth relying
>parties, and that sounds as "federation".

Leave the word federation out of this, it's overloaded and not a technical
term.

Why would you need to do that if you have the Shibboleth IdP already
acting as the back-end for the ADFS system?

Or are you trying to reverse all of it and make ADFS the back-end?

Regardless, a Shibboleth "relying party" is an SP, that's it. They do
SAML. ADFS does SAML. Thus, the Shibboleth IdP is not relevant or needed
in such a conversation, and that's where you seem to be going off track
below.

>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.

There is no such thing. SAML SSO is between an IdP and an SP, it is not
defined in terms of two IdPs. When you link IdPs, what you're doing is
making one of them act as both an IdP and an SP, but in SAML terms,
they're just separate notions and it's just one system acting in both
roles to serve as a proxy.

The Shibboleth IdP does not have that kind of capability out of the box.
Using it as an SP, or more accurately using another SAML IdP to
authenticate to it requires adding an SP into the mix.

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

There is no such concept in SAML as "federation peer" except in the most
generic abstract sense. It has no technical meaning. A peer is an SP or
IdP for the purposes of the SSO profile.

Beyond that, I really don't understand what your goal is yet.

-- Scott