Migration

Introduction

Whether you are moving from an onpremise identity provider to a cloud based IDaaS, or from one Cloud provider to another, there isn't a silver bullet to automatically make the move seamless. You are not alone though, most enterprises will end up going through an Identity Provider migration once every 3-5 years. Whether the reason is monetarily driven or to offer a better user experience, a project plan and architectural changes are inevitable. However, there are proven patterns that will help make this move more seamless and cost effective, saving you time and sleepless nights.

SAML and OpenID standards rely on similar variables to make a trust connection with the identity provider, and because of these variables, security is built in. However, in a majority of cases, changes are absolutely required on the endpoint when moving from one identity provider to another. This means either changing the entity ID and Assertion Consumer URLs and certificates for SAML, or the client ID / secret and endpoints for CI on the application for OpenID apps. The good news is that because SAML and OpenID are standards based, nothing needs to be done to your applications other than a few steps. Use the "phased approach" concept to guide your project planning

Phased methodology

Planning

Identify the architecture pattern for before, during and after the migration. In this migration plan, the approach that is recommended is to:

1. Make the new Identity Provider (IdP) a "service provider" for your current identity provider. This allows the new IdP to act as a SAML proxy and just facilitate the move by keeping attribute claims in place without requiring the application to make any changes. The other benefit here is that no new user interfaces are introduced. The end user simply sees a redirect in their browser and non is the wiser. Current user experience is left intact.
2. Move applications from the old IdP to the new IdP. Exchange client IDs, secrets, SAML metadata, and any other API endpoints required for the application to migrate.
3. Remove your old IdP as the provider for the new service and point it to your source of record.
4. Decomission your old system and you're done!

Have "test" environments ready for every critical cloud and onprem application if possible. Most customers only have 1 Office365 or GSuite tenant (for example). This means that you wont be able to test the new system on these apps until it's in production. This is not a recommended practice. While these services cost money, it is not wise to not have a single instance of a cloud service.

Consider "how" you will communicate these changes to end users. If you are improving the end user experience, then you need to communicate why this will improve their experience. There is a reason for the migration after all. It is important to be transparent with end users, especially because this is how users authenticate to their applications every day.

Choose specific dates and deadlines. Ironically enough, it is such a failed step in many project plans is establishing deadlines.

Moving applications

Choose which applications will migrate first, and which ones move last. There are two approaches to this, but depending on the type of organization you are or what sort of outcome you are looking for, one may work better for you.

1. Most used apps first / Low use apps last
2. Low use apps first / most used apps last

There are benefits to taking the "most used apps" first: it generates a big bang, puts less pressure on the project plan. However, these typically are business critical apps.

There are also benefits to taking the "low use apps" first. This allows you not make any impact to major, mission critical applications while ensuring that knowledge is built on the new tool by your helpdesk and IT admins.

The best approach is likely a combination of both. Get your feet wet in moving some smaller, less used applications to understand the new tool and simoultaneously grow knowledge and awareness, then to speed things along once comfortable, move the larger applications. Then clean up the migrations with the remaining lesser used applications at the end.

Cutting over

All applications must be moved over at this point for this stage to occur, otherwise you will be running two independent systems. By the way, this is not necessarily a bad thing, but obviously is something to consider before performing the cut over.

In this phase, you will likely introduce a new theme or UI to your end users. That's okay. Now a days, our culture has evolved to become more tolerant of changing user interfaces (barring any major user experience modifications). Providing a similar look and feel is important to make this migration more straightforward, so keep this in mind when branding and theming your new login experience.

The action required in this phase is to add your source of record (directory) to the new Identity Provider and remove the older service from the mix. Once you do this step, the new identity provider takes over. Authentication will no longer flow to the old service.

Removing old components

After all applications are moved over, and the cut over to the new identity provider is done, you now have the ability to decommission your older service.

The timeline for supporting this plan is dependent on the access you have with your vendors, number of applications, and business units cooperation. However, generally speaking, these migrations should generally not last more than 3 months. Some organizations have more change controls than others, so use this as a general outline.

💎

Adam Case, IBM Security