Attribute Release Defaults for Web SSO ARP

Policies

As an adopter of the single sign-on authentication system, Shibboleth®, Brown University provides its computing users with the ability to log into a growing number of applications and services, both on- and off-campus, which share Shibboleth's federated identity standards.

To make appropriate authorization decisions during login, the Shibboleth System uses attributes sourced from Brown's LDAP-based (Lightweight Directory Application Protocol) directory services as the core units of identity data. (Note: These attributes are based on the Internet2/EDUCAUSE eduPerson directory schema.)

This document identifies the attribute release defaults for each of the distinct types of Service Provider (SP) groups used at Brown.

There are seven distinct types (or groups) of SPs in use at Brown, based upon the following factors:

System Administrators – referred to as owning party
Application Administrators – referred to as managing party
Level of assurance that SysAdmins are vetted (completed by the Director of Information Technology Security)

A group is considered "trusted" or "not trusted" depending on how closely the service is tied either to the central IT department (Office of Information Technology, OIT) or to the greater Brown computing environment, or the determined level of confidence in the proper vetting of the system administrators. The following is a breakout of the groups by level of trust.

Trusted

OIT owned and managed. Example: Today@Brown
OIT managed but department/Brown affiliate-owned. Example: Faculty Review System (Dean of the Faculty)
Department owned and managed (Director of Information Technology Security determines that application/server IS managed with appropriate personnel). Example: Center for Computation and Visualization (CCV) BrownBox or Computer Science applications
Contracted third party. Example: Workday

Non-Trusted

Department owned and managed (Director of Information Technology Security determines that application IS NOT managed with appropriate personnel). Example: some non-Computer Science departments
Brown affiliate owned and managed. Example: Critical Review
Third party federated.

Groups 1, 2 and 3 above have a strong trust level, and will have default data sent as listed below:

Opaque Identifier
Username
Net ID
eduPerson Principal Name
First Name
Last Name
Display Name
Title
Campus Email
Brown Type
Brown Status
Department
Member Of
Primary Affiliation
Brown Affiliation
eduPerson Primary Affiliation
eduPerson Entitlement

In addition, other attributes may be released by default if needed by the service provided and when approved. Any additional attributes deemed necessary would be released via uApprove only. The following would be covered in this group:

Brown Email Address
Fax Number
Telephone Number
Mobile Phone Number
Brown Barcode

Group 4 above will be limited to the minimum amount of data needed to cover authentication to and integration with the service provided.

Groups 5, 6 and 7 have a varied level of trust, and therefore will only receive an Opaque Identifier via Shibboleth by default. Other attributes could be released if needed but would be done so via uApprove only. The list of attributes is as follows:

Username
Net ID
eduPerson Principal Name
First Name
Last Name
Display Name
Title
Campus Email
Brown Type
Brown Status
Department
Member Of
Primary Affiliation
Brown Affiliation
eduPerson Primary Affiliation
eduPerson Entitlement
Brown Email Address
Fax Number
Telephone Number
Mobile Phone Number
Brown Barcode

Questions or comments to: ITPolicy@brown.edu

Last Reviewed: May, 2012