Upgrading Identity and Access Management Across Multiple Apps: Product Management Case Study
Executive Summary/TL;DR
Identity and Access Management, or IAM for short, can be quite a complex topic — while the interface should strike the optimal balance between simplicity and security, making sure ‘the parts work’ is quite an intricate affair.
Introduction
Disclaimer: For the sake of confidentiality and anonymity, all details contained in this case study (especially PII such as names, addresses etc.) are fictitious and don’t contain any details about the respective client. If you’d like to learn more, reach out to me directly.
In this case study, a client had a quite typical ‘growing pain’ of having built an own authentication that had been robust, but was proving quite hard to scale — and not really future-proof, considering the rising challenges of authentication such as increased hacking activity and increased compliance requirements.
Problem Statement
Initial Assessment
Ow my IAM! Photo by Bermix Studio on Unsplash
The client’s applications — desktop, mobile app and whitelabel — had initially been fitted with a self-built IAM solution for registration, login, authentication and authorization of users.
Engineering management was foreseeing that this status quo would lead to a few problems in the future (or even in the present):
Maintaining an own IAM solution as part of your application means that you’re responsible for maintaining and update it — which is time-consuming and thus also costly.
More importantly, it requires diligent updating according to new threats and standards — or risking compromise.
Also, it’s cumbersome to scale and upgrade — e.g. when you want to introduce Single Sign-On or a new method of authentication like Social Logins (such as OpenID Connect or SAML 2.0, like OAuth via Google).
Solution
Picking A Solution
Photo by Olav Ahrens Røtne on Unsplash
Deciding on what solution to pursue was rather straightforward — having one separate IAM solution in place would yield exactly the desired advantages.
So, after some due diligence, an Open Source Identity and Access Management tool was decided to be implemented.
Implementation
Photo by White Field Photo on Unsplash
The next steps would be much more difficult — we had to:
fully set up the solution so it would be able to replace the scope of the current IAM.
conduct extensive testing.
involve all different interface teams (desktop, mobile app and whitelabel) to prepare their respective interfaces.
be prepared for a rollback (i.e. reverting the changes).
also set up a fallback (i.e. use the legacy IAM as a backup if the new IAM should fail).
plan to run both IAM solutions concurrently for a certain time (e.g. 3 months) before shutting the legacy one down.
The Biggest Bottleneck
First one on the right, obviously. Photo by Andrew Seaman on Unsplash
The phase which took the most time was testing.
Was this a surprise? At the time, mabye.
But as hindsight is 20/20:
No one involved with the project was either an IAM expert, or had been involved with building the legacy IAM.
We were all ‘iteratively learning’ — both about what cases need to be considered from an authentication perspective, but also from an application perspective (i.e. their UX and functionality).
So this turned into a weeks-long ‘game of cat and mouse’.
Whenever we thought we were done, we noticed one more thing to fix.
Remind you of this? Credit: Yash Bhardwaj of Jugaad Posters
Rolling Out
*cue keyboard riff* Photo by Mick Haupt on Unsplash
As we had planned on running both IAM solutions concurrently for a while, we were able to transition all the interfaces separately, and also rollout gradually (i.e. starting with 1%, 5%, 10%, 20%, 50% etc. of all users).
This had never been on the table, but I cannot skip emphasizing what a bad idea it would’ve been to do a big-bang, hard-switch type release.
Actually, doing big-bang releases is a bad idea, period.
But in this case, consider the risk:
If something goes wrong at launch, users can’t log in to the app anymore, and the operation starts bleeding revenue right away, with operational chaos to follow straight away.
Coordinating multiple teams to switch something at the same time may be feasible if it’s e.g. a marketing materials switch, or literally flipping a (feature) switch, but with complex and vital technology such as IAM, stability and reliability are the north stars, so treading lightly is paramount.
Results
Photo by Sammie Chaffin on Unsplash
Eventually, we managed to roll out the new IAM solution to all interfaces.
As a result of this prolonged but successful affair, we were able to:
mitigate risks to authentication being compromised
transferred risks of maintaining authentication to a separate application
transferred the burden of updating to that separate application as well
were able to provide Single Sign-On, making the user experience not just safer, but also easier.
Conclusion
For dough, it’s always ‘make’ — because it’s calming and fun! Photo by Max Saeling on Unsplash
In summary, here are my main takeaways regarding this make vs. buy-decision:
Making something over buying creates unique asset value — you have now built your own machine, something that can’t be bought off the shelf. But – what is it really worth? Does it only serve your business, or can it serve others (possible whitelabel/as-a-service route)? Does its customized form create a business advantage for your operation (‘secret sauce’ advantage, like Coke’s secret sirup recipe)?
Making something also creates a liability — as you’re not able to transfer any risk or burden to a third party or entity, you need to own that risk. That risk also weighs against the aforementioned asset value and can outweigh it. The important factor to consider is lock-in — it behooves an organization to be able to switch vendors or suppliers as seamlessly as possible, otherwise the liability-side of the equation increases substantially.
Buying something over making it accordingly has reduced asset value and liability — which can tip the scales favorably. In the case of my client, IAM wasn’t a core competency — they just needed a robust solution to facilitate their core business, and neither would have been able to sell their own solution separately, nor would have gained a significant business advantage from making over buying.
Thank you very much for reading!
If you’d like me to help you with a similar challenge you’re facing, I’m a Freelance Product Manager & Consultant for hire — feel free to reach out to me at hi[@]bertrandrothen.com