Configure one SP for multiple IDP
peter.schober at univie.ac.at
Thu May 12 16:34:29 EDT 2016
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:
ShibRequestSetting requireSession 1
ShibRequestSetting entityID http://site1.idp.com
require shib-session # or whatever you need for authorization
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
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.
More information about the users