>So, I'd be interested in knowing a little about how you've configured the F5s
>to do hot standby if you don't mind sharing (my currently limited knowledge assumes
>it's by some kind of weighting on the pool nodes?).
Yes, that is correct. I'll try to keep this as generic as possible,
as this is not an F5 mailing list...
On the F5s, set a different priority group for each node.
then set the Priority Group Activation on the pool to be
"less than 1 member in the pool".
You need to setup a monitor to mark a node (IdP) as up/down when appropriate.
For each node, set a monitor with these parameters:
Send String: GET /idp/status\r\n
Receive String: .*attribute_resolver_valid: true
So the F5s keep monitoring for a valid attribute resolver and fail over if not.
For this to work, you need to configure the IdPs to allow the F5s
to access the shib status page. Do this by editing the Shibboleth
web.xml and configure the Shibboleth "Status" servlet to allow
access from the IP address of your F5s.
We have tried doing more comprehensive tests of the status of the IdP,
all the way through to having the F5 authenticate and testing for attributes
being returned, but in practice we found the status page to be sufficient.
Your mileage may vary.
We pass ssl connections through the F5s, but the
user's browser will still be making a TCP connection to the F5, not the IdPs.
Thus the browser-facing certs in the IdP have to have the DNS name
that corresponds to the F5 IP address.
Just some caveats:
This solution works reasonably well, but not perfectly.
Users who login while failover is happening have issues. For example:
If a user authenticates to one IdP and then the failover happens,
the attribute query from the SP may get delivered to the other IdP.
Since the other IdP know nothing about the login, it does not return a
statement. The end-result is that SP gets no attributes and thinks the
user is not authorised
to access the service. I *think* this is only an issue with SAML1.3 however.
Hope this helps,
University of York