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

1. OIT owned and managed. Example: Today@Brown
2. OIT managed but department/Brown affiliate-owned. Example: Faculty Review System (Dean of the Faculty)
3. 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
4. Contracted third party. Example: Workday

Non-Trusted

5. Department owned and managed (Director of Information Technology Security determines that application IS NOT managed with appropriate personnel). Example: some non-Computer Science departments
6. Brown affiliate owned and managed. Example: Critical Review
7. 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

• Introduction to Shibboleth, Attributes and Federations
• Internet2/EDUCAUSE eduPerson Directory Schema
• About Shibboleth (Web Authentication) at Brown
• Brown's Shibboleth Login Page
• Attribute Release Policy for Web Single Sign-On (SSO)