Use SAML 2.0 for single sign-on

The UW Shibboleth Identity Provider (IdP) supports SAML 2.0 for single sign-on (SSO) with UW NetID. This page describes how to register and configure SAML service provider software to rely on the UW IdP using SAML 2.0. For similar assistance with UW Entra ID, see Entra ID Application Integration Guide – IT Connect (uw.edu).

Identity provider entityID and metadata

“urn:mace:incommon:washington.edu” is the entityID for the UW Shibboleth Identity Provider (IdP). We provide several ways to download and refresh our IdP metadata.

• Local metadata
  A local copy of the UW Shibboleth IdP metadata is available at https://idp.u.washington.edu/metadata/idp-metadata.xml
• InCommon federation metadata
  The UW is a member of the InCommon federation and the UW Shibboleth IdP metadata can be consumed from InCommon Metadata; options include their per-entity metadata distribution service and metadata file download.
• eduGAIN
  The UW Shibboleth IdP metadata is exported to eduGAIN and can be found in other national federations that import metadata from eduGAIN. Use the Metadata Explorer Tool to learn more.

Metadata consumption

• If your SAML software can consume InCommon federation metadata, we recommend doing so. It includes metadata for the UW Shibboleth IdP.
• If your SAML software can only consume metadata files with one entity—and therefore can’t consume InCommon federation metadata, which includes several hundred entities—we recommend using our local metadata or the InCommon per-entity metadata.
• If your SAML software can’t consume a metadata file and must be configured manually, use the information in our local metadata file to do so. Because a manual configuration remains static, it has the drawback of requiring manual updates for key rollovers and other changes.

Metadata refresh

If you consume our local UW Shibboleth IdP metadata, InCommon federation metadata, or InCommon per-entity metadata, we recommend you refresh and verify the metadata at least daily. Doing so can help prevent service disruptions due to key rollovers and other changes to our IdP metadata.

Service provider registration

• Choose an entityID you own
  Your entityID is a permanent, unique, public identifier that identifies your service to the UW Shibboleth IdP (and potentially other IdPs). We strongly recommend choosing an entityID formatted as a URL that includes a DNS name you own and control. For example, “https://service.uw.edu/saml”. The URL doesn’t have to resolve to an actual web resource; its purpose is to be a unique string that accurately represents ownership.
• Requirements
  All service providers must register a valid entityID and at least one AssertionConsumerService (ACS) endpoint protected by SSL/TLS. We require at least one registered contact email address, and recommend technical, administrative, security, and support contacts, preferably using addresses that deliver email to appropriate teams rather than individuals. If you plan to register a public certificate—because you sign your SAML authentication requests—the public certificate and private key necessary for signing can be self-generated. However, a key length of at least 2048 bits is required, and the certificate must be in PEM format.
• Self-service registration process
  The UW Shibboleth IdP supports self-service registration of service provider (SP) metadata using the UW Service Provider Registry. Only authorized operators can register and update SP metadata, where authorization is based on ownership and control of the DNS name in your entityID.
• Vendor product registration
  If you’re working with a vendor that provides services to the research and education community, we recommend they join InCommon and register their service through the federation. We can sponsor vendors into InCommon. If a vendor doesn’t plan to join InCommon, their SP metadata can be registered directly with the UW IdP using self-service registration. We can advise you and the vendor on registration, including appropriate technical and administrative contacts, but we expect you will maintain the vendor relationship.

Attribute release

• How to request attributes
  By default, the UW Shibboleth IdP releases a small set of attributes to any service provider registered in UW DNS with a domain name ending in washington.edu or uw.edu. All other attributes must be requested and approved through service provider registration using the UW Service Provider Registry. Request only the attributes needed to operate your service.
• What attributes are available?
  The UW Shibboleth IdP supports a variety of identifiers, attributes, and SAML NameID formats. We use the SAML X.500/LDAP attribute profile. Some attributes are multi-valued. Some attribute values can be used in NameID values. The default format for NameID values is a Transient NameID, but an alternate format can be requested.
• Research & Scholarship (R&S) Entity Category
  The UW Shibboleth IdP supports the R&S Entity Category, and releases the standard set of attributes to any service provider in InCommon or eduGAIN designated with the R&S entity category in the InCommon federation metadata.

SAML authentication

• SAML interoperability profile
  The UW Shibboleth IdP is interoperable with software adhering to version 2.0 of the SAML V2.0 Interoperability Deployment Profile.
• How to initiate authentication
  The UW Shibboleth IdP supports standard SAML 2.0 mechanisms for initiating authentication, including SP- and IdP-initiated flows. We recommend SP-initiated flow. If you can only use IdP-initiated flow, we recommend you create and host a location where users can start the authentication process.
• How to request multi-factor authentication
  The UW Shibboleth IdP supports multi-factor authentication (MFA) by including a standard authnContextClassRef attribute in your SAML authentication request. The UW Shibboleth IdP supports the REFEDS MFA Profile and therefore the value of the authnContextClassRef attribute should be “https://refeds.org/profile/mfa”. Service providers must verify the SAML response to ensure MFA was performed.
• How to force reauthentication
  The UW Shibboleth IdP supports reauthentication by including and setting the standard forceAuthn attribute in your SAML authentication request. However, excess reauthentication can annoy users, so use it judiciously.
• Signing and encryption
  The UW Shibboleth IdP supports signed authentication requests and can encrypt assertions. By default, the UW Shibboleth IdP signs the overall SAML response, not each SAML assertion. If your service expects the SAML assertion(s) to be signed and/or encrypted, we can configure this as a special case. Learn more.

Logout

• Single logout isn’t supported
  The UW Shibboleth IdP doesn’t support the SAML 2.0 Single Logout Profile.
• Local logout
  If your service supports a local logout mechanism, display a message to users saying they should quit their browser if they’re finished browsing. Optionally, redirect users to “https://idp.u.washington.edu/idp/logout” and it will display a consistent message to users.
• Logout, single sign-on, and reauthentication
  If you are concerned that single sign-on allows users back into your service, even after using your local logout mechanism, you might consider reauthentication. Forcing reauthentication can reduce the risk of unauthorized access to sensitive data and operations when a user has a valid single sign-on session and leaves their computer unattended and unlocked. With reauthentication, even users who have a valid single sign-on session will be forced to authenticate again.

Other operational practices

• Service announcements and customer notifications
  We send email to the contacts provided during service provider registration to communicate information about outages, upgrades, and other changes, as well as notifications related to SP metadata registration, updates, and attribute requests.
• Security incident response
  If your service is involved in a security incident involving use of SAML and the UW Shibboleth Identity Provider, normal reporting and security incident response apply. If you plan to adopt the Security Incident Response Trust Framework for Federated Identity (SIRTFI), please contact us; the UW Shibboleth Identity Provider doesn’t implement SIRTFI yet.
• Identity provider key rollovers
  Occasionally, we may need to change the certificate we publish in the UW Shibboleth IdP metadata. This is known as a “key rollover”. It’s the process by which our current certificate is replaced by another certificate. If your SAML software supports multiple certificates (signing keys) for a single entity in IdP metadata, the transition may be seamless. If not, we will rely on the contact information provided during service provider registration to minimize service disruption during a key rollover.