Multi-site question

[Steve Sirag]

Scott--

Thanks for your response.

It sounds like we should set up our own centralized discovery service server, and use that to map our apps to IdP's, is that correct?  Can we make use of request tagging or some other means to keep the selection of IdP for any particular website transparent to the end users?

Regards,

Steve Sirag

eResources
O: 800-297-8293 x7034
C: 703-608-8127
eresources.com


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, July 18, 2016 12:21 PM
To: Shib Users
Subject: RE: Multi-site question

> We're setting up a dedicated set of servers for Shibboleth-integrated sites.

Shibboleth isn't designed to run on dedicated servers, it's targeted at systems hosting the protected resources. Doing it separately requires deploying a second SSO protocol between those systems. That's very easy to get wrong.

> Is it possible to integrate with different Identity Providers for 
> different sites on the same server?  If so, are there any particular 
> tricks to setting the servers up for that capability?

There are many ways, good and bad. The right way is to do IdP discovery if a user directly contacts a resource to determine which IdP to use. It is well understood that customers simply don't accept this. But bypassing discovery does not require that the service do that work. The SP software can be interacted with to request a login to a particular IdP for a particular resource, and so the home organization can host and trigger those requests. That was even standardized in SAML as something called request initiation.

The wrong way to do it is to multi-home the application or the SP or both to hardcode the IdP for specific hosts or URLs. That is a mess and the SP is very bad at doing it. It also makes metadata-based trust automation much more work.

The design of the SP is discussed at length in the NativeSPApplicationModel topic in the wiki, but some of that is a bit dated now because it is more accomodating of approaches that I would now argue are just deeply wrong.

An SP should ideally have a single identity and a single set of endpoints by which it protects resources living *on that vhost* for any number of IdPs. As soon as you go outside that box, you are in for pain, and it's mostly self-inflicted. There are other ways to avoid the discovery step *most of the time* while accepting that direct access to a resource simply needs to do the discovery step.

If your response to this that your application is siloed and only ever accessed by one IdP at a time, you're incorrect about that. Single organizations do run multiple IdPs, and you'll run into that sooner or later.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net