On 05/10/2012 17:32, Peter Schober wrote:

> 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.

Please note that the UK federation recommends that you do not push 
attributes with the authentication assertion for SAML1.1 because they 
cannot be encrypted; you thus have to push them in the clear.

As to whether the data is personal or not; there may be different 
definitions of this according to country.

My view would be that while 20% of SPs in the federation still don't 
support SAML 2 (and some of these are major players) that you need a 
solution that supports back channel attribute queries. Losing existing 
authentications in a failover scenario could be acceptable.

 From what I've seen from behind the support desk, Terracotta can work 
well for an organisation with a strong IT department, but it is 
something of a black art to get it working properly. We can't really 
support it here, because by nature of being a support team, we don't 
have a real live production system in place that we can learn from.


> 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

Sara Hopkins
Support Team
UK Access Management Federation for Education and Research

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.