Migration of Applications from Okta to OneLogin via Terraform

[INAUDIBLE] we're going to go over how we can migrate applications from an existing Okta environment into OneLogin and how to do this with Terraform. So we're going to use our example solution we've got published here in this public GitHub repository here, Automation-OneLogin. And if you have a look in the Terraform folder and then Reference Environment 01, you can see an example solution description and configuration that we're going to use to do the application onboarding process. So let's have a look at what's involved and set the scene here. So we can see we've got our Okta environment here, which we're going to be migrating the applications from. So we've got 14 applications that are set up in this environment here, and we're going to migrate these into OneLogin using Terraform. So on the OneLogin side, then, we have our-- we've got two instances. We have our dev instance here, which is our CedarStone Workforce dev. You can see zero applications here at the moment. And then we've got our fictitious production environment, then-- cedarstoneworkforce-pp-- and, again, zero applications here. So we then have our Spacelift environment. So we have two stacks set up in Spacelift representing each of our different OneLogin environments, so our developer environment here and our prod environment. And we can see they're both connected to GitHub repositories here for our CedarStone Workforce. And our dev is connected to a test branch, and our prod environment is connected to the main branch. So we can see here, in our GitHub repository, we've got our main branch. So we've got our private internal repository here for CedarStone Workforce, which we've connected to Spacelift. We can see here we've copied in some starting Terraform configuration. So we have our main and our test branch, and these will be where we're applying changes to trigger the automation into the inbound OneLogin environment. So we have also got, then-- what we're going to show and use is an example Ansible playbook which we can use to extract applications from the Okta environment and get them into the format of an application inventory file that we can then use to trigger the Terraform process into OneLogin. So if we have a look in the Ansible folder in the Automation-OneLogin repository, you can see here Export_Applications_From_Okta, and this is the example that we're going to be using here. Finally, then, we just have our Azure Cloud Shell environment here, which we're going to be using to run our Ansible playbook and run this against our Okta environment to extract the applications. And you can see here I've already cloned that repository, and we have here the Export_Applications_From_Okta folder with our example playbooks here. So we're good to go and start the process now. The export of the application list from Okta and create our application inventory file, which we're then going to use to feed into our Terraform application onboarding process. So you can see here I have my Linux machine here, which has our Ansible playbook cloned, and we've got our playbook open here. So all we have to do is define the Okta domain here. So you can see I've set the Okta domain for my environment here. And that's pretty much all we need to set in this playbook. And if we then do ansible-playbook and our export_apps YAML file-- we run this-- this will communicate to the Okta API. So if we put in our Okta API key here in the prompt-- and this will now go and communicate to the Okta API and extract out the applications that are in that environment and create the application inventory file. So we can see there that's completed successfully. If I refresh here now, you can see I've now got an applications inventory JSON file here. So we can see now we've got all of our applications that were in that Okta environment exported out here into a nice JSON file, which we can now use to feed into our Terraform process to OneLogin. So we can copy the contents of the applications here from our Ansible playbook output and basically now go to our OneLogin-- our repository for our developer instance for our OneLogin environment, so our test branch. So that's this one. And we're going to basically update the configuration here to create some applications. So like we saw, we currently don't have any applications here in the developer instance. So that's fine, so let's start the process now to add them. So all we need to do is go and update our locals file in our repository here and add the applications into our configuration. So we can just edit the file here. And we can see here we have an ol_application_object which is currently blank. So let's add in that JSON listing of all the applications from Okta. So we can see here each of the applications has automatically been allocated a connector ID-- so a OneLogin connector ID for that related application that we had in our Okta environment. So that's good. We just need to check now if there's any custom SAML applications that we need to just double check and add manually. So we can see ServiceNow, Salesforce-- they all look good-- Twitter. So now we have two test applications here that the connector ID hasn't been automatically populated. So this is a SAML-- application test SAML-- application. So we need to get the SAML connector ID. So we can have a look here in our export from Okta example. And in our vars file here, we can see we've got the OneLogin connector ID for generic SAML applications set. So we can just copy that and update the SAML app, which is this one. So that's the connector ID for that one. And then the other is a custom SCIM provisioning application. So again, we can grab that ID from here and set that in our test environment as well. So now we should have all of the applications having a relevant connector ID, which is great. And we're pretty much now ready to test this process. So just to say here we've got some configuration we can set, so we can set who's going to be the application owner of the application. That would be the person responsible for completing the final configuration of the application connector. We can say whether the application is going to be a birthright application or not or whether it needs to be allocated based on request and whether it's visible or hidden, and then which custom attribute is related to that application, which is going to provide access to that application. So for now, we'll just leave everything as is, and we will just commit the changes. So just to say that the custom attributes here-- all of the custom attributes related to each application have already been set up in the target environment here. So we can see all of these custom attributes were set up here in the admin UI. And it's not currently possible to do this through the API, so just a small step to add those before you run the Terraform configuration. So we've committed that to our repository. And if we have a little look back, you can see-- if we have a look at it, it's just been updated now-- the locals file. And look at our history-- and if we look at the last commit, we will basically see our application file inventory has been updated. So it previously was blank, and now we've added all of these applications here. So that's great. So that will trigger now a Terraform run to run in our Spacelift environment. So if we go to Spacelift here, we can see there already was a run applying. And, actually, it has already completed and finished. So if we have a look at this, we can have a look at our runs. We can see that it finished there, and there were 210 resources added to the target environment, so our dev environment here. So that all looks great. That applied as you'd expect with all of those resources being created from the Terraform configuration. So now let's have a look at our developer environment. And we should see now our applications-- our 14 applications. There we go. So we can see now-- number of applications, 14. So this-- just double check. This matches with our Okta environment. So we have 14 as well. And these applications now have been created, and we can basically now allocate who will complete the configuration of those applications. So if we just take a look at one of the applications, we can see here that it's been created. It's got-- we can have a look at the configuration and see that the custom attribute for that application is this one. And we can see that it hasn't been set as a birthright application. So it needs to be requested by populating this custom attribute for each user to be true. And we can see which roles are related to providing access to this application. So we can see here the role AA-AWS IAM Identity Center is the role that we'll be giving that access to this application. And we can also see we've got a whole series of mappings, then, that will automate the allocation of access to those applications, as well as delegated administrator access as well. So let's just now update our configuration again because we didn't set any application owners. So if we go again back to our test branch-- and, again, we want to update our locals file and just-- let's update the first two applications on the list. So we have our OneLogin and Reflection application here. So what we're going to do is set application owner. So we have a guy here who is going to be responsible to finish the configuration of those applications. So he's the technical owner for the business unit responsible for these applications. And we'll just make an edit. We need to edit the git file here. So let's add James as the application owner, then, for the first two applications. So we can do that by populating him-- his email into the application owner. And we leave everything else as it is. So we can commit those changes. So that's been committed now to that repository. And again, now, if we look back at Spacelift, we should see a Terraform run has kicked off here to apply these changes. And initializing here now, and we're going to run a plan to make sure this is all OK, and then automatically deploy the changes to the target environment. So let's see. So there we go. We've got 30 resources to change. These will be applied now, and we should see the additional configuration now in our OneLogin environment. So we can see here-- apply has been completed successfully. 30 resources have been changed. So that's great. So now let's have a look at our applications. And our first two applications were the ones we wanted to look at. So let's actually just-- now that we've updated things, we can reapply all the mappings. And we saw that the user James was going to be the person responsible for the two applications to configure them. So we can see James here-- James' account here. And if we have a look, we can see he's been given access to those two applications that he's responsible for, so that's great. We can see here that the two application access roles have been set, so he has those applications. And we can also see-- if we have a look at the delegated admin roles that have been granted, we can see that he has been given a delegated admin role for the OneLogin application and the Reflection application as well. So if we switch over now to how James's view of what he can see-- and he should now be able to provide and perform delegated administration activities on those applications. So we can see here we're signed in as James now. James has that delegated administration privilege. He has those two applications that have been migrated here available to him. And he can now go in and complete the configuration of those applications in the OneLogin Admin Console. So for example, he can go in and update the information for this application here in this example, adding configuration as needs be. Applications have been created in the developer environment. And we saw that James had delegated administration rights to go and finish the application connector configuration. We can move on to the next phase, where we're ready now to update the production environment with the same configuration that's been applied. So we can see here we have our dev environment. We have 14 applications. And we know that James was able to update and manage the OneLogin and the Reflection application in the previous example. And let's assume that he has done all that and everything has been tested. The applications have been re-federated and reconfigured to use OneLogin rather than Okta, and everything is ready to be pushed to production. So we have our production environment here. We've got zero applications there, as we saw before. So we want to now replicate the configuration that was applied and tested in the dev environment into our production environment. So we can easily do this with our GitHub repository and merging our test branch up into the main branch, which will then update the Terraform configuration in Spacelift. So if we just have a look again at our prod environment-- so we can see it's using the same repository as the dev environment, but it's connected to the main branch, whereas the dev environment is connected to that test branch. So all we need to do is merge the configuration changes into the main branch in our GitHub repository. So if we have a look here in our test branch, we can see that there are four commits ahead. So let's go ahead, and we can just raise a pull request to merge this demo into production. So we can create our pull request. And this will start our pull request process. And in this case, we're going to just go ahead and merge without any additional approvers in our demo environment. And I'll just say merge the pull request and demo merge for prod and confirm that merge. So we can see then in GitHub it's been merged here. So if we have a look back again at our main branch-- so the main branch has now been updated, and our test branch is in sync now, just some commits behind, which are not related to any files change. So this is all good. And if we have a look now in Spacelift, we can see, actually, a deployment task has kicked off here for our production environment. And we can see here now we've reached the unconfirmed status. So we haven't actually deployed this automatically into production because it's our production environment. So we want to go and have a, let's say, final approval that everything is what we'd expect. So we can see-- as a Spacelift administrator for this stack, I can see what's going to be applied. So we can see 210 resources will be deployed-- one to change, zero to destroy. So I can go and go through all that and check I'm comfortable with that before running it to production. So in this demo case, I'm happy with that, so we can go and confirm. And we've got, then, a log in Spacelift of who approved that run and when it was confirmed and all the full audit trail, which is great. So then we can go back and see now the apply stage is kicking off here now to run the configuration to our prod OneLogin instance. And again, in a moment, we should see those 210 resources now have actually been successfully applied. So if we just take a look here, and a run we can see now it has finished. So [INAUDIBLE] 210 resources have been added. So that's great. So if we now look at our production environment here and refresh, we should see the same 14 applications that we saw were taken out of Okta into our dev environment, tested and configured there, and then added to our production environment here. So we can see 14 applications here have been added and created, and everything is matching with the configuration in the [INAUDIBLE] dev environment.