 |
 |
* Sara Hopkins <[log in to unmask]> [2012-10-08 15:52]: > 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. You'd potentially expose yourself suggesting otherwise, so the conservative official recommendation is clear and all well. I was just saying that an institution could look at the risks involved and still decice to push attributes. The risk of some unauthorized person with full access (!) to your computer (!) and webbrowser -- while you're have an active SSO session with your IdP -- also getting access to your ePSA values ([log in to unmask]; [log in to unmask]) from a SAML-assertion seems like a small price to pay, IMHO, when you gain added resilience in your IdP deployment for free (otherwise). For the most common services (publishers) there will be no personal identifiable data involved (if only ePSA or ePE with the common-lib-terms value are released) and much of the information that would be available to the unauthorized person can possibly be deduced from the misused computer itself. More realistically, people grabbing SAML-assertions from someone else's webbrowser while logging in to SAML1-only entities (that usually means disabling JavaScript in the webbroser first) and then base64-decoding the content might find more lucrative ways to misuse someone else's WebSSO session or comuter (with all its files and emails on it!). The SAML assertion in transit is not a relevant target in such a scenario, IMHO. So the risk of exposing data from the SAML assertion to the HTTP User Agent /for use with SAML1-only publishers/ is vastly overstated, in my very personal opinion. (Has there been a single report of such an incident in the history of SAML-based WebSSO? That of course might be due to the fact that institutions either don't push attributes in the clear or use SAML2 and encrypt: No way of knowing if the threat is exaggerated or the consistently applied mitigation so effective.) Of course it's easier to say "No risk is better than a very very very low risk with potentially negligible or no damages". That just comes with a price for the institution in operational complexity and the costs associated with that (at least once you need resilience and higher availability). And all that is of course meaningless unless you know that pushing attributes would actually help achiving that goal. Some SPs might not stop issuing SOAP queries even if an attribute assertion was included with the initial authentication assertion. -peter