
Cambridge University Press: Single Sign-On for 100M Global Users
Single sign-on and modernized authentication for an academic publishing platform serving 100 million users and 4 billion documents worldwide.
Project Goals
Modernize legacy single sign-on system to support 100 million users across multiple authentication realms, deliver real-time monitoring and operational tools for platform serving 4 billion documents, ensure zero downtime during migration of critical academic infrastructure, and support both public access and institutional subscriptions with unified authentication.
The Problem
Cambridge University Press runs one of the world's largest academic publishing platforms, with 100 million users and 4 billion documents. Students and researchers around the world depend on it.
Its single sign-on system was showing its age.
The old setup couldn't scale. Several authentication methods didn't work well together, and the operations team had no unified view of what was happening. On top of that came the mix of users: public visitors, institutional subscribers and federated university logins, each needing different treatment.
Downtime wasn't an option either. Try explaining to a PhD student why they can't reach research papers the night before their thesis is due.
The Challenge
This was much more than swapping out login forms. Cambridge University Press had authentication needs that would make most SaaS platforms look simple.
Public users created free accounts, and individual subscribers paid for access. Entire universities held site licenses and expected federated login from their campus systems, while third-party integrations needed API access.
Each of these needed its own authentication flow, and all of them had to work together without users noticing the joins.
There were no downtime windows. Students use the platform around the clock in every time zone, and academic calendars don't have quiet periods.
What We Built
We modernized the authentication infrastructure with zero downtime. From the user's point of view, it was business as usual.
The New SSO System
We built a centralized identity provider that supported every authentication method Cambridge needed. Direct users kept their username and password. Federated institutions used OAuth and SAML, APIs used token-based authentication, and single sign-on covered the entire product family.
All of it ran through one system instead of disconnected pieces.
Realm Unification
The platform had several "realms," which were different user populations with different access patterns.
The public realm covered open access to free content, registration for personalization and trial access to premium content. The private realm covered institutional access through university subscriptions, IP-based authentication, federated login from campus systems and license enforcement.
We unified them under one authentication layer, so users could move between realms and get a consistent experience everywhere.
Federation at Scale
Universities around the world each had their own identity systems, and each wanted federated login so students could use their campus credentials.
We built a SAML integration that scaled, with metadata management for institutions, automated onboarding, support for different federation standards and failover when an institution's systems went down.
Every university integration is unique. We built systems that made unique integrations manageable.
Global Infrastructure
A platform with 100 million users doesn't serve them from one place, so we distributed the authentication infrastructure globally. Regional servers reduced latency, database replication sped up reads, caching held frequently accessed data, and geographic routing sent users to nearby servers.
A student in Tokyo shouldn't have to authenticate through a server in London, and after the rebuild they didn't.
The Migration
You don't migrate 100 million users overnight.
We ran the old and new systems in parallel, writing to both during the transition, and moved user populations to the new infrastructure gradually. We started with low-risk segments and rolled out region by region, with feature flags controlling exactly who used what and monitoring on everything.
An instant rollback was ready in case anything went wrong. We never needed it, and the migration finished with zero downtime.
Operational Tools
We built real-time monitoring and operational tools for the team running the platform. Dashboards showed authentication success rates by region, login latency, active sessions, error patterns and usage by institution.
That let support teams diagnose problems quickly. If a user couldn't log in, the team could look up the account, see its authentication history and find the cause. If a university reported access problems, they could check its usage patterns and federation setup and spot what had changed.
Operations moved from reactive to proactive, and problems were often caught before users noticed them.
The Results
100M users supported globally. Every authentication method worked in every region, through one platform.
4B documents accessible. The content was always there. Now authentication doesn't get in the way of reaching it.
Zero downtime SSO migration. Critical academic infrastructure stayed available from the first migrated segment to the last.
Real-time operational monitoring. The operations team could see authentication health by region and by institution as it happened, instead of hearing about problems from users.
What We Learned
Dual-run migration makes zero downtime possible. Running old and new systems in parallel costs more infrastructure. For a critical system where downtime isn't acceptable, we don't know a safer approach. Gradual traffic shifting, instant rollback and validation in production at every step are what made it work.
Monitoring is a product feature. The real-time tools weren't only for the operations team. They improved the user experience because problems got resolved faster, and when support can diagnose an issue quickly, users get help sooner.
Authentication complexity mirrors business complexity. Cambridge's authentication wasn't complicated for fun. Public users, institutional subscribers and federated login each served a real business need, and the technical challenge was making them all work together.
Federation takes patience. Every university has its own systems, standards, timelines and approval processes. You can't standardize that away, so you build systems that handle the variety gracefully.
Global scale requires regional thinking. Authentication from a single data center doesn't work when users are everywhere. At this scale, geographic distribution is what separates an acceptable user experience from a good one.
Cambridge University Press supports education worldwide, and its authentication infrastructure now matches that reach.
Need enterprise SSO implementation or platform modernization? Let's talk →
See more infrastructure transformations View case studies →
Like what you see?
Tell us what you're building and we'll tell you how we'd approach it.
Start a project