| Table of Contents |
|---|
...
With the vendor’s support or documentation:
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.Determine if SAML or CAS will be used.
Some applications only offer one option. If there is a choice, SAML is recommended.Determine if attributes are needed in addition to the attributes released by default.
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.Configure a test instance.
We recommend using a test application instance 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.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)
...
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.
Production | |
|---|---|
Entity ID | https://sso.pdx.edu/idp/shibboleth |
Metadata | https://sso.pdx.edu/idp/shibboleth |
Login URL | https://sso.pdx.edu/idp/profile/SAML2/Redirect/SSO |
Logout URL | https://sso.pdx.edu/idp/profile/Logout |
Stage | |
|---|---|
Entity ID | https://sso-stage.oit.pdx.edu/idp/shibboleth |
Metadata | https://sso-stage.oit.pdx.edu/idp/shibboleth |
Login URL | https://sso-stage.oit.pdx.edu/idp/profile/SAML2/Redirect/SSO |
Logout URL | https://sso-stage.oit.pdx.edu/idp/profile/Logout |
...
CAS configuration
CAS protocol version: 2.0
Production | |
|---|---|
Server | sso.pdx.edu |
Port | 443 |
CAS URI | https://sso.pdx.edu/idp/profile/cas |
Logout | https://sso.pdx.edu/idp/profile/Logout |
CASLoginURL | https://sso.pdx.edu/idp/profile/cas/login |
CASValidateURL | https://sso.pdx.edu/idp/profile/cas/serviceValidate |
CASProxyValidateURL | https://sso.pdx.edu/idp/profile/cas/proxyValidate |
Stage | |
|---|---|
Server | sso-stage.oit.pdx.edu |
Port | 443 |
CAS URI | https://sso-stage.oit.pdx.edu/idp/profile/cas |
Logout | https://sso-stage.oit.pdx.edu/idp/profile/Logout |
CASLoginURL | https://sso-stage.oit.pdx.edu/idp/profile/cas/login |
CASValidateURL | https://sso-stage.oit.pdx.edu/idp/profile/cas/serviceValidate |
CASProxyValidateURL | https://sso-stage.oit.pdx.edu/idp/profile/cas/proxyValidate |
...
Attributes
Attributes are user data that are released by Shibboleth to the application upon successful login.
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 |
urn:oid:0.9.2342.19200300.100.1.3 | Email address | |
sn | urn:oid:2.5.4.4 | Last name |
given_name | urn:oid:2.5.4.42 | First name |
display_name | 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 |
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) |
† Available upon request
...
...
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.
...
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.
This will allow you to handle account renames in your application if necessary.
...
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.
Note also that mail is often not “uid@pdx.edu” due to the possibility of aliases. Also, the domain for mail is different between production and non-production environments: @pdx.edu for production and @gtest.pdx.edu for stage.
...
How do I determine if a user is active?
To determine if a user is a current student or employee, use the eduPersonScopedAffiliation role.
...
Inactive users will not have “member@pdx.edu” among those roles; do not use the presence of “none@pdx.edu” 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, so validating active users is required; do not assume that a user successfully authenticating with SSO means this is an active student or employee!
...
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.