Data Protection issues with Shibboleth
This was a working document belonging to the Computing Service's Shibboleth Development Project. This project is complete (Raven now supports Shibboleth) and this document only remains for historical and reference purposes. Be aware that it is not being maintained and may be misleading if read out of context.
Some notes about data protection issues and requirements as they apply to the Shibboleth project.
Most of the static data (e.g. information about users, rather than e.g. logfiles) being used by the IdP is already held elsewhere by the CS (Jackdaw, lookup, etc.) so we can (presumably?) assume that most DP issues relating to it have already been resolved. Though might Shib be a new Purpose?
Life is much easier where we can avoid disclosing personal/bibloigraphic data. This is true even if it is in the user's interest for us to do so (i.e. it's better for us to require a user to to supply his/her email address direct to each and every SP they use than it is for us to supply it for them). We should therefore resist releasing any non-anonymous attributes as strongly as we can, which in any case fits with UK Federation policy.
We are in a much better position if users consent to our disclosing information, especially anything that is personal. Initial click-through terms of use and click-through acceptance of what's being disclosed in particular cases are good or even vital (a la ArpViewer). However it may not be good enough if we only show these once. The more often the better, but a redisplay once a year, along with prominent links to view the information at other times, might be acceptable.
If users decline to allow us to disclose information they may be refused access to some resources. This could be unacceptable if access to these resources was in some way required and there is no alternative.
If personal information is going to be disclosed then any click-through terms of use are going to have to be a "Fair Processing Notice" that meets the Information Commissioner's expectations. It may prove difficult to get across all the necessary information in a document of acceptable length.
Neither user consent nor UK Federation rules can be guaranteed to protect us if personal data that we transfer outside the EEA is subsequently misused. This suggests that such transfers can only take place if covered (as the UK Federation suggests) by contracts that contain acceptable safeguards. This is going to be a problem where an SP is run by something ad-hoc, like a research group. Note that it's not easy, or perhaps possible, to work out if an SP is inside the EEA or not. Documented procedures and records justifying release decisions would be advisable. However manual approval of every SP is going to be time consuming.
It would be advisable to clearly distinguish between resources provided by the University, which users might choose to trust, and those provided by others. A typical Shib interaction switches between these in what may be a confusing manner.
In designing the system we should remember to make servicing subject access requests as easy as possible. Likely data not imported from elsewhere include attribute release decisions and logging information.
The Colleges are of course separate legal entities. This will have implications both for data use and disclosure. We should probably treat SPs in the colleges by default as we would any SP elsewhere in the EEA. We should check that data we collect form the colleges, or direct from college employees, may be used for purposes such as Shib.
