SSO Authorization

SSO Authorization Overview

The intent of SSO authorization is to ensure that all campus services provide a baseline level of access control. All applications integrated with CalNet are subject to a default authorization policy unless the application owner opts to create a custom policy or provides their own authorization logic at the application level. For more information on these concepts, see KB0015472 - Authentication vs. Authorization.

Default Authorization Policy

The default authorization policy applies to all new SSO Service Registrations. The current members of the Default Authorization group include:

• All SPA UIDs (Note: Both the SPA and the individual user must be in the default group to gain access).
• CalNet Test Accounts and rSPAs with AFFILIATE-TYPE-TEST.
• Active Employees, UCPath Affiliates, and Students.
• Users currently in a Grace Period (KB0011576).

Note: Guests and Alumni are not permitted by the default authorization policy.

Custom Authorization

Authorization can be tailored to meet specific departmental needs. These methods can be combined within a service registration to achieve the desired result:

• Standard Affiliations: Limit access based on roles (e.g., "Staff only").
• CalGroups Official Groups: Use existing campus organizational structures.
• CalGroups Ad Hoc Groups: Create specific "Allow" or "Deny" lists for granular control.

Application-Specific Authorization (Opt-Out)

Application owners can opt out of Default authorization. In this scenario, authorization is performed exclusively at the application level. Owners may also choose to mix SSO service authorization with local application logic.

Examples of Authorization Scenarios

• Default Authorization: All users in the standard campus group are allowed to log in; no further configuration is needed.
• Custom Authorization: Only employees and UCPath affiliates are allowed to log in; students, SPAs, and alumni are restricted.
• Application-Specific: All campus entities (including guests and alumni) can log in via SSO, but the application internally determines what data they can see.
• Combination: Only users in the default group can pass the SSO screen, and the application then applies further permissions once the user is logged in.

---

SSO Registration

CalNet offers several options for Single Sign-On integration. For a detailed guide on the authorization process, see: KB0015303 - SSO Authorization Details.

For any of these SSO integrations, Submit a Service Request for SSO Integration.

Central Authentication Service (CAS)

CAS is an enterprise-focused single sign-on protocol designed for traditional web applications. It is suitable for both on-campus and off-campus hosted applications. See: KB0015660 - Simple authentication with CAS.

Shibboleth

Shibboleth is an standards-based software package built for federated identity management across distinct organizations. It is used primarily for SAML2 integrations with off-campus partners and the InCommon federation. See: KB0015616 - How do I use Shibboleth/ SAML for SSO?.

OpenID Connect (OIDC)

OIDC is a modern identity verification layer built on top of the OAuth 2.0 protocol, designed for modern web, mobile, and API-driven applications. See: KB0015304 - OIDC Integration with CalNet.