Users signed in again for every application. Now they sign in once.
- Client
- A software vendor operating a suite of separate applications
- Scale
- Several applications and thousands of monthly active users
- Engagement
- An identity retrofit into applications that kept running
The outcome in six lines
| Measure | Before | After | Evidence |
|---|---|---|---|
| Login platforms to run1 | several, each with its own login | 1 sign-on for every application | Measured |
| Authentication-related support tickets1 | the old volume | 70% fewer | Measured |
| Where user data lives2 | in each application's own database | one centralised store | Described |
| Applications taken down to move users3 | every application held its own users | none, the users moved with no downtime | Described |
| Users signing in through the one service1 | signing in once per application | thousands of monthly active users, signing in once | Described |
Three lines are figures as the case record for this work states them. Three describe a change in how the estate works that carries no number, and are marked so. Each links to its source.
The problem, in the client's terms
Each application had its own authentication. User information was recorded inconsistently from one application to the next. Security had to be managed separately on every platform, which widened the room for mistakes. Managing credentials and permissions separately was costly and slow, and users had to log in again for each application.
For the people using the estate, that meant several passwords for one working day, and a reset request whenever one of them lapsed. For the people running it, a new starter was several accounts to create and a leaver was several accounts to find. Miss one, and a former user could still sign in somewhere.
The duplicated records were the deeper problem. When a person exists once per application, each copy drifts on its own: a changed email here, an old role there. No single record says who a user is or what they may do, so no single place can answer an access question.
- ConstraintEvery application stayed in service. Existing user data had to move to the new system without downtime.
- ConstraintUser data had to stay protected during the migration and after it.
- ConstraintLicence cost had to stay low, which favoured an open-source identity server over a per-user product.
- ConstraintEach application was written separately, so the sign-in change had to fit several front ends and APIs, not one.
The architecture, before and after
Switch between the two. Sign-in moved out of each application into one identity service, the per-application user tables became one store, and every API started checking the token it was given.
- What hurt in this state
- Built in this engagement
Three decisions, and what we turned down
The stack is the easy part to copy. The choices behind it are what made it work, so each one names what it replaced and what it cost.
Which identity server to run
Turned down
A hosted identity product priced per user
The licence grows with every user added, and the client's goal included keeping licence cost down.
Turned down
A sign-in service written for this estate
Registration, password recovery, MFA, federation and brokering would all have to be built and then maintained, where an existing server ships them.
Chosen
Keycloak, open source, on the client's own AWS account
No licence fee, OAuth 2.0 and OpenID Connect out of the box, and registration and password recovery that no application team had to write.
What it cost: The client now runs the identity server itself. Upgrades, patching and uptime are theirs, and one service is now in the path of every login.
Where user data lives
Turned down
Leave each application's user table in place and federate it
Every copy would keep drifting, so one person would still be several records and no single place could answer who a user is.
Chosen
Move every user into one centralised store
One record per person, one place for credentials and permissions, and no user database left inside any application.
What it cost: The data had to move while every application stayed up, duplicate records had to be reconciled into one, and each application's own reads of its user table had to change.
Where access is enforced
Turned down
Check sign-in only in the front end
An API called directly, without the front end, would skip the check entirely.
Chosen
Middleware on every API that validates the token and applies roles
Each request carries proof of who is asking, and each API decides what that user may do, whichever client called it.
What it cost: Every API needed the middleware and a mapping from Keycloak roles to what it allows, and those roles now have to be kept in step across the estate.
How it was delivered
The identity service first, then the users, then each application moved onto it, then the people who run it.
Identity service
Keycloak on AWS across EC2, RDS and IAM, with OAuth 2.0, OpenID Connect and MFA configured.
User data
Existing users from each application moved into the central store, with no downtime.
Front ends
The Keycloak JavaScript adapter added to each front end for login and session handling.
APIs
Token validation and role-based access middleware added to each API.
Federation and social login
User federation, identity brokering and social logins configured to the client's requirements.
Training
Staff trained to use and manage the new authentication system.
Who owns what now
Staff were trained to use and manage the new authentication system, and the client runs it.
Results
What a user and a support desk deal with, before and after.
- Users log in once to reach every application.
- Administrators manage every credential and permission through one interface.
- Application teams get user registration and password recovery from the identity server instead of building them.
Security is not shown as a count of incidents, because no count was taken.
100
Before
30
After
Most of the login and password queue went away once there was one login.
| Option | Indexed to the old ticket volume as 100. |
|---|---|
| Before | 100 |
| After | 30 |
Source: Source note 1
What it would be worth to you
We do not publish what an engagement costs. So this works from your side: what your login tickets cost today, and what a per-user identity licence would cost you.
Support cost saved per year
Enter your tickets
- Support hours saved per month
- Enter your tickets
- Login tickets left per month
- Enter your tickets
- Per-user licence avoided per year
- Enter users and a price
The licence line applies only if the alternative you are weighing charges per user.
What went wrong, and what we would change
Moving users without stopping anything
Moving users without downtime was the hard part. Users kept signing in to the old applications while their records moved. Next time, duplicate records get matched and reviewed before the first application cuts over, so the merge is settled before it is live.
Each application met Keycloak differently
Each application needed its own configuration changes before it worked with Keycloak, found through testing. Each one had its own assumptions about sessions and users. What we would change: a written integration checklist per application, run before its cutover rather than found during it.
Staff had to learn a new system
Support staff needed training. Managing users in one place is simpler, but it is a different place. Next time, the admin runbook is written alongside the build, not after it.
Will this work for your estate?
It fits when
- You run three or more applications and the same people use several of them.
- The same person exists in several user tables and the records disagree.
- A per-user identity licence would be a real line in your costs.
Look elsewhere when
- You run one application. Its own login may be all you need.
- You have no one to run and patch an identity server. A hosted product may cost less in the end.
- Your applications cannot be changed at all. A sign-on in front of them needs each one to accept a token.
Check it yourself this week
If several applications hold the same people and a share of your tickets are about logins, this case study is about you. Put the ticket count into the calculator above.
- Count the applications that keep their own user table.
- Pick ten active users and check how many tables each one appears in.
- Count last month's support tickets about logins and passwords.
The stack, by layer
- IdentityKeycloak, open source, with OAuth 2.0, OpenID Connect and multi-factor authentication
- FederationUser federation, identity brokering and social logins
- Front endsThe Keycloak JavaScript adapter in each application
- APIsMiddleware that validates tokens and enforces role-based access
- CloudAWS EC2 for Keycloak, RDS for the central user database, IAM for access
How each figure was measured
- Login platforms, authentication support tickets and monthly active users, before and after one sign-on, across the applications involved.
- How the platform works: one central user store and one interface for every credential and permission.
- Users moved to the central store while the applications stayed up.
Tell us how many logins your users juggle, and we will tell you what one would take.
Send the number of applications and last month's login tickets. A software engineer reads it and replies with an honest answer, including when one sign-on is not worth running.