For availability purpose, I have a redundant setup with 2 fronts and 2 backs. Each front hosts a web server, serving the same pages. Each front runs a instance of Shibboleth SP, redirecting to the same IdP. Both fronts are behind a load balancer exposing a unique public address. The Load Balancer will have a session affinity set on the shibboleth cookie.
On the first connection, the user is not authentified and Shibboleth SP redirects to the ADFS with a relay state. After authentication, the ADFS redirects to the LB public address.
Problem is, there is no shibboleth cookie yet. Can the redirection be handled by either instance of Shibboleth SP? If not, how to properly manage 2 redundant instances of Shibboleth SP as described?
Thanks!
ADFS redirects the user back to the LB address which passes along the SAMLResponse to whatever node it selects, at which point the SP (either) will see a valid SAMLResponse and initiate a cookie. If the user gets pinged to another SP node, that cookie won't be seen by the SP as valid unless both SPs are sharing a common session store, just as a database, and it'll kick through SSO again. Usually session stickyness would be pegged to user's IP so that they always (or almost always) get redirected to same SP instance... and on the offchance their affinity changes they'll still have a valid IDP session and shouldn't see the login page.
A lot of this depends upon your application and how that's built, too... see: https://wiki.shibboleth.net/confluence/display/SP3/Clustering... TL;DR: avoid clustering the SP by leveraging it on a single entry point since it's lightweight (problematic but what I'd usually recommend), or live with sharing a session DB (which has a lot of it's own problems).