Getting started with PSU Single Sign-On

Introduction and audience

PSU provides Single-Sign On (SSO) to authenticate and identify institutional users for web-based applications. The Shibboleth Identity Provider supports SAML and CAS protocols to provide this service. This document provides essential details required to configure an application to authenticate users with PSU’s SSO service.

While the “Steps to implement” section is guidance accessible to institutional administrative staff who might be evaluating or on-boarding a new application, this document is intended primarily as a reference for technical staff and, as such, includes terms and acronyms without further elaboration that said staff are assumed to be familiar with or that appear commonly on vendor’s intake forms.

Steps to implement

1. With the vendor’s support or documentation:

   1. Determine if accounts can be provisioned upon login or accounts must be created beforehand.
      Some vendors are able to automatically create accounts for any unknown user upon successful login, sometimes called “Just-In-Time” (JIT) provisioning, while other vendors require accounts to be created before users are able to login. For the latter case, arrangements need to be made outside of SSO, such as with an integration by IAM or Banner/Enterprise Solutions, manual account creation, etc.

   2. Determine if SAML or CAS will be used.
      Some applications only offer one option. If there is a choice, SAML is recommended.

   3. Determine if attributes are needed in addition to the attributes released by default.

2. Complete the PSU Single Sign-On Application Request Form. Provide information to the vendor about PSU’s SSO configuration.
   Contact OIT's Identity and Access Management (IAM) team for assistance with the vendor’s forms or questionnaires for implementing SSO.
   From the vendor, we need either:

   1. The SAML metadata for the Service Provider.

   2. Data required for us to create SAML metadata, viz.:

      1. One or more URLs for Assertion Consumer Service endpoint.

      2. Zero or more public keys/certificates for signing and encryption.

3. Configure a test instance.
   We recommend using a test application instance using our stage environment to get the application working with the SSO testing environment. If possible, keep the test instance to validate future SSO changes before they are moved to production.

   If troubleshooting is called for, IAM might ask to point to our development environment. Unless your application provides three different environments, do not configure for this environment unless requested.
   Note that only our production identity provider has metadata published through InCommon Federation; non-production instances will require manually importing metadata.

4. Configure a production instance.
   Use the production information below to configure a production instance of the application.

Information requested by vendors

Organization: Portland State University

Contact: IAM Team <oit-iamteam-group@pdx.edu>

Member of InCommon: Yes

Identity Provider (IdP): Shibboleth 4.0

SAML configuration

SAML version: 1.1, 2.0 (preferred)

SP-Initiated or IdP-Initiated: SP-Initiated (only)

Service Providers registered with InCommon usually require only PSU’s entity ID and no further configuration for PSU’s SSO.

Service Providers not registered with InCommon require either SAML metadata or URLs of protocol endpoints/bindings. In either case, PSU’s SSO requires explicit configuration with the metadata provided by the SP or by creating metadata from the SP’s protocol endpoints.

CAS configuration

CAS protocol version: 2.0

Attributes

Attributes are user data that are released by Shibboleth to the application upon successful login. See the eduPerson standard for more detailed descriptions of most of these. For identifiers, see the Shibboleth concepts document NameIdentifiers and the SAML Subject Identifier specification, especially the “Problem Statement” section.

^† Available upon request with suitable business case.

Logout

We consider it a best practice to perform logout by destroying application session cookies and then destroying the user's SSO session by forwarding them to the SSO logout endpoint. This prevents accidental re-authentication in your application with the remaining sso.pdx.edu session cookies.

We do not, however, support true single-logout due to it being technically infeasible. The logout URLs documented above end the user’s session with the Identity Provider but previously-authenticated sessions with applications remain valid.

Odin username changes

Odin usernames are occasionally renamed due to special circumstances. Administrators of SSO enabled applications should subscribe to the OIT account rename notification list if tracking username changes is necessary for your application.

Using one of the persistent, opaque attributes for an identifier, such as samlPairwiseID or samlSubjectID, and tracking uid changes like any other attribute is preferable to having to maintain usernames.

Test accounts

Often a vendor will request a test account for use in setting up SSO. We do not currently have test accounts in production, but departments can set up affiliate accounts for vendors. Learn more about affiliate accounts.

Frequently asked questions

What attribute should be the primary identifier to correlate logins with accounts within my application?

We suggest using psuuuid as the primary identifier, rather than uid (username) or mail. Both uid and mail can change — the former in the case of an account rename and the latter in the case of rename or the user requesting an alias.

We strongly recommend against using the mail attribute as it often is not “uid@pdx.edu” and can easily change due to the possibility of email aliases. Also, the domain for mail is different between production and non-production environments: @pdx.edu for production and @gtest.pdx.edu for stage. If the vendor or application insists on an attribute formatted like an email address, use the eduPersonPrincipalName.

How do I determine if a user is active?

To determine if a user is a current student or employee, use the eduPersonScopedAffiliation role.

All users with a standard Odin account will have “member@pdx.edu”, along with other affiliations like “student@pdx.edu” or “employee@pdx.edu”.

Provisional, limited lifetime and inactive users will not have “member@pdx.edu” among those roles; do not use the presence of “none@pdx.edu” as an indication that the user is inactive, as this is the result of a limitation of a part of our identity management systems and should not be relied upon.

Note that in order to access records via Banweb, all users have accounts for life and are able to authenticate via SSO. Furthermore, provisional accounts can be created by anyone with nothing more than an external email address – these are also able to authenticate via SSO. Validating active users is mandatory; do not assume that a user successfully authenticating with SSO means this is an active student or employee! The Identity Provider cannot restrict these accounts from your application.

What are the possible values for eduPersonAffiliation, eduPersonPrimaryAffiliation, eduPersonScopedAffiliaton?

These attributes use a controlled vocabulary from the eduPerson specification. Permissible values are faculty, student, staff, alum, member, affiliate, employee, library-walk-in. Read an explanation of what these values mean as part of the eduPersonAffiliation definition.

The scope of eduPersonScopedAffiliation attributes will usually be “@pdx.edu”. Due to programs such as co-admission with other local institutions, there may be values with other scopes, such as “student@ohsu.edu”; however, anyone eligible for student benefits at PSU will also have “student@pdx.edu”.

To distinguish between regular employees and student workers, however, use the single-valued eduPersonPrimaryAffiliation. Both cases will have eduPersonScopedAffiliation value “employee@pdx.edu” (and regular employees who are also part-time students will have “student@pdx.edu”); however, student workers will have eduPersonPrimaryAffiliation value of “student” and regular employees will have “faculty” or “staff”.