Co-authored by James Thompson
Catawiki is a fast-growing 700+ person company, and we’re super busy tackling the challenge of growing our teams across new countries around the world.
Each month we onboard around 40 new employees working remotely throughout Europe and Asia. This is supported by a close working relationship between HR, IT and Information Security.
To continue providing a smooth new-employee 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 had already been working with an IdP vendor for 3 years, and so most of our mission-critical apps were already accessible through an SSO portal. We also had our HR database connected to the IdP, and our employees were familiar with using MFA to secure their apps. However as we looked towards the coming years, especially with the explosion of remote-working, we saw lots of areas we could improve on:
Things we wanted from an IdP
Zero Trust Security
We can work from anywhere, so there’s no such thing as a trusted network. We need to be sure to validate the devices used to access 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 the user 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 enjoying the unboxing experience and connecting to wifi, the security policies should automatically be pushed to the device, authorizing access to Catawiki data and SaaS tooling with their IdP credentials and MFA.
Low effort onboarding and offboarding
Our employee data is already stored in an HR database, so we needed to make use of this and automatically create a person’s accounts when they’re hired. Even better, we wanted to give them access to the onboarding platform before their first working day so that Day One isn’t as stressful. When someone leaves the company, we can use the same philosophy to close accounts at the right time.
A long term SSO/IdP partnership
Changing your IdP is not a trivial task. We needed to choose a vendor who could grow with us and meet our headcount growth in a 5-year time frame.
Choosing a vendor
After researching the IdP market, we went ahead and engaged the IdP market leader Okta for a PoC, checking in great detail that the tooling could meet our requirements from August to November 2020. After a successful PoC, we moved on to find an implementation partner.
Finding a partner
Having small IT and Security teams forces efficiency. This drove the decision 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 in migrating between different IdP’s. 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’ for access to Catawiki apps. So how did we handle replacing that door whilst people are constantly walking through it?
There were two main 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 normal to access their SSO apps, but federation would be redirected to the new IdP only if the app was migrated.
This massively reduced the risk of the project 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 detective 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
Utilizing a customized mutual TLS implementation, we were able to establish a virtualized 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 unauthorized 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 in both “who” and “what” can access our data across our cloud applications. Going forward, we’re taking advantage of Apple’s Secure Enclave to add another layer of security authorization 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 to make sure all staff 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.
Conclusion
Deciding to swap out your IdP is not easy! A lot of work and patience is needed, along with an experienced migration team and open communication across your business. But it is possible to do so smoothly, giving you a solid foundation to build on as working outside of the office continues.
Top comments (0)