Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Suggestions for setting up services to use SSO.

TL;DR

  • Use attributes samlPairwiseID or samlSubjectID to identify users.

  • Entity ID should be a globally-addressable URL.

  • SAML certificates should be self-signed with a 10 year expiration.

User Identifiers

Do not use the “NameID” section of SAML assertions to identify users. Instead, use either the attribute samlPairwiseID or the attribute samlSubjectID.

The samlPairwiseID is unique for every service provider but based on the persistent PSU UUID. Because it is unique for every service provider, it is more difficult to misuse if stolen or sold. It is also scoped, having @pdx.edu appended.

The samlSubjectID is the PSU UUID with the @pdx.edu domain appended.

Both of these identifiers can be used to positively and consistently identify users. The samlSubjectID can also be used to correlate users with records in other institutional systems. Reach out to the Banner Integration Team for assistance with this.

Neither of these identifiers are very user-friendly or familiar, however, so when displaying an identifier to the user, uid (username), or eduPersonPrincipalName (an email-like identifier) are better choices.

We strongly recommend against using the mail attribute as it often is not “uid@pdx.edu” and can easily change due to email aliases or account renames. 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 that can also receive mail, use the eduPersonPrincipalName.

Refer also to “IAM Definitions: Identifiers”.

User Status

To determine if a user is “active” (i.e., a current student, employee or affiliate), use the multi-valuededuPersonScopedAffiliation attribute: All active users with a standard Odin account will have “member@pdx.edu”, along with other values 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.

To determine if a user is primarily a student or employee, use the single-valued eduPersonPrimaryAffiliation attribute: It will have “student”, “faculty”, “staff” or “affiliate”.

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.

Kindly refer to “IAM Definitions: Roles”.

Entity ID

The entity ID of a Service Provider or Identity Provider is the global identifier for the service. The entity ID thus should reflect a name that is globally unique, so it should not include a hostname like “localhost”.

SAML requires the entity ID to be a URI; previously it was common to use URNs but URLs are the currently recommended convention.

A URL used as an entity ID does not need to be a reachable destination. It is not uncommon, however, for the entityID to provide the entity’s metadata at the entityID URL.

Certificates

SAML uses X.509 certificates as a container for public and private keys. A Service Provider’s SAML certificates should not be the same as the certificate used for HTTPS for the application.

HTTPS uses a trusted-but-not-really-trustworthy-third party security model, so lifetimes are short (and they’ve gotten shorter and shorter as we have come to understand how untrustworthy many of these third parties are). SAML uses an explicitly arranged two-party trust model, so lifetimes can be longer – 10 years is typical. SAML certificates should also be self-signed, as most CAs will not issue certificates with 10 year lifetimes.

Certificates can be generated with the openssl req command:

openssl req -new -x509 -days 3652 -nodes -sha256 \
    -subj '/CN=https:\/\/app.example.com\/saml' \
    -addext 'subjectAltName=DNS:app.example.com,URI:https://app.example.com/saml' \
    -out saml-app.example.com.crt \
    -keyout saml-app.example.com.key
 Why “3652” days instead of “3650”?

There are 2 leap years in most 10-year time spans. (Most, because 2100 is not a leap year due to being divisible by 100 but not 400.)

The subject and subjectAltName (lines 2 & 3) are not necessary for Shibboleth or SAML in general, but the information can be useful for management.

Acronyms & Abbreviations

  • No labels