Welcome to part two of our blog series on how to migrate from Okta to OneLogin. In our previous blog, we discussed different ways an organization can approach the user migration component of the overall access management migration project. We received great feedback on that article, so thank you to everyone who reached out to us in response to that! Today, we are going to discuss how to approach the migration of applications from Okta to your new OneLogin environment.
Understanding the application migration process
At first glance, application migration may feel like an overwhelming process for many organizations and particularly those that have added many application integrations to their environment over the years. The reality is that the process is much simpler than you may think. There will be some work required up front to get yourself into a good position to carry out the migration, but once this work is complete, the actual migration of applications from your Okta environment to OneLogin will simply become a “rinse and repeat” process that can be completed at a pace your organization is comfortable with.
The application migration project will also offer your organization with a perfect opportunity to perform some “housekeeping” and consider rationalizing or removing applications that may no longer be necessary or are scarcely used in your organization. This process could potentially reduce your licensing fees costs.
The application migration project is also a great time to revamp your current processes for onboarding applications into your access management solution. Shifting from a primarily manual-driven process to a more agile and automated approach, with touches of delegated administration, can lighten the burden on your organization’s overworked IAM team.
Leveraging Terraform for efficiency
Want to save some cash in SaaS license fees or simplify the life of the workforce access management team? If you answered “no” to either question, please leave the building. For our sane audience, read on to learn how you can make this a reality.
How can we turn the daunting task of migrating hundreds of applications from Okta to OneLogin into an opportunity to transform the way applications are onboarded into your organization’s access management solution? The answer lies in the wonderful world of Terraform, coupled with a good IaC platform.
You’re probably familiar with Terraform, especially if your infrastructure team uses it to manage your AWS/Azure/GCP resources. However, you may not have heard how it can be used for access management. Terraform is a well-established tool for managing cloud IaaS, PaaS and even SaaS services (and let’s not forget the new OpenTofu fork for all you true open-source fans out there). It’s only natural that Terraform is also a perfect fit for managing your new IDaaS OneLogin environment.
If an organization shifts to use Terraform to manage application onboarding into their new OneLogin environment, they can expect the following benefits:
- Reduction in the number of users requiring high privileged access to your production OneLogin Admin console
- Automated assignment of app security policies and delegated application admins to applications
- Automation of your OneLogin environment, including user access to applications via custom fields, mappings, roles, groups, etc.
- Significant reduction in the amount of “configuration drift” between your production and sandbox OneLogin environments
- Automatic onboarding of new applications into the production OneLogin environment (once they have been created and tested in your sandbox environments) simply by following the standard “GitOps” process in your organization
- Immediate rollback of any changes made to your Production environment simply by reverting a pull request in your “GitOps” process
- Automatic clean-up/removal of applications that are no longer needed by following that same “GitOps” process
- Full version-controlled documentation of all applications onboarded into your OneLogin environment complete with tracked changes
Steps for preparing application data
Now that we’ve established why adopting this approach is beneficial for managing application onboarding to your OneLogin environment, let’s dive in deeper into how it can be used specifically in the context of migrating your applications from Okta to OneLogin.
The first step an organization will need to take is to export a list of applications currently integrated into their existing Okta environment. This can be achieved by using the Okta Admin API. With this information in hand, an organization can review each application, rationalize why it is still needed and categorize it as being either in scope or out of scope for the application migration to OneLogin. To assist with this process, we have created an example Ansible playbook which can be run against your Okta environment and can export all applications into a JSON file. This file can then serve as an input for creating applications in OneLogin via Terraform.
Before feeding this file to our Terraform solution to populate your new OneLogin environment, there are a few steps needed to fill in missing information. The most important part of getting the application inventory file ready for the Terraform process will be identifying which OneLogin Application Connector ID will be appropriate to use (the Ansible script listed above will output the Okta application “Name” as the connector_id in the file as a starting point) for each of your applications currently integrated into Okta. This process can be completed manually by either:
- Searching the various application names in the OneLogin application catalogue in the Admin console. Then collecting the connector ID from within the URL displayed in the browser when viewing that application connector.
- Searching against a list of all application connectors which are available in OneLogin using the Admin API.
The next step is to identify the business unit technical owner for each application and tag them as being responsible for that application. We currently recommend an approach to automate application onboarding process to the OneLogin environment up to the point where the final connector level configuration needs to be defined by the application owner. The owner can then be automatically provided with delegated administrative privileges to manage the specific configuration required for the application connector in the OneLogin Admin console.
As mentioned above, one of the benefits of using an automation solution with Terraform is that configuration can be rolled out to sandbox environments first and then, once validated, to production. With this approach, application owners can configure and test their connectors in the sandbox environment with non-prod instances of their application before proceeding to request the application to be set up on the production environment.
The final steps to get the application inventory file ready for use include:
- Defining whether the application is a “birthright” application, which should be allocated to all users in your OneLogin environment, or whether it needs to be assigned based on an application access request process.
- Defining if the application should be protected by a “baseline” App Policy in your OneLogin environment or whether a specific App policy for that application is required.
- Defining if the application should be visible in the OneLogin App portal or hidden from users, whether OneLogin admins are to be allowed to assume the user context within the application, and finally, which OneLogin custom field is to be associated with providing access to the application where the application has not been defined as a birthright application.
Once the application inventory file is ready, it is then time to test out the application onboarding process against a sandbox OneLogin environment before any deployment to the new production environment. We have created an example Terraform solution that can be used as a starting template for your automated application onboarding process.
When the solution has been run against your target OneLogin sandbox environment, all applications defined in your application inventory file should be created along with corresponding roles, mappings and delegated admin privileges for each application. Application owners can then be notified to access the OneLogin sandbox environment to complete the required configuration on each application connector they have been given delegated admin privileges to manage. Application owners can then complete the required re-configuration on the application side (on-prod instance) and test that everything is working as required when the application has been reconfigured to use OneLogin rather than Okta.
Once application owners have successfully reconfigured all of their non-production application instances to use the OneLogin sandbox environment, the project can then proceed to the stage of adding these validated applications onto the application inventory file, which is then used to automatically deploy the new applications to the production OneLogin instance. It typically makes sense to hide all applications from end users until they have been cutover to use OneLogin to avoid confusion. Achieving this is simple: mark applications not yet cutover as not being visible in the inventory file. Once cutover and tested by the relevant app owners, the inventory file can be updated and Terraform will automatically apply the changes to the target OneLogin environment to make the applications visible to users on their app portal.
Executing the application migration process
With the applications now created in the production OneLogin environment and the application owners holding the required delegated administrative privileges to manage those applications, it’s time for the application owners to complete the final configuration of their respective application connectors. This involves matching what was defined in the sandbox environment and planning when the all-important cutover slot for each application will occur.
The process for cutting over applications should be standardized to minimize risk and should generally follow this approach:
- Disable provisioning on Okta for the relevant application, if enabled.
- Enable provisioning on the OneLogin connector for the relevant application and provision a new test user to ensure everything is working as expected.
- Once provisioning has been validated, or where it is not required, it’s time to reconfigure the SSO settings on the relevant application to point away from the Okta environment and into the OneLogin service.
- Once applications have been cutover and tested, update the application inventory to make them visible to end users.
Watch this video to see an example of how applications can be exported out of an Okta environment and automatically onboarded into your new OneLogin environment via Terraform.
Conclusion
Migrating applications from Okta to OneLogin can be seamlessly achieved with careful planning and execution. By streamlining the process, organizations can minimize disruptions, improve operational efficiency, cut costs and enhance access management capabilities.
