Versions Compared

Version Old Version 10 New Version 11
Changes made by

Wil Cooley

Wil Cooley

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

  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.

  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.

...

Organization: Portland State University

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

Member of InCommon: Yes

Identity Provider (IdP): Shibboleth 4.0

...

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.

Friendly Name

SAML v2 Name

Description

psuuuid

urn:oid:1.3.6.1.4.1.34509.1.2.2.4

Universally unique identifier

uid

urn:oid:0.9.2342.19200300.100.1.1

Odin username

mail

urn:oid:0.9.2342.19200300.100.1.3

Email address

sn

urn:oid:2.5.4.4

Last namegiven_name

givenName

urn:oid:2.5.4.42

First namedisplay_name

displayName

urn:oid:2.16.840.1.113730.3.1.241

Full name

eduPersonPrimaryAffiliation

urn:oid:1.3.6.1.4.1.5923.1.1.1.5

Primary role

eduPersonScopedAffiliation

urn:oid:1.3.6.1.4.1.5923.1.1.1.9

List of roles with domain scope

eduPersonPrincipalName

urn:oid:1.3.6.1.4.1.5923.1.1.1.6

Scoped uid, i.e., odin@pdx.edu

eduPersonEntitlement

urn:oid:1.3.6.1.4.1.5923.1.1.1.7

List of entitlements permitting access for a limited number of cases.

UDC_IDENTIFIER†

urn:oid:udc-identifier-oid

Banner identifier

eduPersonAffiliation†

urn:oid:1.3.6.1.4.1.5923.1.1.1.1

List of roles

employeeNumber†

urn:oid:2.16.840.1.113730.3.1.3

Banner 9-number/Spriden ID, used for student ID also.

eduPersonTargetedId

urn:oid:1.3.6.1.4.1.5923.1.1.1.10

Universally unique identifier (note that we provide this as a simple string format, rather than the “NameID” format some vendors require)

...

Odin usernames are occasionally renamed due to special circumstances. Administrators of SSO enabled applications should subscribe to the OIT account rename notification list.

This will allow you to handle account renames in your application if necessary.

...

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

...

We strongly recommend against using the mail attribute as it often is not “uid@pdx.edu” 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.

...

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.