Overview
The purpose of this article is to:
- Provide brief background information about federated identity management, the InCommon Federation, Shibboleth, and attributes.
- Describe the procedure for asking the University of Pittsburgh to release user attributes via Shibboleth to external institutions. The release of these attributes is necessary to allow University users to access resources at external institutions.
- Explain the procedure for reviewing and approving the release of user attributes.
Detail
About Federated Identity Management
Federated identity management makes life easier for people who use web-based resources across institutions. It gives them access to multiple websites that require a login without requiring them to remember multiple IDs and passwords.
With federated identity management, institutions join together in a group–a federation–and agree to trust each other's identity credentials. It is kind of like when banks allow you to use your ATM card at the ATM of a bank where you do not have an account.
The University of Pittsburgh, for example, is a member of the InCommon Federation. This means that InCommon members agree to trust the University of Pittsburgh to vouch for the identity of someone who has logged in using the University's web authentication method.
The University of Pittsburgh has agreed to trust other InCommon members when they vouch for the identity of people who have logged in using their authentication methods. These institutions share additional identity information, called "attributes," to allow them to make authorization decisions.
Federations use federated identity management software to vouch for their users' identities and share information about whether those users meet the authorization requirements for a particular service. One example would be a license that limits access to students.
About Shibboleth
The InCommon Federation uses Shibboleth federated identity management software from Internet2. According to Internet2:
"Shibboleth is a standards based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner."
Shibboleth has two primary components:
- Identity Provider (IdP): The Internet2 website describes an IdP as, "the software run by an organization with users wishing to access a restricted service." The University of Pittsburgh IdP, which is run by Pitt IT, can be configured to interact with each service that University of Pittsburgh users wish to access via Shibboleth.
- Service Provider (SP): Internet2 describes a SP as, "the software run by the provider managing the restricted service." At this time, Pitt IT is only offering an IdP. Any single sign-on applications should be established through my.pitt.edu.
About Attributes
Attributes are specific bits of information about people. They include such things as a person's name and email address. There are established attributes with specific names that are used for federated identity management. Also, institutions can create their own attributes.
Attributes can be used:
- To determine if someone is authorized to use a particular service. For example, a particular service might be provided only to faculty members.
- To customize services for people after they have logged in. For example, once you are logged in, a service page may greet you by name and show you a customized menu based on what you are authorized to use.
A basic set of attributes has been pre-approved for release to SPs that are members of the InCommon Federation. Requests for release of additional attributes to InCommon Federation members must go through an approval process.
Attributes Pre-Approved for University of Pittsburgh Release to InCommon Member Service Providers
The following attributes are pre-approved by the University of Pittsburgh for release, upon confirmation by the user, to Shibboleth-enabled Service Providers (SPs) that are members of the InCommon Federation. It is not necessary to submit a request for attribute for these attributes. No additional configuration is needed. No additional configuration should be necessary on the University of Pittsburgh's IdP, so users should be able to log in to these services.
- eduPersonPrincipalName: This is username@pitt.edu, where username has been replaced with the person's actual username. CDS is the authoritative source for username information. The username is pulled from the CDS username attribute. Then @pitt.edu is added to it.
- mail: This is the individual's advertised email address.
- eduPersonScopedAffiliation: The affiliation information is determined by the enterprise role associated with the individual in CDS. One or more of these values is/are returned: student, faculty, staff, employee, and member. CDS determines an individual's role based upon information provided by the payroll and student information systems.
The table below shows how the individual's role at the University maps to the controlled-vocabulary values required by eduPersonAffiliation.
| Role |
eduPersonAffiliation |
| Active Students |
student |
| Faculty Members |
faculty |
| Full- and part-time staff (except student employees) |
staff |
| Any faculty or staff role |
employee |
In addition to the controlled vocabulary choices, the schools or department(s) the person is affiliated with is added to the eduPersonScopedAffiliation attribute. The standard abbreviation concatenated with @pitt.edu for each school or department. The standard department abbreviation is determined from DED table T18205 for Schools and T18321 for Departments.
- displayName: This is displayName attribute for the user account. It is either set within CDS or calculated to be Lastname, Firstname. If the individual is excluded from the public directory, then the value for this None.
- givenName: This is the individual's first name. If the individual is excluded from the public directory, then the value for this None.
- sn: The individual's last name or surname. If the individual is excluded from the public directory, the value for this None.
- eduPersonTargetedID: This is a unique string assigned by the Shibboleth service per user per service. It is made up of numbers, letters, and other characters and contains no personally identifiable information. It is used as an identifier when anonymous access is desired. You might use this when an SP needs to know that the person is allowed but doesn't want which library resources a particular person accessed to be tracked. It is calculated by hashing the username and a salt value to produce a hash.
Requesting that University of Pittsburgh Withhold Specific Attributes
When the SP is set up in the IdP, it can be requested that any of the auto-release attributes above be withheld from a particular InCommon member SP. There are situations in which you may not want the SP to have the user's name, email address, or other identity information. For example, an SP providing library resources may not want to be able to connect use of a particular resource with a particular user. Knowing that the user is a member of the University of Pittsburgh and therefore entitled to use the resource may be all the SP needs, and wants, to know.
To request that an attribute be withheld from an SP, contact the Technology Help Desk.
Requesting University of Pittsburgh Release of Additional Attributes
IMPORTANT! Please submit your request as soon as you know you will need the release of additional attributes beyond the ones that are pre-approved for release. That will give Pitt IT time to do the work needed to review and implement your request.
In general, an attribute will not be released unless there is a business reason for its release. If you request the release of an attribute, please be sure that there is a real need for its release.
To have additional attributes released to an InCommon member SP, a request must be made to the Technology Help Desk. The request will then be forwarded onto the technical area responsible for the Shibboleth IdP set up. This area will assess the request and inform the requestor whether it can be implemented.
How Requests Will Be Handled
Pitt IT will review requests for the release of additional attributes for technical feasibility and completeness. If the team members have questions about your attribute release request, they will contact you. Both the review process and the set up for attribute release are iterative, and you may be asked for clarification or additional information at any point in the process.
If the attributes you are requesting fall under established review procedures, they will pass your request on to the appropriate data steward(s), manager(s), or review group.
Straightforward requests may be approved within a few business days and implemented in just a few more days after that. Changes to the Shibboleth IdP will only be performed during the weekly maintenance period (Saturday at 11:00 p.m. to Sunday at 7:00 a.m.).
Complex or difficult requests may take several weeks for approval and several more weeks after that for set up. If new data feeds need to be established, custom programming will be needed. If several units/institutions need to coordinate with each other, considerable time may be needed. Please take this into account when creating your project plan and allow sufficient time.