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 2 Next »

TL;DR

  • Entity ID should be a globally-addressable URL.

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

  • Use attributes samlPairwiseID or samlSubjectID to identify users.

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.

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.

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.

Refer also to “IAM Definitions: Identifiers”.

Acronyms & Abbreviations

  • No labels