California State University, Long Beach Case Study

California State University, Long Beach

Okta Provides a Single Sign-On System to Simplify Authentication for Students

California State University, Long Beach is one of the 23 schools in the public California State University system. Founded in 1949, CSULB is one of California’s largest universities by enrollment, with 37,065 students. CSULB offers 82 baccalaureate majors, 67 master’s degrees, 4 teaching credential programs (including 10 single subject areas), and 4 doctoral degrees. In the 2019 U.S. News & World Report rankings of regional public universities in the West, CSULB is number three.

Initial Challenges

In July 2013, CSULB’s Enrollment Services department requested an application that would make it easier for students to securely access their school resources. At the time, students had to log in separately to each system (e.g., enrollment, advising, financial aid), and the repeated authentication disrupted students’ workflow. The Enrollment Services department hoped the Division of Information Technology could build or find a solution that would enable students to log in to a single sign-on (SSO) portal to access all their applications and services in one place.

CSULB’s IT division met with various departments to identify requirements for an ideal SSO solution and determined that it would have to support various authentication mechanisms, including Shibboleth SSO
and Lightweight Directory Access Protocol (LDAP) authentication. Further, an imperative voiced by more than one department was that each authentication method needed
to remain unchanged for users who want to continue to authenticate directly through

the individual application. This would prevent previously created bookmarks and links for the logins from being broken after implementation of the new solution.

IT met with SSO providers OneLogin and Ping, but Okta was the most confident vendor in its ability to integrate with CSULB’s existing Shibboleth environment. The CSULB team and Okta worked out how they would create the authentication token on the Shibboleth side, ensuring the applications already integrated with Shibboleth would remain unchanged and still work with Okta SSO.

Implementation and Shibboleth Integration

CSULB began their implementation of Okta SSO in February 2014, leveraging Okta Professional Services, who worked with CSULB IT via phone calls. A Shibboleth developer helped with the integration between Okta and Shibboleth, which was the most challenging part. Okta initially suggested CSULB set up two separate Okta instances. After initially establishing one system as the Shibboleth IdP (identity provider) and a second system as a Shibboleth SP (service provider), they found the session was being lost between the two systems. They eventually solved this problem by installing the Shibboleth IdP and SP on the same system. Jesse Santana, Director of System and Web Services at CSULB, worked closely with Okta Professional Services to complete the integration and implementation by March 13, 2014.

Since CSULB’s implementation, Okta has hired a Shibboleth expert who has updated the architecture to enable Shibboleth to integrate with Okta directly. Rearchitecting the environment with the new direct integration has cut the number of authentications required in half. In the previous environment, each user authenticated to both Okta and Shibboleth, but now only one authentication per user takes place.


CSULB was one of Okta’s first higher education customers, and, with about 37,000 students, it was too expensive for the school to leverage Okta’s standard per-client licensing model. Instead, Okta devised a new pricing model to fit CSULB’s budget that priced student licenses at about one-fifth of the cost of the institution’s employee licenses. CSULB now has about 60,000 licenses for their environment.

Best Practices

A best practice for CSULB is to ensure any new application added to the institution’s environment supports Shibboleth and is certified by InCommon Federation. CSULB also wrote a script that leverages the Okta API to perform REST (Representational State Transfer) calls once a month to check for inactive accounts. If an account has not been used in the past 30 days, the license is deactivated, but the account is not purged. When an account is deactivated, a student can still return, log in, and be reassigned a license, and all the student’s applications remain unchanged when they reactivate. This deactivation process keeps CSULB below their license count.


According to Santana, students, faculty, and staff have found Okta to be user-friendly. Those who want to log in the way they did before Okta’s implementation can still access the same links with no change in their previous user experience. Meanwhile, those who use the Okta SSO portal enjoy the convenience of logging in to one place to access multiple applications. Help desk calls related to access have gone down. About 102 active applications in the CSULB environment currently leverage Okta. Support for Okta is maintained by a CSULB engineer who also manages storage and the Shibboleth servers; the Okta maintenance only takes a small portion of his time.

Santana also reports that Okta has provided excellent support through its ticketing system and responds immediately. CSULB has noticed only a few short outages (lasting two to three minutes each) in over three years of using Okta. In the near future, CSULB plans to implement Okta MFA with its Okta SSO solution for applications that handle level-one data.


As part of this research, Tambellini briefed with Jesse Santana, Director of System and Web Services at CSULB, and that briefing informed this case study. Information in this study was also gathered from and