How Catawiki Migrated SSO’s with Zero Trust and Zero Downtime
Catawiki is a fast-growing company attracting 10+ million monthly visitors to its curated online marketplace for special objects. With 700+ employees at present, we’re aiming to grow even further and expand our teams worldwide.
With that in mind, each month we onboard around 40 new employees working remotely throughout Europe and Asia. This is coordinated by a close working relationship between HR, IT, and Information Security. To continue providing a smooth onboarding experience and minimise data risks, we decided to overhaul our SSO and Identity Provider (IdP). This post covers our journey.
When we decided to migrate our IdP, we’d already been working with an IdP vendor for three years, so most of our mission-critical apps were already accessible through an SSO portal. Our HR database was also connected to the IdP, and our employees were familiar with using MFA to secure their apps. Yet as we looked towards the coming years, especially with the proliferation of remote working, we identified a number of areas for improvement.
Things we wanted from an IdP
Zero trust security
As we can work from anywhere, there’s no such thing as a trusted network. We need to be sure to validate the devices used for accessing Catawiki data; we can’t risk having someone use an unpatched public computer to check their email or access our customer data. And finally, because we can’t trust passwords, we verify users with MFA. You can learn more about Zero Trust in this article.
Zero-touch enrolment
The IT team wanted the ability to drop-ship a brand-new Macbook straight from the warehouse to a new employee. After unboxing and connecting to WiFi, the security policies should automatically be pushed to the device, authorising access to Catawiki data and SaaS tooling with their IdP credentials and MFA.
Smooth onboarding and offboarding
Our employee data is already stored in an HR database, so we needed to make use of this and automatically create an individual’s accounts when they’re hired. Even better, we wanted to give them access to the onboarding platform ahead of their first working day so that ‘day one’ goes as smoothly as possible. When someone leaves the company, we can adopt the same policy to close accounts at the right time.
A long-term SSO/IdP partnership
Changing your IdP is not a trivial task. We needed to select a vendor who could grow with us and meet our projected headcount growth over a five-year time frame.
Choosing a vendor
After researching the IdP market, we engaged the IdP market leader Okta for a POC, thoroughly making sure that the tooling could meet our requirements from August to November 2020. After a successful POC, we proceeded to find an implementation partner.
Finding a partner
Having small IT and Security teams demands efficiency. This led us to enlist professional services to help with the implementation from an external consultant. After shortlisting a few vendors, we chose a specialist with strong experience migrating between different IdPs. To minimise the risk of any service interruptions, we planned and thoroughly prepared the migration over several months with multiple checkpoints.
Making the switch
The IdP portal is the ‘front door’ to access the Catawiki apps. So how did we handle replacing that door while people were ‘walking’ through it? We identified a number of key technical challenges involved in migrating Catawiki from one IdP to another:
Setting up federation between the old and new IdP platforms
By setting up an inbound federation from the old IdP to Okta, we were able to migrate our SaaS apps in 25 scheduled batches rather than at one time. From the user’s perspective, they continued using the old IdP portal as usual to access their SSO apps, but federation would be redirected to the new IdP only if the app was migrated. This massively reduced the project risks and ultimately allowed us to complete the project with zero downtime or outages, even for apps with hundreds of users.
Migrating each SSO app
After establishing inbound federation from January to March, we then moved each SSO app from the old IdP to Okta after thoroughly testing in a staging environment. This was tricky because each vendor uses different naming conventions for SAML configuration, so there’s an element of investigative work to find the correct settings for dozens of apps. Once an app was migrated to Okta, users were seamlessly redirected by the inbound federation setup when accessing from the old portal.
Securing the virtual perimeter
Utilising a customised mutual TLS implementation, we were able to establish a virtualised perimeter for our SSO-integrated apps. This way, we were able to not only identify and authenticate users but also devices. We also have the flexibility to monitor attempts to use unauthorised devices, make app-specific exceptions for consultants or freelancers for projects, and gain additional telemetry for our threat detection solution. Once the migration was complete, we were confident with ‘who’ and ‘what’ could access our data across our cloud applications. Going forward, we’re taking advantage of Apple’s Secure Enclave to add another layer of security authorisation for our trusted devices.
Finalising the migration
Once March rolled around, we successfully had all users federating into their apps through Okta. However, they were still accessing via the old IdP portal. The final step was ensuring all employees knew how to access their apps via the Okta portal instead of the old portal. With some outreach through Slack and our support channels, we had this covered.
A final note
Deciding to swap out your IdP is not always straightforward! A lot of planning and patience is needed, along with an experienced migration team and open communication channels across your business. But it is possible to do so smoothly, giving you a solid foundation to build on as many of us continue to work remotely from all corners of the world.
Special thanks to Paul Moreno and James Thompson, author, and co-author of this post respectively.
