Use Shibboleth Service Provider software for single sign-on

For customers using Apache or Microsoft IIS web servers, Shibboleth Service Provider (SP) software is free and open source software, developed by and for the research and education community, that supports single sign-on (SSO), federation, and social login. Unlike other SAML software, Shibboleth SP software is integrated and configured in Apache or IIS, rather than being built into your application code.

Want some help? Need help using Shibboleth Service Provider software for single sign-on with the UW Shibboleth Identity Provider? Contact us for help.

Identity provider entityID and metadata

"urn:mace:incommon:washington.edu" is the entityID for the UW 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 you rely only on the UW Shibboleth IdP-and have no plans to authenticate users from other organizations-we recommend configuring Shibboleth to consume our local metadata.
If you authenticate users from the UW as well as other identity providers in the research and education community, we recommend configuring Shibboleth to consume InCommon per-entity metadata. Both include metadata for the UW IdP and other identity providers.
If you additionally rely on authenticating users through social login (Google, Facebook, etc.), Shibboleth SP software can consume metadata from multiple sources, including configuring it to rely on the UW Social-to-SAML Gateway.

Metadata refresh

Regardless how you consume the UW Shibboleth IdP 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. Shibboleth SP software defaults to refreshing metadata every two hours.

Installation, configuration, and registration

Installation and configuration Refer to the installation and configuration guides in our Shibboleth SP support wiki.
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.
Self-service registration process Shibboleth SP software works well with the self-service registration process described in our installation and configuration guides. Only authorized operators can register and update SP metadata using the UW Service Provider Registry, where authorization is based on ownership and control of the DNS name in your entityID.

Attribute release

What attributes are available? Shibboleth SP software is compatible with a variety of identifiers, attributes, and SAML NameID formats available from the UW Shibboleth IdP. Refer to the "attribute topics" in our wiki.
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.

SAML authentication

How to initiate authentication Our installation and configuration guides describe basic configuration needed to initiate authentication using Shibboleth on Linux and Windows.
How to request multi-factor authentication Shibboleth SP software supports configuration for the REFEDS MFA Profile used by the UW Shibboleth IdP for multi-factor authentication. Refer to the "session management topics" in our wiki.
How to force reauthentication Shibboleth SP software supports reauthentication too. Excess reauthentication can annoy users, so use it judiciously. Refer to the "session management topics" in our wiki.

Access control

Shibboleth SP software supports a variety of ways to implement access controls based on user attributes provided by the UW Shibboleth IdP. Refer to the "access control topics" in our wiki.

Logout

Single logout isn't supported Although Shibboleth SP software offers single logout features, the UW Shibboleth IdP doesn't support the SAML 2.0 Single Logout Profile.
Local logout and timeouts Shibboleth SP software supports configuration to enable a local logout mechanism and to coordinate between logout and timeouts. Refer to the "session management topics" in our wiki.
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

Shibboleth software announcements All customers who rely on Shibboleth SP software should subscribe to the Shibboleth consortium's official "announce" mailing list. This is a low traffic list used to announce new releases and security advisories.
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 Identity Provider doesn't implement SIRTFI yet.
Identity provider key rollovers Shibboleth SP software supports multiple certificates (signing keys) for a single entity in IdP metadata, and therefore can seamlessly handle rare occasions when we need to change the certificate we publish in the UW Shibboleth IdP metadata. This is known as a "key rollover".

Related information

General information for SAML integration If you're curious what information we provide to customers using other SAML 2.0 software besides Shibboleth, refer to Use SAML 2.0 for single sign-on.