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