Shibboleth Attribute Release meta-Policy: Difference between revisions
(Revised in the light of UCS SMT comments) |
(Policy now in line with SMT214.) |
||
| Line 9: | Line 9: | ||
1) All changes to this policy are approved by the Director of the University Computing Service or his deputy. | 1) All changes to this policy are approved by the Director of the University Computing Service or his deputy. | ||
2) Users are told about the IdP, and the fact that it may disclose information about them, the first time they use it to access a resource and at least annually thereafter. They are required to positively confirm that they accept the terms and conditions under which the IdP operates before proceeding and a record is made of this acceptance. On first access to a particular SP, users are made aware of the attributes that | 2) Users are told about the IdP, and the fact that it may disclose information about them, the first time they use it to access a resource and at least annually thereafter. They are required to positively confirm that they accept the terms and conditions under which the IdP operates before proceeding and a record is made of this acceptance. On first access to a particular SP, users are made aware of the attributes that may be disclosed to it, along with their current values, and asked to approve this disclosure; this will be repeated at least annually and any time the list of attributes being disclosed to this SP changes. If the SP is a known member of the UK Access Federation, or a known University of Cambridge SP then it will be identified as such from our Access Federation data files. If it an unknown SP this will also be clearly declared. | ||
3) The | 3) The Shibboleth protocol requires that the SP have a copy of the University's Shibboleth metadata. This will be made available via HTTPS at https://shib.raven.cam.ac.uk/shibboleth for ad hoc use by SPs outside our set of known access federations. | ||
4) | 4) The University institutional IdP provides three attributes to any SP that requests them. These are: | ||
4.1) eduPersonScopedAffiliation with the appropriate value (e.g. member@cam.ac.uk, staff@cam.ac.uk, student@cam.ac.uk). | |||
4.2) eduPersonTargetedID (an identifier allocated at random and distinct for each combination of user and SP, e.g. MlWd0XIR7juZvwvarOVdYiUWPW0=@cam.ac.uk) | |||
4.3) eduPersonPrincipalName with the value crsid@cam.ac.uk | |||
5) Values for any other attributes (in particular eduPersonEntitlement, a 'catch-all' container for values specified by particular SPs, for example cam#default0 used by EduServ Athens to grant general access through the Shibboleth to Athens gateway), may be released to any SP that can demonstrate a reasonable need, providing the corresponding user's identity can not be derived from these attributes or other information likely to be available to the SP. Each SP will only receive the particular extra attributes and values that it requires. | |||
6) Other attributes from or derived from lookup, notably givenName (e.g. Fred), sn (e.g. Clark), cn (e.g. F.J. Clark), displayName (e.g. Fred Clark), ou (e.g. Department of Important Studies), instid (e.g. IS), mail (e.g. fjc55@cam.ac.uk) and groupID (e.g. 100123, 100987) may be released to SPs operating on servers that can already query lookup directly for the same information, but only subject to the user's choice of suppression in lookup. | |||
Attribute and attribute value disclosure approved under section | 7) Other than as mentioned above, attributes and attribute values are only disclosed where there is a demonstrable need and where there is adequate levels of protection for the data concerned. Release of such information is only permitted where there is no alternative.1 Each decision to allow or alter such a particular disclosure is approved by the Director of the University Computing Service or his deputy before it is implemented and recorded in the schedule to this policy. | ||
===Schedule=== | |||
Attribute and attribute value disclosure approved under section 7 above: | |||
: ''None'' | : ''None'' | ||
Revision as of 11:38, 18 July 2007
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.
- This document [2007-07-09: currently a draft] sets out the policy observed by the managers of the University of Cambridge's institutional Shibboleth IdP in respect of release of attribute information. Transfer of attribute information is central to the operation of Shibboleth, however attribute values may represent 'personal data' under the terms of the Data Protection Act 1998 and processing and release of such data must abide by the provisions of the act. This policy ensures that the University does so.
- See Shibboleth Attribute Release policy summary for details of the currently implemented attribute rules.
Policy
1) All changes to this policy are approved by the Director of the University Computing Service or his deputy.
2) Users are told about the IdP, and the fact that it may disclose information about them, the first time they use it to access a resource and at least annually thereafter. They are required to positively confirm that they accept the terms and conditions under which the IdP operates before proceeding and a record is made of this acceptance. On first access to a particular SP, users are made aware of the attributes that may be disclosed to it, along with their current values, and asked to approve this disclosure; this will be repeated at least annually and any time the list of attributes being disclosed to this SP changes. If the SP is a known member of the UK Access Federation, or a known University of Cambridge SP then it will be identified as such from our Access Federation data files. If it an unknown SP this will also be clearly declared.
3) The Shibboleth protocol requires that the SP have a copy of the University's Shibboleth metadata. This will be made available via HTTPS at https://shib.raven.cam.ac.uk/shibboleth for ad hoc use by SPs outside our set of known access federations.
4) The University institutional IdP provides three attributes to any SP that requests them. These are:
4.1) eduPersonScopedAffiliation with the appropriate value (e.g. member@cam.ac.uk, staff@cam.ac.uk, student@cam.ac.uk).
4.2) eduPersonTargetedID (an identifier allocated at random and distinct for each combination of user and SP, e.g. MlWd0XIR7juZvwvarOVdYiUWPW0=@cam.ac.uk)
4.3) eduPersonPrincipalName with the value crsid@cam.ac.uk
5) Values for any other attributes (in particular eduPersonEntitlement, a 'catch-all' container for values specified by particular SPs, for example cam#default0 used by EduServ Athens to grant general access through the Shibboleth to Athens gateway), may be released to any SP that can demonstrate a reasonable need, providing the corresponding user's identity can not be derived from these attributes or other information likely to be available to the SP. Each SP will only receive the particular extra attributes and values that it requires.
6) Other attributes from or derived from lookup, notably givenName (e.g. Fred), sn (e.g. Clark), cn (e.g. F.J. Clark), displayName (e.g. Fred Clark), ou (e.g. Department of Important Studies), instid (e.g. IS), mail (e.g. fjc55@cam.ac.uk) and groupID (e.g. 100123, 100987) may be released to SPs operating on servers that can already query lookup directly for the same information, but only subject to the user's choice of suppression in lookup.
7) Other than as mentioned above, attributes and attribute values are only disclosed where there is a demonstrable need and where there is adequate levels of protection for the data concerned. Release of such information is only permitted where there is no alternative.1 Each decision to allow or alter such a particular disclosure is approved by the Director of the University Computing Service or his deputy before it is implemented and recorded in the schedule to this policy.
Schedule
Attribute and attribute value disclosure approved under section 7 above:
- None
