Using SSP against multiple AD FS servers

[Eivind Lie Andreassen]

Does anyone know whether it is possible to setup SSP as an IdP, and bridge it to multiple AD FS servers for authentication? The company I work for are looking at implementing a new intranet solution, and we need to be able to logon with authentication against Active Directory for members of three separate domains. One relevant intranet solution has support for authentication against a single SAML IdP, and I've been trying to figure out whether it's possible to use a SSP setup in the middle to let the user choose from the three different domains, and then logging in. 

[Peter Schober]

* Eivind Lie Andreassen <ela...@gmail.com> [2016-07-12 12:47]:

> Does anyone know whether it is possible to setup SSP as an IdP, and
> bridge it to multiple AD FS servers for authentication?

Youn can set up SSP as an SP towards those 3 IDPs, and as an IDP
towards the protected resources, sure. I.e., the same SSP instance
would be configured as both an IDP and an SP.

But MS-ADFS itself functions as a proxy (acting as both a SAML IDP and
SAML SP), so maybe adding yet another MS-ADFS would be a more natural
fit in your case?

Of course *avoiding* any proxying is much preferrable, for lesser
complexity of the setup (and therefore more resilience) as well as
higher fidelity (end-to-end encryption of protocol messages, Single
Logout where SPs/applications support it, etc.).
One way to do that would be ignoring the "FS" part of each
MS-AD/domain and using only those for LDAP authentication and as
attribute sources, from a single SAML IDP (SSP or otherwise).
Whether that's possible depends on internal IDM practices
(e.g. uniqueness of identifiers across MS-AD instances) and UX choices
(e.g. what login name someone needs to enter into that one SAML IDP;
even without globally unique identifiers you could still make that
model work either with "scoped" identifiers, or by having a choice of
MS-AD/group/domain on the login page, e.g. like FEIDE has done for
years, cf. https://foodl.org/ and pick "Feide" during login. The UI
can look quite different, of course.)
-peter

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2016-07-12 13:19]:
> Whether that's possible depends on internal IDM practices [...] and
> UX choices

Note that at least the same UI/UX constraints exist when proxying:
You'd also have to have a way to let people pick the SAML IDP they
want to use for authentication. So if sufficient exists for all
passwords to travel through a single system (like FEIDE does for a
whole country's academic population) then you can have much the same
UI/UX but without any proxying, making everyone's life (and SAML
configuration) much easier.

And yet another (and most common, at least in academia) way to avoid
both SAML proxying and centralisation of authentication is to move the
choice of IDP (or LDAP/domain) to each SP -- or to a
common/centralised IDP discovery service -- and treat each separate
IDP as a separate IDP. No proxying, no central authentication, no
funny business.
That keeps separate things separate and the IDP discovery service can
offer to remember the chosen IDP in a HTTP Cookie. So each SP that
used the same IDP DS would sent authn requests to the preferred IDP,
without interative involvement and releated selection.
Whether that's possible depends on the service you make yourself
dependent on. E.g. some SaaS vendors chose not to support more than 1
IDP per "customer". For such cases you'd still need a centralised IDP
or a SAML proxy.
-peter

[Eivind Lie Andreassen]

Thanks for your response; it's helped me to better understand how one would set up such a system. At least I know now that it is possible through different means, which as this stage was the most important.

BTW; I'm a Norwegian student, so I'm familiar with FEIDE - it's actually what made me think about SimpleSAMLphp in the first place!