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.
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.