Shibboleth Integration for Service Providers


Shibboleth provides user authentication services for applications and a single sign-on experience for end-users. The UO Shibboleth Identity Provider (IdP) solution is maintained by Information Services and supports both Shibboleth and Central Authentication Service (CAS) integrations.

Once you configure your application as a Shibboleth Service Provider (SP), your end users can authenticate using their Duck ID username and password. In some cases, third-party, cloud-based solutions can also be integrated with the Shibboleth IdP.


Common Advantages

Shibboleth integration eliminates the need for you to manage usernames and passwords for your applications, allowing users to access your application using their centrally managed Duck ID username and password. The integration provides a common central login service for authentication, rather than having the username and password processed by each application. It also allows for single sign-on among applications, allowing the user to move from application to application without having to re-enter a username and password.


CAS provides proxy authentication by redirecting your application login to our CAS login service, where the user then authenticates using their Duck ID username and password.


Shibboleth provides authentication by redirecting your application login to our central Shibboleth login service where the user authenticates using their Duck ID username and password. Shibboleth also provides single sign-on among other Shibboleth-enabled applications.

For technical information regarding application integration with Shibboleth, please refer to the following article:

For further information regarding the campus population and available data elements, please refer to the following knowledge base categories and articles:

For more information, please visit the main Shibboleth page:

Choosing between CAS and Shibboleth

Information Services recommends Shibboleth where possible rather than CAS.

Since Shibboleth is the preferred solution for centrally managed services, if you want single sign-on capabilities with these services, you’ll need to use Shibboleth. In addition, even if you don’t think you need some of the Shibboleth specific functionality like attribute delivery now, you’ll be ready to add this in the future if it becomes a requirement.

Obtaining the IdP Metadata

The requestor provides the SP’s InCommon registered Entity ID or the metadata for their SP. They will configure the SP to rely on one of the following IdP InCommon registered Entity IDs or download and configure the metadata manually.

Testing Environment

The IdP includes both a Production and Test instance.

Start by requesting integration between your SP and the Test IdP. Please include the Duck IDs of all team resources that will be testing your SP against the Test IdP. After successful testing, request integration between your SP and the Prod IdP.

Releasing Attributes

When submitting your integration request, you will be able to select the unrestricted attributes you want the IdP to release alongside the assertion.

To request access to restricted attributes, please download, print, and fill out the Shibboleth Attribute Request Form. Complete Page 1 and sign and date Page 2. Data Steward Approval on the bottom of Page 2 should be left blank. Please submit the completed form using the service portal authentication request.

Request Integration

To request a new Shibboleth integration or request changes to your existing integration, please proceed to the UO Service Portal

Print Article


Article ID: 53856
Mon 5/14/18 3:19 PM
Thu 8/24/23 9:58 AM

Related Articles (1)

This article provides an overview of onboarding new services into using two-factor authentication (2FA), also referred to as multi-factor authentication (MFA), which enhances the security of Duck ID authentications for University of Oregon students and staff.