IAM: Shibboleth

ARP

Attribute Release Policy

Shibboleth is designed to provide data about users (attributes) to authorized requestors
Attribute Release is governed by Attribute Release Policy
Attribute Release Policy is associated with an Application (typically a URL)
At UF, an application is associated with a Responsible Party via UFID.

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
Many attributes may come from a particular attribute source. Each attribute comes from exactly one source

Attribute Release Policy Control

Request ARP for an application through Application Security role
Approved Application is assigned a URN and binding of Responsible party, application and URN is recorded.
XML is generated by Shibboleth IDP
XML is installed by Shibboleth SP
Test and refine as needed

ARP Goals

Simple policies
Small set with large coverage
Reduce the need for other access to enterprise systems -LDAP piercing, UF DIR API
Reduce the need for local storage of attributes
Facilitate simple applications

ARP Notes

Each attribute is vended from a known, single source regardless of ARP. The source for each attribute is described in a separate document.
ARP-LOA and ARP-GLID can be used to provide current GLAUTH capability.
Attribute values obtained through Shibboleth are for the purposes of authorization and facilitation of the end user's session. They are not to be stored locally or shared in any way.
If additional attributes or attribute release policies are needed, please contact the IAM office. We will work with you to make sure you have the information you need for your application.
Many applications will need more than one ARP. This does not add complexity to the service provider -all attributes returned by Shibboleth come in a single set regardless of the number of ARPs involved.
If we find that a group of ARPs are commonly requested together, we may choose to provide "combo" ARPs to simplify administration.

Shibboleth Attributes Released with Each ARP

Each attribute is declared as a CGI variable. The name of the CGI variable is shown below in parentheses following the attribute name. Some web servers will prepend "HTTP_" to the variable names.

ARP-CID

Used by applications which need to track user preferences and data between sessions.

Computed ID (persistent-id)

Computed ID(CID) is an opaque identifier which cannot be reverse engineered by the recipient. The IDP can identify an individual from a CID for law enforcement purposes.
The CID is vended for supporting end user settings at the application level. It should be stored and used as a primary key for applications that need to "remember" preferences for end users. Information provided by end users to the application can be stored and keyed using CID.
CID does not change for a particular individual using an application.

ARP-LOA

Used by applications that need to know the level of assurance of the individual requesting service.

Level of Assurance (loa)

Level of Assurance(LOA) indicates the certainty of the association of an individual and an identity. UF currently uses two values: 1 for "weak identity" -these are individuals whose identity is self-reported. A particular individual may have more than one identity. Think "yahoo". Level 2 is our standard business practice. Many intake processes result in LOA 2 identity.

ARP-Affiliations

Primary Affiliation (primary-affiliation)
EduPerson Affiliation (eduperson_affiliations)
UF Affiliations (uf_affiliations)

EduPerson and UF Affiliations are potentially multi-valued. All values for the individual are returned.
Use of affiliations for controlling access to resources is sufficient for many applications. Applications that need to restrict access to "faculty, staff and students" should use the EduPerson Affiliations and obtain a consistent result with other applications across campus. This consistency is important to the end user.
Use of affiliations as surrogate for roles can be problematic. Roles provide fine-grained control of access and can be added and removed based on need. Affiliations cannot be added and removed -affiliations are "facts" about a person. They cannot be manipulated for access control purposes. For example, if an application authorizes "students," but an honor court or other restriction must be put in place for a particular student, the student affiliation cannot be removed to satisfy the access requirements. Roles can be removed in such cases. Managing access by roles is preferred when exceptions are common. Managing by exception (all students other than those on an application exception list) is preferred when exceptions are rare.

ARP-GLID

Provides the "named list of users" functionality of GLAUTH allow=(x, y, ..,z). Units are encouraged to move to alternate methods of authorization. Maintaining named lists of users requires significant effort. GatorLink Usernames can change leading to unauthorized access. Many other groupings of users are available which may be preferable.

GatorLink username (glid)
UF Business Email Address (mail)

The GatorLink username is 1-16 characters. It does not contain "@ufl.edu". It is not an email address. To contact the user via email, always use the business email address. Never construct an email address from the GatorLink username.
The UF Business Email Address value is provided for all users. It may be blank for some users.

ARP-UFID

Some processes require UFID for authorization, identification and matching to other university processes.

UFID (ufid)

The UFID is protected information and is not displayed outside the transaction in which it occurs.
The UFID is not required for many transactions. Requests for UFID will be reviewed regarding intended purpose.
The UFID does not change and is never reused.
Keying data systems on UFID is strongly preferred over keying systems on GLID. Applications that do not need to share data about individuals should use CID to preserve privacy and avoid contact with unnecessary protected information.

ARP-Roles

Provides information needed to authorize Staff and Members

PeopleSoft Roles (UFAD_PSRoles)
Dept ID (departmentNumber)
Network Managed By (netmanaged_by)

PeopleSoft roles are multi-valued. Many people have over 50 such roles each.
The primary department ID is the "derived HR Home" of an employee.
Network Managed By indicates the unit managing an employee's workstation and file access.

ARP-Groups

UFAD Groups (UFAD_Groups)

Departments can create and manage groups in Active Directory. This can be used for a wide variety of applications.
These groups are not to be redundant with other groupings such as membership in roles, affiliations, course sections.

ARP-Contact Information

EduPerson Principal Name (eppn)
Directory Name (cn)
Business Name (businessName)
Given Name (givenName)
Surname (sn)
Middle Name (middleName)
Postal Address (postalAddress)

The university maintains many kinds of contact information for individuals. A separate document describes the various kinds of contact information and when each is appropriate.

Proposed and Future Attributes

ARP-Certifications (proposed)

Certifications

The certifications are expected to be one field, multi-valued, containing all certifications.
This ARP may not be needed if all certifications are implemented as roles or arbitrary groups.

ARP-Enrollment (future)

Provides information required to authorize student access. It may be possible to handle term information if the UFID is not also present. UFID and term information together would constitute FERPA protected information.

Term / Course / Section(s)

Term/course/section numbering is per university standard.

ARP-Academic Structure (future)

College
Major(s)
Minor(s)
Classification

All academic structure information is current as of the login of the user. Academic structure is empty for non-students.
College is the college offering the degree the student is seeking.
Classification is of the form "3LS," where the digit represents program level and the characters represent program.

OIT

University of Florida

ARP