Serving multiple IDP from ApplicationOverride SP setup

[Zico]

Hello Gurus,

I am just curious if it is possible to connect multiple IDP's entityID from
one Shib SP instance?

Say, I have multiple protected apps here in my sp (named: testsp.test.com);
configured with ApplicationOverRide ( via. RequestMapper )... /ext1, /ext2
and /ext3

Now, I want:
1. "testsp.test.com/ext1" to move for "testIDP1.test.com"
2. "testsp.test.com/ext2" to move for "testIDP2.test.com"
3. "testsp.test.com/ext3" to move for "testIDP3.test.com"

Is it possible?

I am not going to implement this in any production environment but I am
just playing here... so, just asking. :-)

[Cantor, Scott]

Post by Zico
I am just curious if it is possible to connect multiple IDP's entityID
from one Shib SP instance?

The proper way to support multiple IdPs is with a discovery interface.
Anything else is a copout that prevents actual federated access to a
single set of resources, which is almost always a use case even when SPs
are convinced they know better. There are "single organization" federation
use cases in which there will still be multiple IdPs, so there is never a
valid assumption that only a single IdP per resource is appropriate. It's
a simplification that creates a limitation.

Post by Zico
1. "testsp.test.com/ext1 <http://testsp.test.com/ext1>" to move for
"testIDP1.test.com <http://testIDP1.test.com>"
2. "testsp.test.com/ext2 <http://testsp.test.com/ext2>" to move for
"testIDP2.test.com <http://testIDP2.test.com>"
3. "testsp.test.com/ext3 <http://testsp.test.com/ext3>" to move for
"testIDP3.test.com <http://testIDP3.test.com>"
Is it possible?

Yes, you set an entityID content setting on those three directories/paths.
You just shouldn't do it.

Post by Zico
I am not going to implement this in any production environment but I am
just playing here... so, just asking. :-)

It's extremely common to do all of that in production, which is why I'm
noting that it's not a good decision, just a very typical one.

-- Scott

[Randy Wiemer]

There is a competing view that holds that the discovery service process is cumbersome, especially as the number and diversity of IdPs grows, and therefore implementing your service in a manner that avoids the need to involve the user in the discovery process is a reasonable strategy. Many SAAS vendors accomplish this by having dedicated URLs for each IdP. Another common strategy is to prompt for the username which contains a domain part and then redirect to the IdP based on the domain part of the username.


Randy

[Cantor, Scott]

Post by Randy Wiemer
There is a competing view that holds that the discovery service process
is cumbersome, especially as the number and diversity of IdPs grows, and
therefore implementing your service in a manner that avoids the need to
involve the user in the discovery process
is a reasonable strategy.

I'm aware of the competing view, and unfortunately it doesn't solve the
problem to pretend there isn't a problem.

Post by Randy Wiemer
Many SAAS vendors accomplish this by having dedicated URLs for each IdP.

Which precludes federation, as I said. You can only present this as a
competing alternative if it actually solves the problem. That model is
broken.

Post by Randy Wiemer
Another common strategy is to prompt for the username which contains a
domain part and then redirect to the IdP based on the domain part of the
username.

Yes, and that's a discovery interface, probably the eventual one that wins
out, it just has the problem that it's not privacy preserving, which is a
limitation for some applications, though not most.

-- Scott