User-Centric Identity: Ensuring a Seamless Migration to OneLogin

Navigating the access management space can bring forth a host of new challenges, one of which may be the migration to a new access management solution. This blog is aimed at those of you who are in the process of considering an exit from your current access management provider and evaluating the effort required to do so.

Let’s kickstart this discussion by showing you just how easy it is to migrate from Okta to OneLogin access management solutions. We are going to break up this topic into two parts, with part one focusing on your valuable end users.

When it comes to planning your migration from Okta to OneLogin, one of your top priorities will likely be minimizing disruption to your end users. Moreover, you will be concerned about ensuring that your existing identity security posture is at the very least maintained during the migration, and ultimately, increased once all services have been migrated over to your new OneLogin solution.

With these priorities in mind, we recommend you approach your migration project with the following five core principles as your guiderails for success.

1. Users should be able to use the same authentication factors they are using today, where possible, with the new OneLogin solution. (This includes passwords where password-based authentication is still in place.)
2. Users should be able to access the same set of applications and resources that they can access today when the new OneLogin solution is in place.
3. MFA re-registration, where required, should be strictly controlled. For example, users should be forced to perform Okta MFA before being allowed to register MFA factors with OneLogin.
4. User profiles in the Okta solution should be replicated in the new OneLogin environment (standard and custom attributes).
5. Users are given the same level of access within the integrated applications (i.e. licenses, groups, privileges, roles, etc.).

In this blog, we will cover the first four items. We will address the process of migrating applications in our next blog.

To deliver a successful migration project, we will need to identify the best approach to take when it comes to getting users into OneLogin and configuring the relevant authentication factors in a way that is as seamless and secure as possible. The approach taken will be based on how your current Okta environment is architected and whether you want to keep this kind of architecture with your OneLogin solution or use the opportunity to transform your environment to your desired end state.

Before we dive into these details, there are several general steps you should start with, regardless of how your current Okta environment is architected and what your desired OneLogin end state is. These include the following items:

• Set up branding in your new OneLogin environment to mirror the current branding elements from your Okta solution.
• Perform an attribute mapping exercise to identify the number of custom fields that will need to be created in your new OneLogin environment to be able to mirror your existing core user profiles.
• Create the required custom fields in OneLogin following the completion of your core user attribute mapping exercise above.
• Create the required number of roles in your OneLogin environment to correspond to your existing Okta groups. This can be done via the admin console or for large numbers of roles/groups, you can use the OneLogin Admin API or IaC tools, such as Terraform.
• Create OneLogin mappings to automatically assign roles to your users (when they are eventually created) to mirror the same logic currently in place with Okta group rules.
• Create a Trusted IdP connection between the OneLogin and Okta environments (using OIDC) and use this TIdP as an authentication factor in your OneLogin environment via our Trusted IdP as a factor capability. This factor can be used to redirect users to perform their existing MFA at Okta the first time they sign into OneLogin, ensuring that users must perform Okta MFA before being allowed to enroll in OneLogin MFA.
• Create a user security policy in OneLogin which will require the Okta MFA (via TIdP as a factor) and apply this to users the first time they sign in to OneLogin using our pre-authentication Smart Hook capability.
• Enable the required other authentication factors you will use in your OneLogin solution and create user security policies, as required, to meet the general day-to-day needs of different groups of users in your solution. Create another series of OneLogin mappings to automatically allocate these security policies (via OneLogin groups) when your users are created.

User Migration

With the above items in place, you are now ready to start loading your users into your new OneLogin solution. In the next section, we will present several different approaches you can take to achieve this task. The recommended approaches will be specific to the desired end state you have for your IDaaS solution.

Traditional Hybrid Identity as a Service (IDaaS) Architecture

In this case, your desired end state is to maintain a traditional approach to your new IDaaS solution whereby users will be synchronized into your new OneLogin environment from an existing on-prem directory such as AD or an LDAP directory. Users will also be required to perform password-based authentication against the on-premises directory. You may have an HR-driven identity solution in place which is supported by integrations between your HR directory and your AD/LDAP via an existing on-premises IGA tool.

In this scenario, there is a very simple path to get your users into your new OneLogin environment and ensure they can use the same set of credentials for password-based authentication.

