SP configred to use multiple IdP's.

[Cantor, Scott]

On 11/8/15, 9:36 AM, "users on behalf of Hall, Gerry" <users-bounces at shibboleth.net on behalf of gerry.hall at emory.edu> wrote:



>We want to run two different IdP's; IdP1 will use the typical
>authentication process ((1FA) while IdP2 will use two factor
>authentication (2FA); both IdP1 and IdP2 use IdP version 3 code.

Well, that's not really an intended approach.

>Without using a federated service, is there a way to configure the SP so
>that authentication requests for app1 and app2 default to IDP1 (1FA);
>however authentication requests for app3 are sent to IdP2 (2FA)?

Yes, using the "entityID" content setting via the RequestMap or Apache command. "Default to IdP" is exactly the intent of that feature, controlling the automatic behavior, but not trying to limit it.

>For app1 and app2, these must use IdP1 (1FA) and prevent use of IdP2 or any other
>IdP.  For app3, app3 must use IdP2 (2FA) and prevent use of IdP1 or any
>other IdP.

Preventing use of any trusted IdP beaks the whole model. That turns this into a much harder problem, particularly if you try and do it by path and not vhost. You should really have one IdP, supporting all methods required, and use the authnContextClassRef in the SP to control the required method used by the IdP.

If you really have to do this, I would still suggest avoiding overrides. You can get around the design and do authorization based on the entityID. Best would be to do that in your application by enforcing the policy against the Shib-Identity-Provider variable. If you have to do that via Apache rules or the SP's access control feature, it's harder.

-- Scott