Transcript
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, we 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 what's the set of 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 workforce, Cedars-Stone Workforce Dev. You can see zero applications here at the moment, and then we've got our fictitious production environment, then Cedars-Stone Workforce 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 Cedars-Stone 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 Cedars-Stone Workforce, which you've connected to Spacelift, and 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 a 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 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 a Ansible playbook and our export.apps.yml 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 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 you 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 repository for our developer instance for our OneLogin environments or 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 you 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 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. Okay, 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 location. 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 virus 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 there 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, and that will be the person responsible for completing the final configuration of the application connector. And 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 you 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. So we can see that it 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 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. 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. We can see which roles are related to providing access to this application. So we can see here the role AA-AWS-IM identity center is the role that will 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 one login 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 as 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 okay, 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. This will be applied now, and we should see the additional configuration now in our one login 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, okay, 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 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 one login 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 one login admin console. So for example, he can go in and update the OADC 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 the 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 one login and the reflection application in the previous example, and let's assume that he has done all that and everything has been tested and the applications have been re-federated and reconfigured to use one login 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 on 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. In this case, we're going to just go ahead and merge without any additional approvers in our demo environment and just say, merge the pull request and merge 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 change there 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, one login instance. And again, in a moment, we should see those 210 resources now have actually been successfully applied. So if we just have a look here, and our run, we can see now it has finished. So as quickly as that, our 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 resources 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 dev environment.
