Web Single Sign-On (SSO) Attribute Release Policy
The purpose of this policy is to establish the University's requirements for single sign-on attribute release, in order to provide ease of use, federation, and awareness relative to the use of personal identity data for authentication, and to maximize the security of identity data while minimizing its misuse or theft.
It is important for the Brown community to know that the University shares identifying information, or "attributes", with others. The ability to share such information allows for seamless and secure access to the web pages of partner service providers (SP) without further authentication of the user.
Brown has announced itself as a Federated Authentication Identity Provider (IdP), and the transfer, release, and use of attribute information is central to the operation of Federated Authentication. However, attribute values may represent 'personal data' and are subject to protection, regulatory oversight, and mandatory compliance measures.
The University is dedicated to ensuring the privacy and proper handling of the identity data of its students, employees, and individuals associated with the University. The goal of this Attribute Release Policy (ARP) is to ensure that the necessary procedures and awareness exist for the use and release of identity data, while also enabling secure federation and authentication between Brown and its partners.
Brown University follows established best practices governing the release of personally identifiable information to service providers – be they internal Brown service providers, or external resources at another institution. Brown has identified several categories of service providers, and the attributes that may be released to service providers falling into each category. The release of additional available attributes may be requested by contacting the Shibboleth Administrator.
This policy applies to all users, computing resources, and applications owned or managed by Brown University. Individuals covered by the policy include (but are not limited to) Brown faculty and visiting faculty, staff, students, applicants, alumni, guests or agents of the administration, and external individuals and organizations accessing network services via Brown's computing facilities.
Computing resources include all university owned, licensed, or managed hardware and software, and use of the university network via a physical or wireless connection, regardless of the ownership of the computer or device connected to the network.
These policies apply to technology administered in individual departments, the resources administered by central administrative departments (such as the University Libraries and Computing and Information Services), personally owned computers and devices connected by wire or wireless to the campus network, and to off-campus computers that connect remotely to the University's network services.
- Brown University has the authority to share certain pieces of common identity data with verified sites at the university, and among trusted third parties via contractual agreements.
- By default, Brown will only release a unique identifier to 3rd party service providers. The unique identifier will be different for each service provider accessed by a user.
- For all Brown University identity data not covered by the provision above, users are told about the IdP, and informed that the IdP may disclose information about them, the first time they use it to access a resource. If there are any changes to this notice, users will be prompted to agree to the new notice.
- For 3rd party Service Providers that are federated with Brown via InCommon, or Brown sites that are not certified by the University Identity & Access Management Steering Committee (UIAMSC), the IdP will release first name, last name, email, university affiliation, and NetID scoped to Brown (e.g. Josiah_Carbury@brown.edu) with the consent of the user. On first access to a particular Service Provider (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 dialog screen will be repeated any time that the list of attributes or their values being disclosed to a particular SP changes.
- Other than as mentioned above, attributes and attribute values are only disclosed where there is a demonstrable need and where there are adequate levels of protection for the data concerned. Release of such information is only permitted where there is no alternative. Each decision to allow or alter such a particular disclosure must be approved by the UIAMSC before it is implemented and recorded in the schedule to this policy.
- Attribute values obtained through Federated Authentication are for the purposes of authorization and facilitation of the end user's session. They are not to be shared in any way and because these attributes are subject to change, they should not be stored locally.
Attribute – An attribute is a piece of information describing some aspect of a person's identity. Examples of attributes include, but are not limited to email address, University affiliation, name, library bar code, etc. Attributes may be asserted by an IdP to an SP and different attributes may be sent to different SPs.
Brown verified site/unverified site – Sites verified by the UIAMSC will have access to a wider array of attributes and/or not require user consent for the release of those attributes. Sites which have not been verified will require user consent for basic attribute release and committee permission for additional attributes.
Federation – A group of organizations that share a level of trust and work with each other to inter-operate, frequently defining a common set of shared attributes. Brown is a member of the US higher education federation, InCommon, and has created its own campus federation. There are many education, government, and potentially business federations throughout the world.
Identity Provider (IdP) – Every constituent of a federation must provide this service for the purpose of verifying the identity of users who belong to an institution on behalf of other federation members requesting identity verification. This is the "home institution" login component of Federated Authentication. The IDP also provides the important role of providing information (attributes) about users when prompted by service requests.
InCommon – InCommon is the U.S. higher education federation. Brown, as well as many peer schools and service providers that cater to the higher education sector, are members of InCommon and share a common infrastructure and language for defining interoperability and attributes.
Service Provider (SP) – A service provided by a federation constituent that a user might want to access, with access mediated by Shibboleth. May services are provided by commercial partners. However, increasingly collaboration sites supporting joint work and hosted by other campuses also manage access using Federated Authentication.
Shibboleth – Shibboleth provides for privacy protection through Attribute Release Policies (ARPs). Release of user attributes from an Identity Provider (IdP) to a Service provider (SP) is determined by the IdP's ARPs. ARPs contain a set of rules specifying which attributes to release. Shibboleth is an open source implementation of the OASIS SAML standard and the project has implementations of both the Service Provider and Identity Provider Software.
Shibboleth Administrator – The person or group responsible for managing the technical aspects of Shibboleth Infrastructure, in particular for configuring and implementing attribute release policies on the Identity Provider (IdP).
Attribute Release Policy
- Federated Authentication is designed to provide data about users (attributes) to authorized requesters.
- All Attribute Release is governed by Attribute Release Policy.
- An Attribute Release Policy is associated with an application (typically a URL).
Attribute Release Control
- Each Application has exactly one responsible party.
- A responsible party may have many applications.
- An Attribute Release Policy (ARP) may be assigned to many applications.
- An application may have more than one ARP.
- An ARP may release multiple attributes.
- An attribute may be released via many different policies.
Attribute Release Policy Control
- A request for an ARP for an application is made through the Shibboleth Administrator.
- XML is generated by Shibboleth IDP.
- XML is installed by Shibboleth SP.
- Simple policies
- Small set with large coverage
- Reduce the need for other access to enterprise systems
- Reduce the need for local storage of attributes
7.0 Related Policies and Links
- Adding a Service Provider (not yet created)
- Attribute Release Defaults for Web SSO ARP (current implementation specification)
Effective Date: May 1, 2011
Last Reviewed: May 7, 2012
Next Scheduled Review: May, 2014