Single Sign-On (SSO) for UCSB identity management consists of policy and LDAP servers scaled to provide a 24/7 campus service. Federation using the SAML 2.0 protocol is also supported by a Shibboleth service where UCSB is a member of InCommon.

To inquire about using campus SSO, please contact us through the UCSB IT Help Desk.

SAML (highly recommended)

UCSB identity management supports SAML 2.0 authentication by hosting a Shibboleth service. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about an end user between a SAML authority, named an Identity Provider, and a SAML consumer, named a Service Provider. SAML is an industry standard for federated authentication that has been widely adopted throughout the Internet. This enables the campus to incorporate federation to non UCSB domains to enable integration with cloud services and vendors.

All commercial or open source applications that support SAML 2.0 can be utilized on campus or with third parties to offer SSO. Our Shibboleth service is integrated with our CAS service to offer a seamless login experience for the end user.

UCSB Identity Provider metadata:

Central Authentication Service (recommended)

The Central Authentication Service (CAS) is a SSO protocol for the web. Its purpose is to permit a user to access multiple applications while providing their login credentials only once. It also allows web applications to authenticate users without gaining access to a user's security credentials, such as a password.

CAS for UCSB provides a single login page for UCSB applications and can incorporate MFA through our Duo implementation.

CAS provides enterprise SSO service for the Web:

  • An open and well-documented protocol with limited adoption among web applications and services
  • Support for multiple protocols (CAS, OAuth, OpenID)
  • A library of clients for Java, .Net, PHP, Perl, Apache, uPortal, and others

LDAP Authentication (not recommended)

There are campus applications that directly connect to the campus LDAP for data and authentication purposes. This type of authentication may be on a per user basis or require an LDAP application account. A LDAP application account with greater access is required to bypass search return limitations of regular accounts. Also, some older applications will authenticate their users directly with the campus. In general, we no longer support direct authentication to the LDAP and recommend SSO to provide a more cohesive and secure authentication method.