1. Install Active Directory/LDAP Connectors in your environment and configure them to communicate to the same user stores that are currently supporting your Okta implementation.
2. Configure the required attribute mappings on your Active Directory/LDAP Connectors to ensure the required attributes are synced to the OneLogin Cloud directory to enable the core user profile to match what is currently in place in your Okta environment.
3. Sync several test users and validate that the user profile in OneLogin matches the profile in Okta and that the required OneLogin roles and groups have been automatically allocated to the user.
4. Inform your test users to log into the new OneLogin environment and validate that authentication against your AD/LDC is working as expected. The test users will be forced to complete Okta MFA before they can establish a session to OneLogin where they can now enroll securely to OneLogin MFA.
5. Sync the rest of your user base as required from your AD/LDAP into OneLogin and review your environment to ensure the number of users matches the expected outcome.
6. Plan your communications to instruct your users how to sign in to the new OneLogin App Portal with their existing Okta credentials and how to configure the required MFA factors on their OneLogin account.

So, six steps and you’ve got all your users in. That’s not so bad, right?

Cloud-Only IDaaS Architecture

In this case, your desired end state is to move to a solution with the OneLogin cloud directory being your IT directory source of truth and you want to use only cloud-based authentication factors in your solution. You may already have a cloud-only environment in Okta that you want to migrate over to OneLogin, or you may have a Traditional Hybrid IDaaS Architecture in place that you want to take the opportunity to move away from. For this scenario, we have two recommended options to allow your organization to perform a cloud-to-cloud based user migration (both include the migration of Okta passwords, when required).

1. OneLogin Smart Hooks User Migration Hook

With this approach, you can have your users drive the migration of their account simply by instructing them to sign into the new OneLogin environment using their existing Okta credentials. There is no requirement for any additional software to be deployed on premises or any kind of intermediary SaaS automation solutions in the middle to perform the cloud-to-cloud based user synchronization. The only thing required is to implement a user migration Smart Hook on your OneLogin environment. The Smart Hook will run as a fully customizable serverless JavaScript function which will be hosted on our platform on your behalf. It will execute an API call to Okta each time a login request is received for a user which does not currently exist in the OneLogin cloud directory.

The steps you will need to take include:

1. Define the logic required to be contained in the Smart Hook.
2. Define the mapping of user attributes sourced from the Okta API (post successful authentication from the user) into OneLogin standard and custom fields. This will control how attributes are mapped when the new user is created in OneLogin from the Smart Hook.
3. Implement the Smart Hook in a test environment and validate the function is working as expected.
4. Deploy the Smart Hook to the production environment and initiate your communications to users to sign into the new OneLogin environment with their existing Okta credentials to create their new account.
5. Remove the Smart Hook once all required users are migrated.

To assist with this approach, we have published an example Okta User Migration Smart Hooks in our public GitHub repo. You can also watch the video below to see how this user migration process works.

2. OneLogin Inbound SCIM Provisioning

With this approach, you can enable an inbound SCIM interface for your new OneLogin environment which can be used to create/update/delete users from any SCIM compliant client systems. It is simply a case of using the App provisioning capabilities built into your Okta solution to outbound provision your users out of Okta and into OneLogin. This solution can be configured to include the current Okta password in the SCIM payload sent to OneLogin or exclude it if required.

The steps involved in this approach are:

1. Enable the inbound SCIM interface for your OneLogin environment by engaging with your account manager.
2. Create a SCIM provisioning application in Okta to connect to your SCIM endpoint for your OneLogin environment.
3. Define the relevant attribute mapping on the SCIM Application in Okta and provision some test users to your OneLogin environment. Validate the test users.
4. Update the SCIM Application in Okta to provision all required users in your Okta environment to OneLogin. Review your OneLogin environment to ensure the number of users matches the expected outcome and initiate communications to instruct your users how to sign in to the new OneLogin App Portal with their existing Okta credentials and how to configure the required MFA factors on their OneLogin account.
5. Delete the SCIM Application in Okta and disable the SCIM endpoint on your OneLogin environment once all required users are provisioned.

We will be publishing a new KB article in the coming weeks outlining the detailed steps required to configure the inbound SCIM solution.

As you can see, there are three straightforward ways in which you can get your users into OneLogin as part of your project to migrate from Okta. Once you have your users loaded into OneLogin and the relevant authentication factors set up, you can then start to plan how to approach your application migration, which is the topic for part two of this blog series. Stay tuned for more on that soon!