[MUSIC PLAYING] [VOCALIZING]
Hello, and welcome to this session on how to enhance your authentication flows through smart hooks. My name is Torsten Westphal. I'm a pre-sales engineer with One Identity. And with me today is Mark Maguire, and we're going to show you how to enhance these authentication flows for specific needs through the OneLogin smart hooks.
In terms of agenda, there's quite a lot of things to go through. First of all, what are smart hooks, what do we need to implement them, and the different sorts of smart hooks we have-- in particular, the pre-authentication smart hook-- how to enhance smart hooks by introducing variables.
You could even look at how to create your own Node.js package and have them managed through the NPM platform. Some tips and tricks, and then we're going to see a short video on how to implement a smart hook via Postman.
And then we're going to look at a whole series of different deployment methods through, for example, Terraform and other more in-depth deployment options, smart hook logging, how to get the most of information back from what happens once we put a smart hook, and then several options that we're going to show different scenarios we're going through and how this could maybe give you some ideas in how to enhance your authentication flow.
But first of all, what are smart hooks? Well, they are basically just code snippets in JavaScript. They can alter the login flow, which allows you to extend the OneLogin solution maybe to fit a unique need you might have for your business.
So as there are code snippets, we run them in AWS Lambda. It's a Node.js runtime, so there is no other technology required. We just push them to AWS Lambda and connect them to your tenant. And the great news is that there is nothing else to put in place or add or even funds, as smart hooks are automatically enabled and your tenant, should you be a OneLogin client.
So smart hooks are defined and created by the OneLogin API, right? And if you want to have a look at how they are built, I would strongly recommend you to take a look at the developer website at developers.onelogin.com. And there's a whole section dedicated to smart hooks with some really nice examples and really nice explanation how to implement them.
We actually have two flavors of smart hooks. One is the pre-authentication hook, which is more used on security settings or policies. Right? So when the user logs on, then we look at the context. We look at the conditions, and we would do something with this user security settings.
The other one, the migration hook, is more to migrate users from, let's say, legacy system or other IDP systems into OneLogin without necessarily having the user reset their passwords. But we could capture the password check if the user is, for example, present in the OneLogin database. And if that is not the case, we would just create the user on the fly.
Pre-authentication hook is what we see most commonly. And this is what we'll be discussing today. It's extremely useful, as we can, as I said, change the security policy dynamically based on the context such as from which device am I logging on, which location, maybe a risk score that we can enter. Right?
And this in conjunction can work and leverage the SmartFactor Vigilance AI authentication feature. So if you have SmartFactor as an option in OneLogin, well, smart hooks and SmartFactor can work very nicely together to give that extra layer of flexibility and, of course, security.
The user migration hook, as I said, mostly or solely done for migration scenarios. This is something we usually see in custom identity use cases where we have to migrate users from one platform to the other in a very smooth and on-demand way.
So let's look at the pre-authentication smart hook. When a user enters his username in the login form, as from that moment, we're going to identify him. And we're going to look at his security settings. These are defined in the security policy.
We can then check the condition that we have defined in the smart hook and temporarily put the user into a new policy, which would request maybe a stronger MFA method or which would require to reset passwords.
The user's then being placed in this policy just for the time of his session. Right? When the user is logging out again and logging in again maybe next day or later the day, then we're going to check again through the smart hook if the condition is met. And if not, well, we're just going to continue having the user authenticated and being placed in his normal policy.
So this is particularly interesting if you just want to achieve, let's say, one-time action, like verifying after a certain amount of days if a user has used his MFA or if the MFA is enrolled. Should that not be the case, well, we can force him to enroll into a specific MFA method.
So there are plenty of scenarios we could think of where smart hooks would come quite handy without having to modify the entire settings in terms of security requirements or settings. For example, as I mentioned, we could override Smart MFA, which would look at the risk score. And when the risk score is very low, well, we could decide not to enforce MFA.
With smart hooks, however, you could enforce after, let's say, 30 or 45 days to place the user into a policy which would then require MFA no matter what. Right? Or we could force the user to update their passwords if they haven't logged in for any amount of time.
We could also enforce a specific type of MFA factor without having to change the overall policy settings but just through the smart hooks. We could have the user allow users who are on a password-less policy. Right? They would definitely need MFA in order to proceed with the authentication.
So in this case, we could force them into a policy where we go through the device registration process. And once they log out again, well, they are in a password-less policy. Very frictionless. Very easy for the user. It's completely transparent.
And a good old example would be we would deny access to the platform or application coming from specific IP addresses or geolocation. This can also be coded in the smart hook. And we're going to see an example just a bit further down.
So when you start building smart hooks and you get more and more comfortable, well, it's a good idea to maybe place environment variables. Right? And to include them into your smart hooks logic. The reason is that let's say you have multiple environments, and you want to reuse those smart hooks but without necessarily having to hard code things like maybe the API keys.
We could call them from a variable that we can introduce. So it might be a good idea really to implement that. The other thing is the more smart hooks you produce, you might want to curate them in a node package management system like NPM. Right?
So you can bring them in. You can version them, which is quite interesting because just modifying smart hooks on the fly might be a good thing for testing purpose in production environment that we should have some trace of what has been happened. And Mark will go into more detail on how we can do that, for example, with Terraform.
So the options are all there for you to use. What do we need? Well, the first thing you have to know is that your tenant is already enabled to use smart hooks. So once you have maybe downloaded the Postman collection, we can then upload that.
Nevertheless, we can use them only by going through the OneLogin hosted login page. Right? So the portal. We have to log in through the portal. This cannot be done through APIs.
Certain flows like logging in to OneLogin through the trusted IDP will bypass the smart hook layer. This is something we've come up and we are configuring, or we're trying to get a workaround to avoid this situation.
And then, of course, as we mentioned, SmartFactor needs to be purchased and enabled in your tenant if you want to leverage the risk context in your smart hooks. Now, also good to know we would always advise to use context version 1.10 to pass the most verbose context into your hook. Right? So the more information we have, the more granular we can operate in terms of the hook level.
Node.js 16 or 18 is now mandatory. In the scripts you will find on the developer's site, some are still mentioned to version 12. So just change that to make sure that the hook will be executed correctly, otherwise it will be stuck in awaiting position and not execute, which is a bit confusing.
So if you use external packages, then obviously you need to integrate the package parameter in your hook in the script. And for the time being, only one pre-authentication hook can exist in the OneLogin environment.
So if you want to add multiple conditions or multiple logic, then you would have to append this into the existing logic, so like enforcing MFA and restricting access from a specific location. For example, this would need to be placed into one hook.
Yes, and then this is something very important. Make sure that you always test this in a test environment. Don't rush out and put it in a production environment kind of normal. This is JavaScript, and, as you know, there might be just something missing, a comma or a bracket, and then the script wouldn't function. So make sure extensive testing is done before you place this in a production environment.
Also, keep it simple, lean, and efficient. We have very little time to execute the pre-authentication hook. Usually, it's a one second max. So everything should be done in this amount of time.
And we can scope the-- how do you say the-- can scope the population of users that will be impacted by the smart hook. So we can typically say maybe just administrators will be affected by smart hook by putting them into a specific role, so without having to put everyone into this logic, which can reduce the login time because there's the little execution time, as we mentioned before.
We can then proceed with the authentication. So it's a good idea to maybe start simple, test this extensively, and then place it into a role context where only certain users will enjoy the smart hook.
Onto a little demo video here. It's a very simple example. And you can find all this example on the developer website. In this case, we're going to configure the environment through Postman, place a smart hook, and run a test to see if everything is according to our expectation.
Now, I'm just going to launch this video here. And what you see here is the developer website up. The developer's still onelogin.com. And if you click on the left-hand side, then you will see all the different sections we have.
And, obviously, on the left-hand side, you can see smart hooks. There is a nice overview of what it is all about, basically what I have been presenting so far. This is also where I got my content from. You can see there's the differentiation between pre-authentication hook and user migration hook.
Now, all the way down on the right-hand side, you can find the Postman collection. And this can then be downloaded to your environment, which I did here together with other examples from the developer websites. And there we have it.
You see we have basic functionality and then the distinction between the two hook types. Configure your environment with API credentials. Make sure that you are on the testing platform. And the first thing we have to do is we have to generate an access token for the tenant. This is what I've been doing here.
All good. And then we can go in and start looking at pre-authentication hooks, so basic commands like shown here-- list, get, post, log. And what I'm doing here, I'm checking if there is a hook in place. There is none, so that's all good.
And we can now start by maybe picking an example. Before we can place a smart hook in our environment, we have to create a minimum viable function. This is the post command you see right on the top there, where we have that we need to execute in order to get started.
So by selecting this and sending this off, I now have an ID. Right? This is a hook ID, and the next thing we're going to do, very simple. We're going to check a certain condition. So I'm going to log in here on my tenant password, username password, and an MFA method.
In this case, it's my YubiKey. And this is a very normal smart hook less flow, right? I'm being authenticated. I get access to my tenant or grant. My IP address today is from France. This is where I'm usually connecting from, and that looks all fine.
Now, in this example, I want to have the user connect through a VPN service to a server in the Ukraine so that my IP address changes to Kyiv. Let's go do that. Connecting. And I am now connected in the Ukraine. Just checking on my IP address again.
And if I do refresh, indeed it does say Kyiv. So that's grand. All good. Now, logging on again, up till now there's absolutely no difference. OneLogin will of course see the change in IP address, country, geolocation, and we are going to raise a risk here. But that is for the moment not configured or applied.
So we're seeing there's a sudden change and a high-speed travel probably. But I can still log in without having any restriction. And this is what we're going to change now through a smart hook.
So back in the Postman environment, we are going to select-- yeah, I think it's that one. Right? Deny access based on country code. So just select that, and you will see then the details on the right-hand side. Go into the prerequisite script, and here's where we add the condition.
So if country code equals UA, then we are returning a false result. Right? Other than that, we are not enabling the risk for the time being. But this is what we could do when we have smart factor. Location is definitely enabled, and we're not looking at any MFA-related condition here.
So we're sending this off, and you should get a OK status. You see it is being queued. It is enabled. And then, of course, if we double check again, the hook is in place. You can see it's ready in the status, and that looks all grand.
You can see also the runtime. We're using Node.js 16. So keep in mind to change that from 12, as it might still be in the script. Now, back on my tenant, and if I connect through my page here, this is the moment where we run through the hook. And I'm getting an access denied fairly quick.
Let's have a look at the tenant, the event log. And we can see that the risk is relatively low, 20 on 100. This is not being used. But we can clearly see that the location is now based in Kyiv. And the pre-authentication smart hook has denied us access. So that is precisely what we're looking for. OK? Very simple, very easy.
We can also grab the logs on through the get hook logs. And the more we enrich the context, then obviously more information we'll get. So in here, basic overview, we have the username. We have the correlation ID, and we have other information such as is it a mobile agent, and then, of course, the country code and IP address, which leads to the access denied action from the smart hook.
So what we're going to do is now we're going to delete the hook and question. Just have to fill in the correct hook ID, send this off, and that should get accepted. And a few seconds later, log has disappeared. OK? We can try again.
So this is still the same open window here. Just entering my username. And getting passed this option will then allow me to re-provide my password, my MFA method, and, as we've seen before, I'm getting access to the platform despite the fact that I'm still connected to a Ukraine server.
There we are. So a very short example on how we can enhance security with this smart hook pre-authentication method feature. I'm sure there's lots of ideas now starting to agitate. And with that, I would hand over to Mark Maguire to talk a bit about how to deploy and manage smart hooks, for example, with Terraform. Over to you, Mark.
OK. So what Torsten showed us there is great for deploying smart hooks in our test, just getting to grips with how they work and how to use the technology. But to use this in our production environments and to really take this approach into a more structured environment, we recommend to look at using something like Terraform to deploy and manage your smart hooks.
So basically, we can see that we've got two options at the moment on how to apply and manage smart hooks in your environment using Terraform. So we've got our official OneLogin Terraform provider, which you can find in the Terraform registry. And we have a resource available in that provider, which is handling smart hooks, both the pre-authentication and the user migration smart hooks.
So you can use that Terraform provider to configure and to deploy your smart hooks. Our second option then is we can use a generic REST Terraform provider. This is also very handy for applying smart hooks and updating and managing your configuration.
So we can just see here a screenshot then of our Terraform provider in the Terraform registry. So we can see here this is the official OneLogin provider. And we've got our onelogin_smarthook resource here, which you can use to deploy both pre-auth and user migration smart hooks. I have some examples in the documentation there on how to use those.
The second option then, like we said, is using this generic REST API provider. So this provider is actually maintained by MasterCard. And it is a very, very good solution how to use Terraform to deploy and update smart hooks again on your own OneLogin environment.
And we've got lots of examples showing you how to use this. And we'll see that in further detail as we go OK. So now we have a demonstration where we're going to show how you can deploy and manage your smart hooks using Terraform.
This time, we're going to be using from a Linux environment. So we're going to actually be using Azure Cloud Shell, which is our small little Linux environment which we will basically use. So it's a very handy place to start with because it already comes built in with Terraform and Git already installed in the Azure Cloud Shell.
So it's a great little starting place to start little explorations with Terraform and using Terraform to manage your own OneLogin environment and then specifically smart hooks in this case. So let's have a look at this.
In this demonstration, we're going to look at how to apply a pre-authentication smart hook to a OneLogin environment via Terraform. So let's just start by validating that we don't have any pre-authentication smart hook in place.
So we have our environment here, which we're going to use, ignore22. So if we log in and just validate there's no smart hooks executing, we can proceed to the next steps. So if I just log in as a standard user here to trigger some activity, we get logged in, and everything is fine.
We switch back now to our admin console and have a little look in the logs. We can see the user is logged in, but there was no smart hook executed. So that is clear we do not have a smart hook in this environment. So if we log out there and go back and see our log out event, so we have no smart hooks in this environment. So we're ready to go and apply a hook.
So the basis of this demonstration, we're going to be using smart hook with the minimum viable function, which is held in our new GitHub repository here. So it's in the One Identity pre-sales Automation-OneLogin-SH, for smart hook.
So if we go, we can see we've got Ansible and Terraform folders here. And if we go into the Terraform folder, and we have pre-auth and user migration. In this case, we're concentrating on pre-auth. And we have our minimum viable hook. And in here, we have our Terraform configuration to apply a hook into the OneLogin environment.
And so we also then have a couple of variables to be defined in the Terraform configuration. So we need to define our sub-domain, the name of our OneLogin environment we want to target, our client ID, and the policy ID of a new user policy.
So let's go ahead, and what we'll do in this case is we're going to just use Terraform from a command line from Linux machine to deploy. In this case, I have my Azure subscription here. And I've got Azure Cloud Shell bash terminal.
And we can see in this case Terraform is already pre-installed in the Azure Cloud Shell. So this is a good starting point. And we also have Git installed. So it's a perfect little place to test out this solution.
So first of all, we're going to clone our Git repository here with the examples. So if we go ahead and copy this address and run our Git clone command, so just clone this into our existing directory. We see now we have a new folder, Automation-OneLogin-SH. So that is great.
So if we switch into this, we'll see now we have our Ansible and Terraform folder. So let's go into Terraform. And, again, we're going to go into pre-auth. And we've got our min viable hook. So if we switch in there, we can see now we've got our two files.
So what we need to do now is go and set our environment variables. So you can open a little text editor here in Azure Cloud Shell. And again, we'll just navigate to the folder we want, so Terraform, our pre-auth, and our minimum viable hook.
And you see here now we have some variables to define for our target environment. So let's start with the easiest variable, so the name of our OneLogin environment. So ignore22, and let's see. Then we need our client ID.
So if we go into our environment and get our API credential, and we can copy this into the variables file. We don't need to set this. This is already hardcoded, so that's OK for the moment. And then we just need a policy ID for our new user policy.
So in this case, we have created a policy already, which is for new users, this one. And this is just for demonstration purposes for the moment. So let's take this policy ID here and plug it into our variable.
And then we can see we have to set the OL client secret via environment variable command. So we'll do that now in a second. And so if we save this file, and next step, then we can go and set our environment variable.
So we have to copy our client secret here. So if we go now and open this file again, and we can just copy this command here, export TF_VAR_ol_client_secret. And paste it in here.
And then we want to copy our client secret. And so we don't want to store this in a text file like the other variables for security reasons. So we'll just put it in as an environment variable into the terminal and set that now. And it's set.
So now we can proceed to the next steps. So we have our environment variables configured. We have the GitHub repository cloned, and we're ready now to initialize our Terraform environment. So we can start off just running the terraform init command.
And this will pull down our provider that we need. And we can see it's been successfully initialized. So that's great. So now we can proceed to the next step. So now we want to run a plan to see what's going to happen if we run the configuration.
So to do this, we use the terraform plan command. And we're going to also specify which variable file we want. So we use the -var-file parameter. And we are going to say our target_ol_env.tfvars is the file we want to use for our variables.
So if we run this now, you can see we get a prompt back with what's going to happen. So we've got two resources are going to be applied. And we've got our oneloginsmarthook_vars will be created. And we also have up here our actual smart hook itself here, oneloginsmarthook_pa.
So this all looks good and what we'd expect. So we're happy now to go and run an apply operation. So we just go back to the previous command, change the plan to apply. And if we run this now, we get another prompt asking, are we happy to proceed with that plan?
So I'm going to say yes, I want two resources to be deployed. And we run the Apply operation. You can see here now, we've created two resources-- successfully completed.
So this all looks really good. And we can now go back to our target environment. And if we look at the activity logs, we can see here, now, we've created a smart hook environment variable and smart hook itself. So this is really what we'd expect.
So now, we can go and test this smart hook. So as I said, this smart hook doesn't do anything. It's just a minimum viable smart hook for illustration purposes. But let's go and make sure that it's working. So if we go back and log in again as our user-- and this time, we'll see the smart hook actually triggers, and hopefully triggers successfully in the logs.
So we should be able to log in again. This all looks good. That's fine. Go back down to our activity logs, and now, we should see that the smart hook is actually executed successfully, as we can see here.
So we've got the hook ID, and correlation ID, and request ID, and we can see was successfully executed. So this is really good. Smart hook has been activated and is working as expected. So now, let's just revert what we've done. We want to remove this.
So again, with Terraform, it's very easy to remove our smart hook. So we simply go back to our command line, and we want to run the Terraform destroy command. And in this case, we might have to run it multiple times just to clean up-- full clean up.
So if we run the first time, we can see that we've been prompted again for the-- oh, I haven't specified our variable file. So again, we want to Terraform destroy, and define the var file like we did before. So it's target_ol_env.tfvars.
So if we run this, we should now have a prompt to destroy our two resources. So we're going to say yes with this. Now, we've destroyed one resource, you can see here, successfully. But the second one hasn't actually been destroyed yet because it was being used by the other hook.
So that's OK. We'll just do a second destroy command. And now, we should have a full cleanup. So now, everything has been cleaned up. So now, if we go back to our environment, again, in the activity logs, we should see the smart hook has been deleted, and the environment variable also has been deleted.
So everything is now back to normal. And if we go back and log out and log in again, we'll see that there hasn't-- there's no smart hook executed for this login. So again, your username and password, and we're logged in fine.
If we go back to our logs, again, we won't see any smart hook activity-- just a simple login command. So that's just a short overview of how to deploy a pre-authentication smart hook using Terraform and from command line. In our next video, we'll look at using some infrastructure as code platforms to run Terraform commands against your target OneLogin instance.
So now, we have another demonstration. So we're going to look at how we can, again, deploy and manage our smart hooks with Terraform. But this time, we're going to be using an infrastructure as code platform to deploy, and update, and maintain our Terraform configuration and our smart hooks. So this time, rather than using our Linux machine with the Terraform installed locally, we'll be using the Spacelift infrastructure as code platform to roll out and maintain our smart code configuration across a number of different OneLogin environments. So we can see how easy this is using Spacelift Terraform capabilities.
So in this recording, we're going to look at how we can deploy a smart hook to your OneLogin environment using Spacelift, which is an infrastructure as code platform. And so with this approach, you don't need to have any detailed knowledge of Terraform, or how to use Postman, or Linux skills, or an on-prem management server. We can basically use the infrastructure as code platform to run our Terraform configuration to our target OneLogin environment.
In this case, we're going to use a-- our example Git repository here, we can see, and we're going to use the Spacelift raw Git approach in this solution. So we start off in our infrastructure as code platform here by creating a new stack. So the stack is going to contain our relevant OneLogin target environment configuration.
So we can start off by creating the new stack and just giving it a simple name. So we're going to be using our minimum viable hook in this example. So we'll just give it a name like that.
And also we can add a label to say which environment we're targeting there. We can see that's all good. So we have our smart hook examples in our automation repository here. So we can see Automation-OneLogin-SH.
So we can grab this public GitHub URL and push-- put it into the URL configuration. And then we want to go in and define which actual smart hook we're going to use. So as I said, we're going to use the minimum viable hook option here.
So we can take the last part of the URL there, /Terraform/PreAuth and Min_Viable_Hook, and add that to our project route. So now we can take all the defaults here. So we're going to allow Spacelift to manage our Terraform state in this example, and save our stack now. And everything should be as we need for this point.
So now, we have our stack created. So we can see the name, we can see which environment it's going to target-- our ignore22 OneLogin environment. Now, if we have a look at our variable file, we've got a few variables that need to be defined in the stack we've created in Spacelift.
So if we go into the environment section here, we can start adding some environment variables that we need for this operation to run. So first one is our ol_subdomain. So if we add that in-- so everything needs to be prefixed here with tf_var_, and then our ol_subdomain.
So we can add that. So that's our ignore22. Then we can add our second one-- that's, again, tf_var_ol_client_id. So we can take this-- and obviously, we'll get the value for this then from our target OneLogin environment, where we have our API credential.
So if we click on that, we can copy out the client ID. So we can add that variable as a plain item. Then, the next one we need to add again. So tf_var, underscore, and our client secret.
So again, we need to grab this from the OneLogin admin console. We can go to our automation API credential and add in there our secret. And we can save that as a secret value in Spacelift, so it's no longer visible.
Our smart hook environment variable is already hardcoded in this example, so that's OK. And now, we want to take the policy ID variable. So again, TF_VAR_ol_policy_id_new_user.
So now, we can go to our target OneLogin environment and copy the policy ID that we want to use in this example. So this is purely just for an example in this case. We're not actually going to use it in the smart hook, but again, let's just show how that looks.
So we have that. So we now have our four environment variables defined in this stack. So that looks like everything we need, just like we saw on the previous example.
So we can run manually now a trigger to execute this Terraform run to our target environment. So we can see it's on the preparing step here now, so it's going through initializing and running a plan operation. So we can see now we have a plan with two items to add 0 to change and 0 to destroy.
So that's great. That's what we would expect. So we have our environment variable resource and our smart hook itself. So we're happy to go and confirm this in the console here to run this against our target environment.
And Spacelift will go and execute and apply this now to this Terraform apply command. So we can see now we've had apply complete with two resources added and 0 changed, 0 destroyed. So this is successfully finished.
A lovely green tick there, so all good. We can see in the UI here now again two resources and successfully applied. So this looks like we would expect. And we can see in our run here, again, it's finished-- completed successfully.
And we can see who it was executed by and some more additional information. So at this point, our smart hook should have been applied to our target OneLogin environment. So we can go now and have a look into the security logs events in our target environment.
So we can see here we have a smart hook created event and a smart hook environment variable created as well. So this is great, as we would expect. So let's do a little test now and just make sure that our smart hook has been deployed and it is actually working.
So if we go now and log in-- create some OneLogin traffic here in an incognito session, we can use the same user we used before and just trigger a smart hook to execute. And we can now sign in. And everything is looking fine, so that is all good.
And now, if we have a look back and switch back to the admin console, we should be able to see now some smart hook events that our smart hook has executed successfully there. We can see now, smart hook executed successful. And we can see hook ID and some more information there in that.
So that's simple-- a case-- now, we've deployed our minimum viable smart hook to our target environment using Spacelift. So now, like we did before, let's go and run a clean up operation. So in Spacelift, we can use the tasks option inside our stack to run commands. And in this case, we're going to use terraform destroy command to clean up and remove our smart hook that we've deployed previously.
So just like we did before, we're going to clean this up and bring it back to the previous state. So if we run our command here, this will, again, start off a destroy command. And we can see here, we're going to have two resources to be destroyed.
So we can see we successfully destroyed one resource. And if we run it a second time now, we should see that the second resource has been also successfully destroyed. And our environment will be brought back to the way it was before we ran any Terraform operations.
So we can see destroy complete, and the second resource has been cleaned up as well. So this is now showing we've brought everything back to previous state. And if we have a look in the events, we will see that the smart hook environment variable has been deleted as well as the smart hook itself have been deleted as well.
So just to build on this a little bit further along-- so to further productionize and bring control around your smart hook deployments-- basically, to say here that we can fully leverage GitOps/DevOps principles to use infrastructure as code, configuration as code approaches to store and maintain your smart hooks. So your Terraform configuration maintaining the smart hook configuration to deploy, and also the JavaScript function itself within your smart hook. All of this can be controlled in our version control systems, such as GitHub, GitLab, et cetera.
So this allows us to have strict version control processes around changes to the smart hook hooks layer within your various OneLogin environments. As we mentioned before, smart hooks is a very powerful capability. So if you have one little typo or error in your smart hook, you can find yourself very quickly in the situation where nobody can log in to your environment.
So being able to have that control around changes and also being able to roll back changes using GitOps principles is really important here. So we can see that we can have changes made into our GitHub-- our repository, which can then trigger and initiate deployment runs of our smart hooks to our target OneLogin environments.
And we can have even very nice solutions, where we can use things like pull requests and merge our changes, say, from a feature branch in our GitHub repository into our main branch, which can trigger deployments then to a production OneLogin environment. And then, obviously should any issues occur in the production environment, it's simply a case of reverting a pull request in GitHub, which will then initiate a revert of the config change back to our previous known good state. So it's a very nice way to manage your smart hook configurations and deployments.
So now, we have a demonstration on how to use, again, our infrastructure as code option here to deploy smart hooks via Terraform. And we're going to look at how we can deploy a minimum viable function smart hook to multiple environments. So first, we're going to start off-- deploy it to our test environment and make sure everything's working there fine, and then roll out the exact same configuration to our production environment and have some level of control around deployments to the two different environments and see how this process looks.
So in this recording today, we're going to look at how we can apply smart hooks to a OneLogin environment using Terraform. And this time, we're going to be using an Infrastructure as Code platform to deploy rather than using a Linux machine. So in this case, we're going to use Spacelift, which is a Infrastructure as Code platform.
We've got two different OneLogin environments here that we're going to use in this process. So we've our ignore environment, which is our production environment. And then we have our second environment here, ignore22, which is going to be our test environment.
We then have a GitHub repository here with our Terraform configuration that we've copied in from the examples in our Automation-OneLogin-SH repo. And we can see in the Terraform folder in PreAuth. And this was the one here we copied-- we've copied out the minimum viable hook.
So we've copied this configuration section into our own repository here, and we've got this ready to go now as our source for deploying to our two different OneLogin environments. So we're going to deploy to our test environment, first of all. Obviously, make sure everything's working OK there.
And then if all OK, deploy then the same code to our production environment using the Infrastructure as Code principles and approaches. So let's start. Just into Spacelift, just to show a very quick overview, we've got our VCS connected here in our settings.
We go to our source code, and we can see that our GitHub is connected here. So you can follow the Spacelift guide on how to connect to your GitHub repository. And I've gone gone ahead already and created a stack here.
So we can see up the top our stacks. A stack is going to represent each of our different OneLogin environments. So in this case, I've created a stack here for our test environment, so the ignore22 environment.
And we can see a tag-- our label here for that as well. And then we'll have a second stack then for our production environment. So I've already created this one. We can just have a little look.
You can see here, it's using the GitHub repository test1, the main branch, and this version of Terraform. And we can see then in the environment variables, I've created some TF_VAR_ol environment variables here, which we need. So we've configured the subdomain, where the-- which environment it will target in the OneLogin perspective-- the client ID, client secret, and the policy ID as well that we need for our smart hook configuration.
So this is ready. So let's go and just create a second stack now to show you how this looks. This will be for our production environment. So if we go ahead and create a new stack, and we can say, again, just give it a name-- Smart Hook Pre Auth.
And in this case, we'll say prod, and it's going to be the ignore.onelogin.com. And we can add a label as well just so it's clear which environment we're talking about, and continue. So then, we want to make sure we're connecting into our correct GitHub repository with our Terraform configuration there.
So that's this one, and it's the main branch we're using at the moment. We only have the main branch, so that's OK. We're using everything default here for the backend.
So we want Spacelift to manage our Terraform configuration. So that's part of the server, so that's fine. And again, everything default here, and we can save the stack.
So we now have a second stack in our Spacelift environment for our production OneLogin instance. So we just need to go ahead here now and update this with some environment variables for the-- representing the production environment. So again, there's four variables we need to add.
So first one we'll just do is the subdomain. And this is called just ignore login.com. So we can make that a plain. Then, we want our client ID, which we can get from our admin console here.
So if we copy the client ID from this one and assign that to this variable here, we can give it a plain value. And then we can do the client secret TF_VAR_ol_client_secret. And again, we can take this from the admin console, and put that in there.
And this will be of a secret type, so it's hidden. And then the last variable is for the policy ID. So we can get that in here-- the name in our variables file in GitHub repository, so this one.
We can define that and then get the policy ID of the user policy we want to use in the configuration. Just for illustration purposes, we're going to use this new user policy we have, and that's the ID of the policy in the ignore production environment. So we can define that as a plain.
So we now have our four variables here-- our client_id, client_secret, policy_id, and our subdomain ignore. So this should be now ready to be used as well. So we're now in a good place.
We've got our two stacks for two different environments, and both using the same code, the same GitHub repository, and the same branch. Everything is consistent there. So both of our environments here currently don't have any smart hooks deployed.
So let's go ahead and deploy to this test environment first of all, ignore22, using Spacelift. So if we go to our test stack here-- our ignore22 stack-- and we can see we can either trigger a run to be executed if we push a new commit into the GitHub repository that's being tracked, or we can run it manually with the trigger button. So in this case, we'll just run it manually for the moment, and this will trigger Terraform execution here against our test environment.
So we can see here now the run has kicked off, and we're in the planning step now. And we should-- we can see now we've got two resources, which will be deployed. And so that's what I would expect. So I'm happy to go ahead and confirm that and approve that, so we can confirm in the console here.
And this will now trigger the Apply stage to actually deploy the configuration to our target environment. So we should now see-- we see finished. So we can see it's successfully run.
We can see here now we've got two changes were applied to the environment-- to our OneLogin environment. We've got a smart hook variable and then the smart hook itself both successfully deployed, and everything looks good there. If we go back here to the runs, we can see when it was last run, and who executed it, and then the fact that it did actually make changes-- you can see added two resources here.
So this looks really good, and we can now go and check in our environment and validate that it has been applied. So if we go into our activity logs, we should now see some activity around smart hooks being created. So we can see a smart hook was created, and the environment variable as well was created. So this looks all good.
So let's now do a basic testing and just make sure that this is working OK in our test environment-- so we haven't broken anything before we deploy to production. So we have our test environment here. We can just do a quick log in-- quick test with this one user-- make sure everything's OK. So this is not the correct password.
We try again, and we should be logged in here. And everything looks OK from the user experience. If we go back now and have a look in our admin console, we should now hopefully see that the smart hook executed successfully.
We can see here now that the user logged in, and the smart hook was executed successfully. So the hook ID, correlation ID, request ID, et cetera, everything looks really good here. So obviously, this is just a very streamlined case of testing. In production real-life scenario, you follow your normal testing processes.
But in this case, we're happy that this is good, and we're ready now to deploy to the production environment. So all we have to do is, again, go back to Spacelift, and we have now our second stack. So we-- again, just to confirm, we can see the two different stacks are based on the same GitHub repository and the same branch, same version of code. And we can see that this one was just obviously rolled out a few minutes ago, and we've tested everything, and it's fine.
So we're happy now to go ahead and run this to our production environment. So again, we can trigger this manually with the trigger option. And this should go through the same process and deploy the same smart hook, the same code to our production environment.
So we look at our plan again, and hopefully, we'll see the two-- yeah, two resources to be deployed. So we're, again, offered to approve or reject. So we're going to confirm this, and this should now trigger the Apply stage of the Terraform process to our production environment.
And hopefully, we'll see again two resources successfully deployed. And in this case, we've got a problem here, actually, with one of our-- seems like we're not authorized to connect. So we might need to go and check our environment variables. They may not have been defined correctly.
So we have our client ID. So if we just go back to our production and make sure we've got the right detail-- so we've got our-- this is the one here. So this is the client ID.
So let's just check. So I think we do have a problem there, actually. So if we edit the client ID and save that-- and then our client secret, we'll just make sure that's correct as well. So our client secret is here, and we will apply that and save that.
So if we update those-- and let's-- we can retry this. And we're going to retry now, and hopefully, it will be authorized to connect to the production environment now that we've updated the environment variables in Spacelift. So again, we go through the planning stage.
You can see the two resources will be added. And we can confirm this. And hopefully, now, the execution to apply will work now that we've fixed the API credentials.
So hopefully, we will have two resources deployed like we saw in test. So we can see here-- yeah, we have two-- we have a green tick-- finished. So if we go and look again, we can see our smart hook environment variable and our smart hook itself have been successfully deployed into the production environments now.
So we can see here, again, the runs finished successfully and everything looks good here. So this has deployed the exact same code to our production environment. So now, we can go ahead and have a look in our production environment and make sure we see the smart hook being deployed, and then do some quick testing.
So in our production environment here, we can see smart hook created and the environment variable created as well and everything looks good. So let's go and do some testing now in production and just make sure everything is also working there. So it's not that one we want.
We actually want this one. So again, we'll just do some very basic testing with a user login here and make sure everything is OK. So this user here-- and again, try to remember the correct password.
And we should be logged in here now. Everything looks OK. So that looks good. And if we go back now and have a look in the activity logs, we should see that the smart hook is executed successfully in production as well.
So there we go. We can see execution successfully, and all of the hook ID and correlation ID as well listed. So that's just a very high level overview to show how to roll out a smart hook to multiple environments using Terraform, and then using the Spacelift as an Infrastructure as Code platform to help roll out. So I hope this was helpful. We'll have a follow-up video now on how to go ahead and actually make changes now to your smart hooks using the same principles as we've just seen here. Thank you.
So now, it's time for another demo. We're going to look at, in this case, actually rolling out a change to your smart hook solution across your multiple environments. So we're going to take the scenario where we get a business requirement in to deliver a slightly different tailored user experience for the very first sign in that a new user makes.
So we're going to look at how we can change our smart hook logic to deliver a different user experience and direct the user to a different user security policy when the context is available to us-- that it's a brand new or first time sign in-- first time the user has used their account. So we're going to roll that new logic out to our test environment, do some testing there, and then, obviously, bring that in-- make a pull request to merge that then into our main branch in the repository, which will then trigger a deployment run to change the Terraform configuration in the production environment. And basically roll out that same updated smart hook code-- smart hook logic into the production environment to deliver the new business requirement into the production deployment.
In this recording, we're going to go over how we can now make changes to our smart hooks that we've deployed through Terraform using our Infrastructure as Code platform. So just a recap of what we have, we've got two different OneLogin environments here.
We've got our ignore22, which is our test environment, and we've got our ignore.onelogin.com, which is our production environment. And currently, both of the environments are using the exact same smart hook.
You can see here, using the same repository and the same branch, and the same commit, and everything is exactly the same. We've got our GitHub repository here with our smart hook code-- our Terraform configuration in here. And this is basically-- everything is as it should be.
So we'll just show-- let's take the example where we've had a request to make a change to our smart hook so that we can give a new experience-- different experience to a new user signing in for the first time. So let's say there's a business requirement for such a new feature.
And so let's just make sure and show the current experience. So when we-- if we create a new user-- so let's just create a user here-- jane.test. And just validate the current experience.
So create a password for Jane. And you can see the Jane security policy is the default security policy. So if we just sign in now that account and just validate what the experience is-- so we get signed in here. The smart hook is executed, but it hasn't done anything, and we just get a standard sign in.
So if we go back and look at the logs, you can see the smart hook executed, and everything's fine, but it didn't actually change anything. It didn't do anything at all, so it's just passing through all traffic. So let's go ahead now and see how we approach making a change to the smart hook.
So we're going to obviously want to make a change, deploy it into test, validate everything in test, and then deploy into production once everything is OK. So we can go back to our GitHub repository with our configuration, and what we can do is we can create a new branch for our new feature.
So we can say new branch, give the branch a name-- Feature-NewUserXP-- NewUser is fine. And so this will create our new branch and copy of configuration-- our code in the default branch. So now, we can go into Spacelift, and we have our production and our test environment, as you saw, about using the same repository and the same branch. So let's go and change our test environment to use our new branch.
So we go in and change the settings and our source code. We should see here now our new branch called Feature-NewUser. So we can point this stack at the New branch.
So now, we have our test environment configured to the new branch, and that's OK. So now, let's go ahead and see actually what changes we need to make. So thankfully, in this example, we can use one of the other default templates in our automation repository that we can take some examples from.
So we have in the automation smart hook repository here in our Terraform folder, in PreAuth, we have actually policy here to switch a new user. So we can take a look at this and just use this as our base to change our current smart hook. So we can see here, we have the JavaScript function for this particular experience.
So this will change the user experience for a user signing on for the first time. So we can use this as our basis for our change. So let's go-- and we're in the new feature branch. Let's go in and just update our JavaScript function in our smart hook.
And we can just go in and do it in the GitHub UI here. So let's edit this file and have a look down for our smart hook function. So we should have a variable here for-- you can see this is our current smart hook function, which is literally just passing through traffic-- minimum viable function.
So let's modify this. So we can just take out this whole section in this case, and let's use-- in this case, we have prebuilt example that we can just use from our examples repository. We copy this in, and let's just paste that in there.
So now, we have our extended function here. We can see we've got some conditional statement here. If the context.user.last_login does not exist, we're going to do some-- switch the policy and write some logs.
Otherwise, we're just going to log that this is not in scope and not change the policy. So that's pretty simple conditional statement. So let's commit this into our new branch.
And we can give some description. So deliver a new experience for new users as per business requirement XYZ-- whatever. So we can just commit this into the new branch.
So that's fine. That's been committed now. We can see just updated there. So now, we can have a look in Spacelift, and we can see already everyone has actually been initialized and initiated.
So based on our commit that we just committed into the new branch that we're tracking with this stack, we've kicked off a run. And we can see here now that it's-- it needs to be-- it's gone through and needs now the confirmation from an administrator. So let's have a look.
We can see there's going to be one change, so that's what we'd expect. We're just changing the smart hook resource, so let's go ahead and confirm that. So that should go ahead now and apply the Terraform configuration to our test environment here in ignore22.
And so we can see, we have changed one resource here, and it's successfully finished. So smart hook object has been changed, so this looks good. And again, you can see here it's finished, and all is good-- one change.
So now, if we have a look at our logs in our test environment-- and let's just see has the-- you can see here, yeah, the smart hook has been updated. And our new code now should be pushed down to the smart hook-- the new function. So that's OK.
So now, let's do another test. So if we take that user, jane.test, and let's just delete this user and create it again and see if the user experience now is what we want for a new user signing in for the first time. So again, let's just create basic user-- so jane.test.
Brand new user-- we can give a password again. Just sign in. So just to be sure-- we can see, again, the default policy has been applied to Jane.
And if we have a look at our policy, we have this new user policy. So this is the one we're going to switch in-- switch the user into if they're a new user. And we can see that we have a simple message here just to show the difference in the different policies.
So new user welcome. We know if we hit this, we know we hit the new user policy. So our smart hook logic is going to change Jane from using the standard default policy to use the new user policy based on the context of her being-- for signing in for the first time.
So let's give this a test and sign out the previous example here. And now, let's hopefully see the new behavior kicking in. So again, jane.test, and our smart hook was executed there in the background.
And we can see now we've reached the new user policy. So we have successfully modified and changed the user experience now for a new user. So that's fine. We can accept that.
And that all looks good. So if we go back and have a look at our logs, we'll see the smart hook executed successfully. And there's all of our detail here. So we can see that the hook is working. The new user experiences is all good, and this is all fine from our test environment.
So we're happy to go ahead and upgrade and update the production environment with this new logic. So the best way to approach this is really using-- in our GitHub repository, we can create a pull request, and we can merge this.
So we can see the Feature-NewUser has four-- has pushes, so we can compare and do a pull request. And just very simple example-- you can just go through here and merge the pull request with some comments that-- ready for Prod-- fully tested a new function in Test.
And OK, and we can merge this pull request. And we'll see now, obviously, our code has changed in our main repository. So if we now have a look at-- back to Spacelift, we can just refresh here.
We can, hopefully, see here now production-- some change. So we can see already on the production environment, something has triggered. So again, just to confirm, this is using still the main branch.
But we've committed those code changes to the Terraform configuration into the main branch, so that has triggered a run here in Terraform in Spacelift. And we can see this was started by a Git commit a few moments ago. So we merged the pull request for that Feature-NewUser branch.
So we can go in and have a look at this. So again, this is awaiting an approval from Spacelift administrator before it actually deploys. So we can see one item to change.
So this is exactly what we would expect. We've just tested it in our test environment. Everything was fine, so happy to go ahead and push us into production now.
So again, this will carry out the Apply operation on our production environment, ignore.onelogin.com. And you can see it has finished successfully. And again, we've got one change to our smart hook PreAuth object here, so exactly what we would expect.
So that looks good. So then, we can just make sure now in our production environment we see the smart hook updated. And we can test the new user experience then with a new user. So you can see the smart hook is updated.
So this is what we'd expect here in the production, so all good. So again, let's now create a new user. And in production, we have a user, jane.test. We don't, so that's fine.
So let's just create, again, the same really simple user and check that the user experience is different on production just like we saw on test. So again, we can see Jane has the default policy. And we're going to, hopefully, see her sign in switch to a new user policy just like before.
Let's create a password for Jane here. So again, we can see in our policies here in production environment, we have the policy here with the new username. And this is the one we've used in our configuration in Terraform.
And again, this is a very simple message just to say, welcome new user. So just an example of changing the security policies based on the context. So we're now ready to test in production.
So if we just go to our production environment with our new user and validate then that the user experience is different for a first time user. So again, jane.test. Our smart hook has actually executed already In the background there and given us a security policy.
And we can see here, again, it's the new user policy. So based on the context of the first time sign in, the new user policy has been invoked rather than the statically assigned default policy. So we can accept that.
We're going to be signed in there to the portal. And if we go back and just make sure here-- we can see smart hook has executed successfully, and everything is working perfectly. So we now have implemented our function change and our code change, and both environments now are using the same the same version of code.
So we can just go in now and update our test stack and point it now at the new-- at the main branch now that we've rolled it out to-- into the main branch. And everything is fine here. And then obviously, if we want, in GitHub, we can go-- and now that we've implemented our change and everything is working fine, we can go ahead and delete that new feature branch, if we like.
It's no longer required. So it has been merged, and keep everything nice and tidy. And you can see, basically, everything now is updated, and our smart hook logic in our function here has been updated.
So we can just validate that our new experience is fully visible and auditable here. We can see the new function and everything was rolled out in a very streamlined fashion across the multiple environments. So just an example of how to now go and actually implement smart hook code changes through Terraform using Spacelift as a platform to deliver those changes.
So now, we're just going to talk a little bit about smart hook logging. So you can see here in our screenshot, we've got an example of smart hook execution event. So we can see successfully executed in this case, and we can see some information-- hook ID, correlation ID, request ID, et cetera.
So just to say that this logging here is high level logging to basically let you know if smart hooks are executing successfully or not and what users have been impacted by smart hooks, et cetera. But it does not give you the full level detail of the conditional logic that actually takes place inside your function-- inside your smart hook function about what actual decisions were made to switch into different user policies based on context, et cetera. So to see full smart hook log level detail, we need to poll the hooks, slash, id, slash, logs endpoint to basically gather our smart hook logs with the lower level detail around what has actually executed in the smart hook.
So just to show then in terms of good practices here for actually enabling logging them within your smart hook function, you can see here we've got-- whenever we're using the console.log command or console.error command in our JavaScript function, anything logged here will actually be written into the smart hook logs, and can be retrieved then by polling the logs API. So we can see some-- we'll see some examples of how to do this in some of our examples in our GitHub repository. And we'll see how this is very helpful when you're troubleshooting issues or trying to figure out what has gone-- what has happened in a particular user experience with your conditional statements.
And then just lastly here to say that in terms of the smart hook log failed event, that you may come across from time to time, just to make everybody aware that there are actually two different scenarios where this event can occur. So the first scenario is basically where you do have actually some kind of bug in your JavaScript function, and the smart hook itself could not actually execute.
So you actually have a bug in your code. You need to go and fix that and then reapply your smart hook. So that's the first scenario. The second scenario then is where your smart hook actually has executed, but the conditional logic in your hook has actually resulted in a deny access condition.
So this is basically letting you know that we have-- smart hooks has denied access to log in for a particular user based on some context or conditional logic in your actual smart hook function itself. So just bear that in mind if you are coming across issues or troubleshooting. There are two different scenarios when you will see that message.
Just had to point out our new GitHub repository here with some really nice examples of different things you can do with smart hooks. So at the moment, we've got examples in our Terraform configuration format, so you can have a look at those. I hope to bring some Ansible examples in the near future as well.
So you can check that out there at 1id-presales/Automation-OneLogin-SH. So this should be expanding and building on this over time. So please check that out.
So now, we're going to look at some actual smart hooks in action and doing some really interesting things and adapting user experiences here. So the first one we're going to look at is actually onboarding a new user in the passwordless flow, and basically bringing them a different user experience than once they've added an additional authentication factor. So we'll see the new users onboarded with email authentication factor.
They'll get an email to their mail and have to find the access link and click the access link-- the magic link to authenticate. And once they're brought into the portal then, they'll be displayed an option to enroll OneLogin Protect, which they'll go ahead and pair their mobile device with the OneLogin Protect service. And then we'll see that when they log in then for the second time, the user experience then will be different.
They will no longer use the email magic link factor to authenticate in their passwordless experience, but rather use-- the OneLogin Protect will be used now that that authentication factor is available. So the smart hook is dynamically reallocating user security policy based on the authentication factors that are available for that user. So there's a really common use case for using smart hooks here, and let's see how this looks now.
So we can see our users just received an email notification. Their account has been created. So they can click the login link here and start the login process for the first time.
So they can enter in their username. And you can see here they'll hit a user policy now requiring email magic link as their first factor. So they received their access link, and they can go ahead and click on the access link to authenticate. And we see now they're logged into the portal.
So at this point, they don't have access to any corporate resources-- only the one tile here to enroll OneLogin Protect. So they can go ahead and start the process to enroll OneLogin Protect. Hit the Activate button, download the app onto their phone, and scan the QR code, obviously, to pair their phone to the service and link this authentication factor to their account.
So that's been done successfully, and everything is fine. So we can have a look at the profile, and we can see back again on the app portal that the user doesn't have access to any resources yet. So we log out and we start a new log in. And this time, now, our smart hooks behavior should change the OneLogin flow.
So we can see now that we've gone logged in, our login flow has started, and we hit the OneLogin Protect authentication factor. So our policy has been uplifted from the email magic link to using OneLogin Protect authentication factor. And now, we can see since they've logged in with a stronger factor, they can now access corporate resources.
So our next demonstration, we're going to look at how we can use the app context in a certain scenario here. In this case, we're talking about in CIAM use case, where we don't actually want people to be able to log in to the OneLogin portal. Our CIAM users-- or B2C users, we only want them to be logging into our CIAM application and not logging in directly to the OneLogin portal-- the app portal.
So we don't want them to see that. So in this situation, we can use smart hooks again, using our app context to actually block authentication requests that don't have an app ID reference in the app context. So this means they're signing in directly to the OneLogin portal. So we want to block that in this CIAM example.
But we don't want to block that for all users. We still want some admins or some internal users to be able to log in to the OneLogin portal. So we're going to show how we can use the conditions and scoping the smart hook policy in this case to only be relevant for a particular OneLogin role. So we can scope that the OneLogin roles dictate which users are actually impacted by a smart hook or not. So we'll go through how we can then add the role to a user to bring them into the scope of the smart hook, see the user experience, and then remove the user from the role so they're no longer impacted by smart hooks.
So if we look into our automation repository, we can see we have an example here for blocking OneLogin portal in CIAM use case. So basically, this is where we want to use the app context in the smart hook context to use that information to change the login flow.
So if we start off, just to have a look at the current experience. So if we can log in with our standard user here and just check that we don't have any smart hook defined in this particular environment. So we can log in and log out. And jump back now to the Admin Console, and just have a look at our activity logs.
So we can see no smart hooks are present at the moment in this environment. So if we go now to our Spacelift environment, we have a stack already configured here. This is pointed now at our example for the CIAM portal being blocked.
And we can see here all the configuration. And we have our environment variables defined here. So again, we're using the ignore22. And we have our policy ID here.
So this is the role ID. So the role ID of-- that's going to be used in the smart hook context. And we can see here this role defined in our environment here, and there's the role ID, as we saw.
So we can go ahead now and run manually this smart hook to execute against our target environment here. So we'll have the standard cycle here of a plan, and then a confirmation from our admin, and then the smart hook should be deployed. So we have our resource to add you can see here. So we're going to confirm that we're happy enough with that.
And this will trigger the Apply stage now and Terraform to actually run this smart hook against our environment. So we can see we have one change. And we've finished that run. So we have a look in our admin console now. We can see our smart hook was created.
And we can have a look now at the poll-- at our example user here. So at the moment, they do not have the role that we've defined in the smart hook allocated to their account. So if we log in again with that user, we shouldn't have any different user experience.
And so they should be able to sign into the portal here. That is the case. All good, so we can log out again. And if we jump back into the event log, we can see now that there was no activity smart log-- smart hook activity for the user, because they're excluded from this smart hook based on the scoping condition.
So everything is what we would like there. So what we can do now is go ahead and, obviously, bring our example user into the scope of the smart hook. So if we can go find the user and add the smart hook role we defined. So if we add the SH_Role to their account and save that, they now will be inside the scope of the smart hook that we've rolled out.
So if we try and log in now with that user to the portal, we'll see we're getting blocked by the smart hook based on our app context configuration. So as you can see, again, it's denied. So now that our user has been given the role, they're no longer able to sign in to the portal.
So let's remove the role and just sign it again, and make sure everything is working for users that are not inside the role. And again, we can log in here with our password, and we can see that everything is working as we would expect once the user isn't in scope of the policy. So we can see then in our logs some smart hook execution failed, and these are the cases when our context was met.
So we can see beforehand, the user was able to log in when they didn't have the role. And when they were allocated the role, that was in the scope of this policy. They're getting execution failed event, and they're not able to log in as per our desired business logic. So everything is looking exactly like we would want to see here at this point.
Our next demonstration now, we're going to show how we can extend our OneLogin context using, in this case, an external system which is going to be a Redis cache environment. So we're going to show how we can store additional information or make our own context about certain login behaviors and store this actually in an external Redis cache, which we can access from our smart hook serverless environment.
So we're going to show how we can actually-- we're going to store authentication accounts. So how many times-- each time a user tries to authenticate, we're going to store that in our Redis cache. And then we're going to build some conditional statements to say, if the user is trying to authenticate more than three times within a 60 second period, and we're going to assume that it's some kind of malicious activity-- possibly an MFA fatigue type attack.
And we're going to switch-- you're going to use smart hooks to switch the user into a different user policy. In this case, a policy, which has the push notification feature for OneLogin Protect disabled. So we'll see that the user can use push notifications up to the point where a threshold is breached, and then the user experience will switch into a different policy, which blocks push notifications and requires an actual OTP code to be entered into the login screen from the OneLogin Protect mobile app.
So we can just see that this is a very flexible and can be-- you can imagine this can be expanded to take care of various other scenarios you might think of. So please check it out.
In this demo, we're going to look at how we can use contexts that's stored in an external system to modify our user sign in flows. So in this case, we have an example where we're using Redis cache to store some context about authentication requests. You can see here, we've got two variables for our Redis host and our Redis password, so they need to be populated with our relevant values.
And then down in the smart hook function itself here, now we can see some of the configuration. So we have an auth count constant here, which is reading from our Redis cache. And then we have our simple conditional statement here.
So if the authentication count is greater than 3, we're going to switch the user policy ID, and then the authentication count will expire after 60 seconds. So then in our actual smart hook configuration, we can see we've declared the NPM package for Redis in our config. So that will be used in our hook function.
So let's look at the environment here-- the user experience when we don't have any smart hook in place to control this kind of behavior. So we can see we've got a passwordless policy here using OneLogin Protect. The user is being sent unsolicited push notifications, which they're obviously rejecting, and verification unsuccessful is logged.
So we can see this can keep going on, and on, and on, potentially until user might give in and actually approve one of these unsolicited push notifications. So we're going to look at how we can-- how it looks now if we change this behavior with smart hooks. So we can see here in the admin console here now with a whole load of denied authentication requests.
So the user's been rejecting those push notifications, obviously. So this looks already suspicious kind of activity in the logs. So let's go ahead and deploy now a smart hook to a give some additional protection, let's say, in this scenario.
So we have our smart hook-- our stack already defined here in Spacelift to use this example from our automation repository. And we're going to run this there now against our target environment. So we'll go through the standard flow here with the planning phase.
We can see for new resources will be deployed to our target OneLogin environment. And we can confirm that. We're happy enough with that. And go ahead now with the Apply phase of this Terraform run.
So we can see now we've successfully finished. And we have four new resources created, so our smart hook itself and then three different environment variables. So if we have a look in the events now, in the admin console, we can see that we've created a new smart hook, and we've got a few new environment variables created as well. So this looks all good.
Now, let's have a look at the policy we're going to switch into. So when this behavior is reached that we've defined in our conditional statement, we're going to actually switch into this policy here. And this policy has the push notifications disabled on the user policy, and also a simple system use notification message just to make it clearer in the demo that we have switched the policy.
So let's see the new sign in behavior now that we've implemented the smart hook. So we can start creating some traffic again, just like before. And some unsolicited push notifications being sent to our user here now, which they're going to reject. So there's the first rejection.
And we'll try again with the second attempt. And again, push notification will be sent to the user's device, which they're going to reject. And now, the third attempt. So this should be reaching now the threshold that we defined in the smart hook to change the behavior.
So we have our third rejection there. And now, our fourth attempt. We should see now the policy has been switched. So we can see now, we've switched into a policy here that has the push notification capability disabled for OneLogin Protect on this user policy. So our smart hook has kicked in and changed the user experience here to protect our user from the MFA fatigue attacks.
So we use our OTP code to sign in. And we can see the notification here for our demo to say we've switched into the stronger policy. And then our user signed in now to the portal, and they have been protected from the MFA fatigue attack. If we can have a look at our event logs, we can see now we've signed in successfully. So this is just showing how we can use the context we're storing in an external system-- in this case, Redis cache-- to dictate the sign in flow and the user experience.
And then our last demonstration, we're going to show how we can basically extend the extensibility of smart hooks. So in this case, we can show how we can call another external function from our smart hook service. So this allows us to trigger more complex workflows perhaps, where we can use a smart hook to make a call to another Azure function or another AWS Lambda service, et cetera, to go and do certain activities based on the smart hook being the trigger point.
So in this case, we'll see how we're able to make a call actually out to an external Azure function, which actually calls back the OneLogin API to update the custom attribute on the user. So in certain-- when certain contexts has been met-- so in this case, when the user has registered or has another authentication factor available against their account, which we can see in the smart hook MFA devices context, when this is the case, we can call this external function, which will then make a call back to the admin API to update the user profile and add a custom attribute to confirm that the user is now-- should now be trusted to access corporate resources. And we can see then they'll be given access then to the various applications in this environment once they sign on with the OneLogin Protect authentication factor on their account.
In this example, we're going to look at how we can use smart hooks to actually trigger external functions to basically extend the extensibility to do even more automated actions. So we have a user here we're going to look at-- James Byrne we're going to use in our example. So we can see James's email address there.
And we've got a custom field created in our environment called approved user. So we can see at the moment, this is blank for James. And we're going to show how we can populate that now with a true value using smart hooks when some conditions have been met during the sign in flow.
So if we start the sign in flow here now, we can see James goes to the login page. And he's going to log in for the first time here, and he'll be using authentication factor email and magic link to authenticate. So you can see he gets an access link sent to his email, which you can go and click on to approve the sign in and successfully authenticated now into the portal.
And basically, now, James cannot see any corporate resources yet because his approved value hasn't been set yet. But he's going to now-- and register OneLogin Protect as a stronger authentication factor. So he can go through the device pairing flow here to scan the QR code with the mobile app on his phone and pair his device.
So now, the user has registered a second authentication factor for their account. So they now have OneLogin Protect enabled on their account. So we can see that now on the security factors, they have two factors available.
So this is the condition now that we'll use to call an external function to-- in this case, we're going to update that custom field on the user in OneLogin. So if we log out now and log in again, our conditions should be met now in the smart hook, which are basically saying that when OneLogin Protect is registered for this user, we will make a call to an external function to go and do some more complicated actions.
So we can see the user is presented with the OneLogin Protect policy here, which they can now approve in a push notification on their phone and be signed in. And everything worked OK there. And now, we can see they can actually access corporate resources, because that custom field has been updated on their account via smart hooks calling our external function-- in this case, an Azure function in this example.
So if we have a look at James's account now, we can see he has the true value on the approved user custom field. So our smart hooks have triggered to call our external function, which basically updated, in this case, James's account through the admin API. So we can see that there just a moment ago.
And so now just to have a little look at the logic, so we can see here we have a conditional statement. If the authentication factor OneLogin Protect is actually registered for that user, then we will fire a call off to, in this case, an external Azure function, which will go and do some more complex logic where needed.
So now we can see that some of the logic in the function here. And just to show that we are updating the user-- so we can see the user's endpoint here. And we're going to update the user in certain situations here. And we can have a look then-- we're going to basically set the custom attribute of approved user to be true in this example. So simple function to update our user.
So just wrapping up now just to show we've got some additional information for everybody to check out. So for sure, the smart hooks section of the developers website is the best place to really study this capability and go deeper into what's possible. We then have our Postman collections there we can see as well.
We've got our Terraform provider, so our OneLogin Terraform provider. You can see a lot of detail on that there. And then just some detail on NPM and some more reading about what different packages are available and can be brought into your smart hook capability.
So that's pretty much everything for now. So thank you for staying with us, and we hope this session has been helpful. And good luck with all of your smart hook endeavors.
[MUSIC PLAYING]