Multiple IdPs *with* discovery

[Cantor, Scott]

On 3/25/14, 1:22 PM, "Rob Gorrell" <rwgorrel at uncg.edu> wrote:
>
> 
>Ah, ok, now I'm learning! So the DS would have to return different
>entityIDs for each IdP (which means they would each appear as a selection
>to the user in the drop down box (desirable for desperate IdP's belonging
>to differing members, not so for similar IdPs to the same member) or the
>SP itself would have to have some mechanism for translating a single
>entityID into multiple IdP urls (which I can only assume such a concept
>doesn't exist).

The discovery UI isn't some kind of mandated thing, you can do whatever
you want. But the only thing you get to return is the entityID, so yes,
you could probe something, and then return a different entityID based on
that to get the SP to pick a different endpoint.

> 
>But I'm still left with the reality that bottlenecks and single points
>are often feared in our trade and I can only assume most do not rely on a
>single IdP host/service endpoint to run their organizations
>authentication, so what are the generally accepted ways of turning what
>must be a single endpoint into redundant backend in this context? I'm
>still guessing network load balancer or are there other more common
>approaches to dealing with this?

Load balancers or proxies, yes. Or do active/passive and accept some
downtime if a node fails, I guess.

-- Scott