<div dir="ltr">I have 2 production instances behind F5. One is primary, the other a secondary/fail-over if the primary is unreachable. I deploy new integrations in the secondary, validate by DNS override in client etc/host file (by-pass the F5 to directly use the secondary IdP instance), then migrate changes to the primary and force re-load. It's been a notably robust configuration, but if we deploy additional nodes at remote sites or in the cloud, may need modification.<br><br>A fairly recent change was to terminate TLS on the F5 to enable application layer decision-making on the F5; I insisted on re-encryption from the F5 to the IdPs.<br><div><br></div><div>David St. Pierre Bantz</div><div>U Alaska</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 5, 2020 at 10:08 AM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/5/20, 2:05 PM, "users on behalf of Donald Lohr" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:lohrda@jmu.edu" target="_blank">lohrda@jmu.edu</a>> wrote:<br>
<br>
>    I don't believe load is an issue either, folks want to use a commercial <br>
>    load balancing product to share the work between more than 1 IdP.  More <br>
>    over to maintain the SSO feature of Shibboleth across more than one IdP <br>
>    being balanced.<br>
<br>
That's why client-side is the default, it takes that out of the equation.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>