Multiple IdPs *with* discovery

[Rob Gorrell]

On Mon, Mar 24, 2014 at 4:29 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> You don't have two IdPs there, you have one. You can't deploy separate
> IdPs for "redundancy", that has to be handled behind the scenes. A browser
> is only going to try one place, it can't know to try another.
>

You say I don't have two IdP's in this sense because they would both
configured to answer as the same entityID, is that correct? I understand
deploying multiple IdP's doesn't solve the problem of sharing sessions
among them and upholding the purest since of SSO, but there is some level
of "redundancy" the comes from having multiple ones answering the same
authentication *if* you can redirect the client between them. we
currently use DNS/A record to provide passive failover to a standby IdP
should our primary become unresponsive. I was curious about how this was
handled in deployments significantly larger than us, especially if usage
dictates the IdP scaling beyond running on a single host.


> It doesn't have to be a load balancer, but there can only be one endpoint
> tried, period. It's physically impossible to do anything else with a
> browser unless the first endpoint just redirects to the second, which
> isn't really going to work if the first is down.
>

I understand the browser can only redirect to a single endpoint, but
because the WAYF/DS is involved in returning that particular endpoint, I
didn't know and was curious if there was/could be any intelligence baked
in (I guess at the DS level) allowing it to pick from multiple "sites" for
a given entityID.

-Rob


Robert W. Gorrell
Systems Architect, Identity and Access Management
University of NC at Greensboro
336-334-5954 <#> <#SafeHtmlFilter_>
PGP Key ID B36DB0CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140325/a912addd/attachment-0001.html