SA¹ú¼Ê´«Ã½

What is SSO?

Single Sign On is a technical service that allows application administrators to rely on a single source of account data, and allows members of the campus community to use one SA¹ú¼Ê´«Ã½ Username and Password to access multiple services.

What are the benefits of SSO?

SSO provides a simple, streamlined and familiar login process for accessing applications. When members of our community see the https://login.scu.edu prompt, they know that they are accessing a legitimate service, where it is safe to enter their SA¹ú¼Ê´«Ã½ credentials, whether or not the application is hosted by SA¹ú¼Ê´«Ã½. By having a shared authentication service, SSO minimizes the number of username and password combinations that people need to remember, and ensures that applications do not need to store and protect end-user credentials. Because SSO is tied to SA¹ú¼Ê´«Ã½â€™s identity-management process, SSO credentials quickly and automatically reflect changes in status, and provide a single point of control to minimize risk when an account is compromised. (Note, this is not instantaneous; the change in status will not be known by the application until the information is refreshed, typically by the user logging out and logging back in.)

How do I get started bringing my application into SSO?

The SSO team welcomes SA¹ú¼Ê´«Ã½ application administrators to bring their applications into Shibboleth. Once Shibbolized, web applications are added as tiles within the MySA¹ú¼Ê´«Ã½ Login Portal, where they are easily accessed by members of the campus community. For a consultation about bringing your application into SSO, please contact the Technology Help Desk.

SSO terminology:

The Identity Provider (IdP) is the SSO system itself. The IdP is responsible for user authentication, and for providing user information to the Service Provider (SP). For SA¹ú¼Ê´«Ã½, the IdP is our Shibboleth service at . Information Services runs the IdP on behalf of SA¹ú¼Ê´«Ã½.

The Service Provider (SP) is the application that users are using SSO to access. The SP may be internal to SA¹ú¼Ê´«Ã½, or may be a third party like Canvas, Google, or Workday.

If you are requesting that an application be added to SSO, then your application is the SP, and you as the SP administrator have some responsibilities within the SSO framework:

• Provide an introduction to your vendor’s IT team for SSO integration work
• Coordinate any ongoing changes on your vendor’s side of the SSO integration (such as periodic certificate updates)
• Provide and maintain the information needed on the MySA¹ú¼Ê´«Ã½ tile
• Manage tile visibility using the Entitlement Manager (, access is limited to SA¹ú¼Ê´«Ã½)

How does SSO work?

This diagram shows the interaction between the user, the Identity Provider and the Service Provider:

Here’s what happens when the user connects to a SSO-protected service:

1. The SP detects the user attempting to access restricted content within the resource.
2. The SP generates an authentication request, then sends the request, and the user, to the user's IdP.
3. The IdP authenticates the user, then sends the authentication response, and the user, back to the SP.
4. The SP verifies the IdP's response and sends the request through to the resource which returns the originally requested content.