* John Isles <[log in to unmask]> [2012-10-05 16:17]:
> 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
> valid attribute
> 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.
Failing back channels are slightly uglier than failing front channel,
I agree.
To get around this you could always push data over the webbrowser
(send attributes with the authentication assertion), also for SAML1.1.
At least the Shibboleth SP will then /not/ perform any attribute
queries as it already has recieved attributes, no point in asking
again. Other SAML SPs not not be so clever, you'd need to check if
this helps with the SPs users are accessing the most.
The data I send to those SPs (publishers) is non-personal and there's
no issue with potentially exposing the data to the webbrowser.
Then the only thing happening after switchover/failover is people
having to authenticate again at the IdP, and only next time they
access an SP without a valid session there. They wouldn't ever be
stuck at an SP with authentication but without attributes.
Personally I find that hot-standby IdPs without shared state, behind a
pair of redundant loadbalancers with SSL-offloading are acceptable,
even for the very few cases where we needed to restart the IdP
(upgrading the software is now the only thing I can think of why I
would need to restart the IdP).
Getting fancier later, with shared-nothing clustering etc is always
possible. The Shibboleth IdP v3 (whenever that sees the light of day)
is supposed to come with that enabled out of the box. Until then
hot-standby beats messing with Terracotta any day, in my book.
-peter
|