How to configure multiple IDPs in Shibboleth

Peter Schober peter.schober at
Wed Aug 29 06:13:55 EDT 2018

* Ron Harris <neo204011 at> [2018-08-29 10:57]:
> I have installed shibboleth 3.0.2 version. I am hosting a single
> page application

If that client-side (i.e., in-browser) application requires
trustworthy identity data you might stop right there and consider how
a SAML implementation running on the web server would be able to
achieve that.

> How can i configure two IDPs in shibboleth2.xml file. element is allowed
> only once. I have provided two tags with different metadata file but when I
> click the link,
> it shows me two "entityID" elements with same IDP provided in .

Probably Garbage In, Garbage Out, as Rod suggested.

The software itself doesn't de-duplicate the data it uses (or exports
as JSON) for discovery purposes, which might in fact be a bug, as it
couldn't differentiate between multiple EntityDescriptors with the
same entityID, anyway.

> How does system work with two IDPs. What should be the process to
> identify when to call which IDP. Like with single IDP, I can do
> something like below in my Apache configuration. Whenever the
> context path is hit, apache will redirect the call to shibboleth,
> and shibboleth to IDP.

For true multi-party federation the recommended way is to provide an
IDP Discovery Service, i.e., when accessing the protected resource the
subjet gets to select the IDP they intend to use for this session.
The Shibboleth project provides the EDS software for that purpose.

But with only 2 IDPs that seems overkill (though I have personally
used it even in such corner cases, with the 2 IDPs set as
'preferredIdP' and removing all unnecessary elements from the EDS UI):

With active protection (requireSession true) as used in the config
snipped you provided you could "simulate" a much simpler discovery
service with even a sttic HTML page w/o actually implementing the
discovery protocol: Just put one login link for each IDP on an HTML
page, /outside/ of your application and /not/ protected by the web
server (e.g. at /login/), and set that pages's URL as
SSO/@discoveryURL parameter in your shibboleth2.xml.
If you also set SSO/@target to the base URL of your application
("/my-first" in your example) people will always be returned to your
application's base URL after authenticating at their IDP when
returning to your server. Something as simple as this would do for the

<a href="/Shibboleth.sso/Login?entityID=https://adfs1/">IDP One</a>
<a href="/Shibboleth.sso/Login?entityID=https://adfs2/">IDP Two</a>

But you can get as fancy as you'd like, of course.

(The value of the entityID parameter in the examples above would have
to be URL-encoded for correctness.)


More information about the users mailing list