Configure one SP for multiple IDP

[Peter Schober]

Elaborating slightly on what Scott said.

* reda sabir <sabiretude at gmail.com> [2016-05-12 15:43]:
> I want to configure one SP for multiple IDP. I know that it's already
> possible but I have a constraint is that the user shouldn't know that
> there's many IDP. In fact the SP have to recognise the right Idp by
> analysing the url of the resource requested :
> If the user request the URL: http://site1.ressource.com, the SP should then
> redirect him to http://site1.idp.com for the authentication and so on for
> site2, site 3...

For the IDP selection based on vhost accessed -- assuming Apache httpd
2.4, something like this:

<VirtualHost ...>
  ServerName http://site1.ressource.com
  <Location />
    AuthType shibboleth
    ShibRequestSetting requireSession 1
    ShibRequestSetting entityID http://site1.idp.com
    require shib-session # or whatever you need for authorization
  </Location>
</VirtualHost>

Repeat for other content / vhosts as desired.

> Why I need to use one SP and not multiple SP (each SP for each IDP)
> is because all sites (except the idp) will be on the same server and
> that when the user is authenticated in site1.idp.com, he can then
> access site2.ressource.com without re-authenticating (WebSSO).

Not sure I understand. If you're saying whatever IDP the subject used,
say, http://site1.idp.com from an initial access to
http://site1.ressource.com, they're free to later access
http://site2.ressource.com with their existing session, too?
If that's the case, you're done as that's the default way of the SP
working.

If that's what you want to prevent/avoid you'll have to add
authorization rules to each Location (in the above example), to keep
someone having authenticated at idp1 from accessing site2.

The latter is easy to do if the IDPs share a common understanding and
use of certain SAML Attributes, e.g. based on the
eduPersonScopedAffiliation it's easy to "tack" each Scope to a vhost.

If you don't have that the most straight forward -- but not
recommended, for more philosophical reasons -- way is probably
authorizing based on the IDP's entityID. That's Wrong™ in many cases,
though, e.g. when an organization you have dealings with runs more
than one SAML IDP.

HTH,
-peter