[AUDIO LOGO] Hello and welcome to this video session about integrating OneLogin and One Identity portfolio products. I'm joined today by Solenne Le Guernic. My name is Torsten Westphal, and together we're going to go through how different solutions integrate into OneLogin and One Identity products.
In terms of agenda, what we're going to look at is, well, why do we need integration, followed by a short overview or reminder of OneLogin, what it does, and how it can help. And then we're looking at the integration between OneLogin and Defender, OneLogin and Password Manager, Active Roles, Safeguard for Privileged Passwords, and of course, Identity Manager.
Why do we need integration? Well, we have to secure access to applications and devices doing so by adding, for example, multiple MFA methods. We have to exchange user identity information between platforms. And as we live now in a hybrid world, we need a solution that is capable of handling both on-premise and SaaS infrastructure. This, of course, helps unifying administration and easing the management of these solutions and systems, reducing complexity and costs. And above all, we improve the user experience. And with this, I'm going to hand over to Solenne to give you the overview of OneLogin.
Thank you, Torsten. My name is Solenne Le Guernic. I am a solution engineer at One Identity for over a year now, but I've been working in the IT department for the past seven years as a technical support engineer for various companies like HP, [? then ?] HP, and Citrix. Let me tell you more about OneLogin. And I'm not going to present you fully the solution as this is not the purpose of this presentation, but I will give you some reminder of what is OneLogin and what it can do so that you can understand later the integration with the various products from the One Identity portfolio.
OneLogin is a cloud access management solution hosted in AWS that will help you secure the access of your SaaS application mainly. It provides out-of-the-box access to several MFA methods and centralizes the user management with integration into various directories such as AD and LDAP, but also HR directories like Workday and BambooHR, for example. Using role-based access control, we can help providing a clean and clutter-free user experience so that everything is simple for the end users. Using your Vigilance AI running in the background, we can provide adaptive MFA based on the risk score calculated for every single connection to make sure every user's accessing their portal are accessing it securely. OneLogin can provide access to the different security policies that you can configure yourself. Those policies can be set for user, group of users, or application. And finally, we can help in the lifecycle management of users via provisioning through application for joiners, movers, and leavers.
This is a screenshot of what OneLogin portal looks like. As you can see, very simple. No extra information. Simply the basic tiles and icons that you need with all the applications a user can access. Once again, using role-based access control, a user is only seeing the application they need and nothing more. Here you can see all the security factor available out of the box. And there is an extra one that is not visible on that screenshot but that has been added recently to our portfolio and that is trusted IdP as a factor. As you can see, we have many different ones. We have our own factor with OneLogin Protect, our application that supports both push notification and TOTP passcode. But also OneLogin SMS, OneLogin Voice, and OneLogin Email to receive OTP or magic link.
We still have OneLogin Security Questions because, in some situation, it's the only factor that would be suitable. And we can integrate with biometrics thanks to WebAuthn. For example, you can have touch ID on a Mac or on a Windows machine as a secondary factor. But we can also integrate with various partners like Duo and YubiKey and any TOTP authenticator on the market like Google and Microsoft authenticator, for example.
This is the first view of a security policy. As you can see, we have three different login flows that are available thanks to our smart factor module. The Standard one, basically with username, password, and an MFA factor. A Brute-Force one that will swap password and MFA so that, in case of a brute-force attack, accounts are not constantly locked out. And finally, Passwordless, pretty useful for users logging in from their mobile phone or tablets because it can be pretty difficult to type a long and complex password on small keyboards. So with the Passwordless flow, they simply have to enter their username and validate MFA, and then they can access to their resource.
Finally, as I was mentioning earlier, you can enable provisioning through OneLogin connectors if the application supports it whether via Steam or via API. The provisioning option is available for every application that supports it, and you simply have to tick the box to enable it. And you can add some admin approval layer on top for creation of users or deletion of user, for example. And you can decide what you want to do with the user profile into the application when the user has been removed from OneLogin.
Back to you, Torsten, to present us the configuration and integration of Defender with OneLogin.
Well, thank you very much, Solenne. I will continue with OneLogin and Defender integration and tell a little bit more how we configure it and set it up. Now the integration as of today-- and keep in mind, this is all work in progress-- is as follows. OneLogin would propose MFA for system authentication. We can do this through an integration through our cloud RADIUS server. OneLogin also proposes SSO through the portal. And we use a form-based connector to connect the user into the vendor self service and admin portal.
In a nutshell, the setup is as follows. So we have access nodes which you can see here, which define basically the login client. We communicate on Port 1812, and we share secret, and we have to provide email or SAMaccountname information. This is handled through the RADIUS agent that we deploy on the access node or client, a.k.a desktop. Now a user can either authenticate via the OneLogin RADIUS or through a vendor token or any other OTP method through the Defender's server. And this is handled by the Defender proxy which would check the policy and either route the user to the Defender's security server or to the OneLogin RADIUS server. So this gives you great flexibility in terms of how you want to configure this or what type of population you want to being authenticated on different services.
As I said, we also propose SSO. Fairly straightforward. We have a generic form-based connector for this. And this can be very useful in order to have users register their hardware or software token in Defender. Compatible MFA factors are YubiKey, for example. You can use the same YubiKey for both OneLogin and Defender. As of today, you have to register the YubiKey in each interface or each system. I think over the time, we will make sure that we can drill this down into maybe just one registration, preferably in OneLogin. Or maybe giving a choice. We can use Google Authenticator. So in the same authenticator application, we still need to create two accounts simply to point one to Defender and one for OneLogin.
OneLogin Protect can use the same application and the same account when we're connecting through RADIUS because we are talking to the OneLogin platform. Unfortunately, in the offline world this is not possible as we would always require an internet connection to reach the OneLogin tenant. And then we have the Defender token, which is available also for local login and can be used offline. Very interesting. When you install the Defender token, then this will become the default one for local login.
On we go with the technical demonstration. Server configuration followed by RADIUS configuration, client configuration, and then an example of how this all works together. Just going to look at how we install the Defender Security server. It's pretty straightforward, just mount the CD. Click on the Install button, and then we're going to wait for the prompt to appear. Now you can install this either on the DC or a member server. What we need though is visibility onto the AD infrastructure. These are the options we're going to install. We're just going to use the current account I'm connected with which is on my domain. Now these things are grayed out because they have already been installed. As for the moment, we're just going to change the settings as Port 8080 is already used. Click Next and install. That shouldn't take any longer than a couple of minutes. And once that is done, we will launch the small configuration agent.
And the first thing we have to do is to add the LDAP or Active Directory server, which I'm going to add right now. So we can either use the IP address or the DNS name. Fairly easy. Get some service account credentials here in order to be able to read through AD. Apply and eventually restart the service before we continue. You have several options regarding auditing and testing the connection. I always make sure that we see everything and that we can connect correctly to the service and through AD. This is basically all we need. So what we have installed right now is the security server.
In order to make sure that everything is set up correctly, we're going to check in Active Directory user and computers. And you will notice that there is an extension that has been made. And it should show up Defender, under which we find all the different OUs which hold information about the access node, policies, tokens, and security services.
So to start configuring Defender, we would add an access node. Just right click New, Access Node. Give it a meaningful name. These are the clients that are going to talk to the security server. And it can be either a single PC or a range of workstations or servers defined by IP addresses. Now in this case, we're going to change from SAMaccountname to email address as we want to make this compatible with the OneLogin RADIUS, which by default listens to email.
Now in here, I can add IP address or DNS name. I'm going to add just one single workstation, which is on my network in order to allow authentication onto this security server. We have to provide a shared secret which needs to be copied on all installation paths on the security server, on the access node, and also into the OneLogin RADIUS configuration. We're going to create a new Defender policy. Again, make it easy to understand in terms of naming convention. I'm just going to leave that as such for the moment. And for the sake of this demo, I'm just going to deactivate all these advanced options which are more Defender related. There we are.
Finally, we have to add a security server to tell the access nodes to which server they have to call out to. So in our case, we only have one server which is the one we are working on. Again, same logic. Just put in the IP address. And we can eventually change the prompts that user will receive when they authenticate. Tokens will be filled in later. Users registering their own tokens such as YubiKey or OTPs.
Now, we have to tell every access node to which server they talk to. And in our case, well, it's our Defender Security server. We can also specify who is allowed to use the service. In our case, we're just going to add a sales group. So any member of the sales group will be handled by this server. And we can also add the policy to make sure that we have the correct selections of token or authentication methods. Again, this is more on the Defender configuration side. And this is just to showcase how both solutions, OneLogin and Defender, can be configured side by side.
We're going to add the application. So since this is a form-based application, meaning that we have to send the username and password to the Defender portal which has been installed during installation, we're going to grab that information which comes out of AD since this installation is AD based. We're just going to point to the server and adding parameters such as the password and the username. So the different steps you're seeing here is very simple. We're going to add the name. Make it available in a specific tab. We can make it look nice. I'm adding an icon.
This is the survey we're pointing to. And the parameters we're sending over is the SSO password as well as the username. So in this case, we're using the SAMaccountname prefixed by the domain specification. This is quite important because in here we can say who has access to this application in the portal. And only the user being in a particular role such as the One Identity role will be able to see the application. And if I click Refresh now, the application should show up. There is on the left hand side.
And if I click now, I will be taken to the Defender portal since I'm connected to the portal as the administrator. Well, I'm logged into the portal as the admin. From here, I can take different administrative steps such as finishing the configuration of Defender in terms of tokens, SMTP settings, service account settings, et cetera. Again, this is more on the Defender side, but these are steps necessary to make this solution work.
So as you can see here, we have defined service accounts, roles, log receivers service, and reporting. All very straightforward and quite self-explanatory. We have an activity log as well as warnings, and then of course, the self service settings. So this means that any user who has this application now configured in OneLogin will be able to access the Defender Application and, for example, register different token methods, which you can see here. Options for software tokens such as email verification and hardware tokens. So in my case, I'm using the YubiKey as the default hardware token. We can also set SMTP server settings and other configuration options.
Now the second step that we need to configure is the RADIUS side of things. That means that we are going to tell the OneLogin RADIUS interface to listen to a specific IP address, which would be the IP address of this server. We're going to copy the shared secret that we have on the Defender security server, and we're going to configure the OTP options. So in our case, we are asking for username and password, and our user field is going to be the email field. And you remember this is what we indicated in the security server setup. This is all we have to do.
And with that, we can then go into the Defender Security server. Now, I'm logging on here as an administrator on the security server, and we're going to launch the Active Directory users and computers interface. Go into Defender and we're going to add these policy nodes or access nodes to the configuration. Basically, we're just creating a new client, which is going to be the OneLogin RADIUS. Give it a meaningful name. There are two RADIUS servers available with distinct names and addresses, so you can actually use those.
Important here to note that we have a node type, which is the RADIUS proxy. And make sure we select the email address. This is the first RADIUS server we listen on Port 1812. Just leave the subnet mask as such and copy the shared secret from the RADIUS configuration and OneLogin. And that's it. Now, as we did before, we have to add the access node to the security server configuration right there. We actually have to double click otherwise it will not be taken into account. There we go. And that is that.
Now, the third part is installing the client. I'm now on a Windows 10 desktop which is domain bound, and we're going to install the Defender Desktop Login module. This is, again, very easy, very straightforward. Just click Next, Next, Next, Next. And it should be really a matter of a couple of minutes, and you will be prompted with a small invitation to restart the system. Now at that point, I would highly recommend you do not reboot the system because we need to configure Defender Desktop Login before. Otherwise, there's a slight chance you may not be able to log in again.
As always, we have to add the security service IP address and the correct port which, in our case, is still 1812. Now, this desktop will point to the security server. We further have some options. Very important to copy the shared secret. We could require certain domain users or maybe just a group of specific users to use the service. In this case, I'm just going to reuse my sales group. Obviously, have to check in the correct location for that group. There we are. As you can see here, we can also have the option to allow local accounts to log in without using Defender. Especially for troubleshooting, this is a very good idea. And for the moment, we're going to allow all credential providers to be able to authenticate on this desktop. With this done, it's time to reboot the system.
Now, once the system comes back online, we're going to authenticate again just to make sure that communication is working seamlessly. So you can also see that we already have a new sign in option here. Besides the password, there's also the Defender option. And according to what we've configured now, on the other side, we can check if that is working. So I'm just going to make sure that the desktop can communicate with the security server. And by doing so, we're going to provide the test authentication by indicating an AD user which is part of the sales group and which is the same user we're going to use later for the test. So in this case, I'm going to use the YubiKey the user has already configured in OneLogin, for example. And the result is that we can successfully authenticate the user using his YubiKey. Now, since we're now sure this is working, we can switch to block all credential provider except Defender. And that PC is good to go.
That was the integration overview for Defender and OneLogin. I would hand back to Solenne.
Now that Torsten has presented you with the configuration of Defender integration with OneLogin, let me show you how it would look like for an end user. So here you can see our user here is logging into OneLogin portal using his email address and his password. And we will see in a moment that his primary MFA factor is OneLogin Protect, so he is receiving a push notification on his mobile phone. And once that notification has been accepted, Pierre will be able to access his OneLogin portal.
We're going to change the primary factor and to do so, we need to register a new one. So Pierre is going into his profile and is going to select Add Factor in the Security Factors tab, so that he can add the YubiKey as an extra factor to log into OneLogin and later on to Defender. So we simply select YubiKey from the list. We're going to press on the YubiKey button that is plugged into the machine, and the factor will then be registered to Pierre's profile. We want to make it the primary one, so we're going to set it as the primary so that now OneLogin Protect is not the first MFA factor requested when logging in.
Back to Pierre's portal, and now we are going to register the YubiKey into Defender because we want that factor to be available for both products. So Pierre is going to log into Defender and register a new hardware token. YubiKey is selected by default. We press on the YubiKey button once again. Verify the serial number on the YubiKey itself, and then that's it, the YubiKey has been registered to Defender as well. So now we have one security factor that will work for both same device. No need to have a second one.
Pierre is now logging out of OneLogin. And to make sure that everything has worked as expected, he's going to log back in to see if YubiKey is effectively the primary factor. So once again, email address, password. And now, Pierre is prompted for the YubiKey and not for OneLogin Protect anymore. So the action we performed before has worked successfully and the YubiKey is now the primary factor for Pierre.
So let's log out once again. And let's sign out of the Windows session and log back into the local machine to see how it would work with Defender. So this is the Windows sign in option. As you can see, we now have the Defender option available. So Pierre is going to enter his AD password. And now he's being prompted by OneLogin RADIUS, as you can see, to validate his MFA token. Going to press on the YubiKey to validate the MFA factor. And now he can access the session successfully.
Using what we call Windows domain authentication option in OneLogin, we can make the login to OneLogin portal smooth and simple. And as you can see by simply clicking on a shortcut on the desktop, Pierre doesn't have to authenticate once again. Because MFA has been validated locally on the machine, we don't need to ask him to do it again. And now authentication to OneLogin is done automatically. Let's sign out once again and see what it would look like if, for whatever reason, we are not connecting through RADIUS with OneLogin, and we authenticate through the Defender Security server.
Back to the local session. Pierre is going to enter his AD password once again, and then we will see that it's not the OneLogin RADIUS that is asking for the token but it's the Defender Security server. So we're not going through RADIUS anymore. We still can use the YubiKey because we've registered it through Defender. Se we press on the YubiKey to validate the MFA factor, and then Pierre will be authenticated successfully to his machine. And once again, using Windows domain authentication, Pierre can open OneLogin smoothly and seamlessly without the need to authenticate again. Even if you don't connect Defender through RADIUS with OneLogin, you can still use that option because the machine is domain joined, so OneLogin can still enable the Windows domain authentication functionality when the connection with the vendor is not done through RADIUS.
Now that we have told you everything about Defender, let's talk about the other product available into One Identity portfolio. And the second one in our list is Password Manager. At the moment, the integration with Password Manager is pretty limited. And so what we can do is integrate OneLogin MFA with Password Manager in order to add MFA factor into the password management flow, for example. But you can also add OneLogin MFA into any of the password management flow to secure the action from your end users.
We can also integrate Password Manager using our form-based generic connector to have a tie into OneLogin portal, if that's something that would be useful for users. How do we configure that? We need to use the remote registry rule security token server that is embedded into Password Manager in order to configure OneLogin MFA with Password Manager. So as you can see on that screen, we select OneLogin MFA, and we need to enter the client ID and client secret that are available from OneLogin that you will see in the following slide. We need to enter our OneLogin tenant name and select the user ID attribute that we are going to use. Here it's the employee ID. Just as a side note, you would need to configure that in your ID as well so that this attribute can be used for OneLogin and Password Manager.
As I was saying, we need the client ID and client secrets. And this can be configured into OneLogin. You create a new credential that you will name the way you want, but you need to find a meaningful name to remember what credential corresponds to one integration. Here this is Password Manager. You can select the level of access you want to set. Here we have selected manage all, but depending on the integration you want, you can set it. And once this is done, you will be provided with the client ID and client secret that you can enter in the secure token server to configure OneLogin MFA into Password Manager.
Once this integration has been done, you can add OneLogin MFA into the Password Manager workflow. As you can see here, we have selected authenticated with external provider, that would be OneLogin. And in the password management flow, an end user will have to validate MFA factor before they can reset their password. This is what it looked like on screenshot. I'll show you a short video after that.
Our user, John, is logged into Password Manager, and he wants to reset his password. And during the workflow, he will receive that view saying that he has received a push notification on his mobile device and that notification is available here. To be able to change his password, he will have to validate that notification. And then he will be presented with a view to change his password. Let's have a look at the whole process through a short video.
John is going to log into Password Manager, entering his ID credentials, username. The domain is validated. He can access Password Manager and he will select the password management option because he wants to change his password. So John needs to enter his password to validate the option, then he needs to enter his username again to making sure the domain is present. And then once he will log in, he will receive a push notification on his mobile phone that he will need to accept and maybe validate biometrics if that's something that the mobile device supports. And once this has been done, John will be presented with a window to reset his password. So we can secure the process of changing your password in Password Manager with OneLogin by forcing the user to validate an MFA method before they can change their password.
Now that we have talked about Password Manager, let's have a look at Active Roles. Integration with Active Roles is a little bit more complete than the one with Password Manager, but Active Roles doesn't support SAML at the moment. So we will need a distributed security token server as well to be able to integrate OneLogin with Active Roles and have a Federation and MFA. We hope that Active Role will support SAML in the near future, so hopefully you won't have to add that server in the middle to be able to connect the two products together.
To configure that integration, both products need to be connected to the same domain, the same Active Directory. So as you can see, this is the way it's done for both products. We need to have the secure token server in between. That needs to be installed because this server is not embedded into actual installation. And then we can configure single sign on and MFA.
During the configuration, we also need to create a service account for Federated authentication that will be configured for Kerberos constrained delegation. We have documentation that explains to you how you can do that in depth, but here are some quick steps that you will need to perform if you want that configuration to work successfully. Then we need to install the secure token server as I was saying. And we also need to create SAML application into OneLogin in order to gather the SAML metadata that we can then import into the secure token server, as you can see on the screen.
So we are configuring an extra authentication provider that will become the default one. We name it OneLogin, we configure external Federation, and we add the domain. And here is some metadata that we have downloaded from the SAML connector configured into OneLogin. Then we need to configure the actual web interface because those are the components that we will secure. We are going to integrate Active Roles web interface into OneLogin portal and enable single sign on. And we are going to add MFA on top of web interfaces because we want to make sure the administrator that can make change into Active Roles will have secure access, and MFA is a good way of securing access. As you can see, we are configuring web interface so that they talk to the secure token server and that secure token server will talk to OneLogin. So in the end, the connection is done through SAML and everything is more secure.
Now let's have a look at what it will look like through short videos. First of all, I will show you simply what it looks like when MFA has been added on top of an actual web interface. To make things simple, I've added a shortcut on my desktop. And sorry for the blur. It's going to improve in a moment. So if we open that shortcut for web interface of Active Roles, we can see that authentication is being redirected to OneLogin. And my administrator, John, will have to enter his username, his password. And when you press Continue, he'll receive a push notification on his mobile phone to validate MFA factor.
When this is possible, we can force biometrics as well. This is another layer of security. Kind of a second MFA, if we want, so that we make sure administrators have secure access to web interface because they can do change to Active Directory. So this is what it would look like simply for MFA. And now we can have a look at Active Roles integrated into OneLogin portal using single sign on. So the MFA will still be available here, but not positioned at the same time in the process because the MFA will be validated when logging into OneLogin portal instead of when logging into Active Roles directly.
So first of all, my user, John, will log into his OneLogin portal. So the view is similar to what is seen before, but this is to access the portal and not simply the application. Once again, the username, password, and the push notification will be sent on the mobile phone. We're using OneLogin Protect once again. So John needs to validate that push notification and validate the biometrics, and then he would be redirected to his OneLogin portal. As you can see, the Active Roles admin tile is available, so if he clicks on it, he will be redirected to Active Roles web interface and no need to authenticate once again. So with the secure token server, we can have Active Roles web interface embedded into OneLogin portal and make sure the connection is still secure for admin to perform change into Active Directory.
Now I will let Torsten give you more information around the integration of Safeguard for Privileged Passwords with OneLogin.
Thank you very much, Solenne. Now this is integration which is quite advanced as we have support for OneLogin MFA via API and SSO via SAML 2. So there's a native OneLogin application already present in the portal allowing an access to the appliance of Safeguard for Privileged Passwords.
We have two scenarios where we can provide MFA to authenticate the user. The first scenario we're going to look at is the application initiated, meaning that the user presents himself directly to the Safeguard application. The appliance will call through API the OneLogin MFA and will trigger the token demand. And the second scenario, we will have a more OneLogin-centric approach where the user will connect to the portal and access the One Identity Safeguard for Privileged passwords, providing beforehand the MFA. Again, this allows great flexibility in terms of configuration. And we're going to see how that is being done.
Now, throughout integrations also with other products, we always find the same terms. We are going to provide access to an appliance and for which we're going to propose, for example, Federation Services for identity verification, and then of course, the MFA. So this is something you can see here in the Safeguard access identity authentication pane. And on the other side, we have to configure OneLogin to receive those API calls by providing an API client access.
What we're going to look at now is how are we going to set those up. And we're going to show you the two scenarios accessing the Safeguard for Privileged Password clients. So on the appliance, we're going to go into Safeguard access and, in identity authentication, we're going to look for OneLogin MFA. This is already now being provided within the standard installation package. Very easy to configure. Again, give it a meaningful name. Under DNS hostname, enter your OneLogin tenant URL. So that would be subdomain.onelogin.com. And we have to provide the API credentials set. This is something we do in the OneLogin tenant. So simply click on Settings, API Credentials, and create a new credential set. Give it a meaningful name again to make sure that we use this for a specific purpose. And we would require the Manage All level of access.
Copy the client ID from the OneLogin site into the appliance and the client secret. Now, it is important that the employees can resolve the hostname; therefore, networks should be configured accordingly. Once this is saved, the OneLogin MFA option shows up as here, and we can now start to configure users.
Now user-- again, my favorite user is Pierre here-- he has an identity that comes out of Active Directory. You can see it here in identity provider, email, et cetera. Authentication, for the time being, is being handled by AD, so when Pierre tries to access the appliance, he is being authenticated by AD. Nevertheless, we can already configure this user to provide MFA methods which is, as we've seen before, configured in OneLogin. So simply click OK and that is that.
So in my case, I'm now being Pierre. As you can see, the source of my identity is pointing to my domain. I'm providing my username and my [INAUDIBLE] AD password. We're now receiving an MFA, a token request, or a push notification. And this is being transferred directly to the appliance, allowing me to access the appliance fairly easily. So this is the first use case. Now, change slightly things where we're going to say that we want this user to be authenticated by an external identity provider which is OneLogin.
So same thing. Go into identity authentication. Select external Federation. Always give it a meaningful name. Under realm, just type in the subdomain name of your OneLogin tenant, so subdomain.onelogin.com. Now, here we need a Federation metadata file which we're going to find again in OneLogin for this. Go back to your OneLogin tenant, and we're going to create an application. One identity Safeguard for Privileged Passwords has a native application already existing in the OneLogin catalog. So as you can see, it's a solid true connector. Simply select that one.
Again, as we've seen before with Defender, we can change the picture. Make it visible in the portal. And above all, we need some configuration data. So to start with, we need the audience or the entity ID. And this is something we're going to extract from the metadata file that comes from the appliance. First of all, I'm going to add an access role for this application, and then we're going to look for the necessary things to fill out.
I'm going to download the OneLogin configuration data, and we're going to inject that into the Safeguard appliance. At the same time, I'm going to download the Safeguard Federation major data file. I can close that bit. Head back to the portal because from this file, we now need to extract the entity ID, which you will find on top of the page. So if you look closely, it sits there. So we just need that one. And paste it into the application detail. We also need the link. And this is the internal link IP address to which we're going to send the user for verification. So as you can see it's fairly easy. Just put what is indicated in the example field below. That's fine. Make sure to save that. And we can even put this application in the One Identity-specific tab. I like doing that so to keep things nice and tidy.
Parameters, this is where we indicate what type of information we're sending, the email address-- we're not going to touch that-- and SSO is all configured, as well as the access. So only users having that specific One Identity role will receive the application. As you can see, Pierre has now automatically received the Safeguard for Privileged Password application. So back on the appliance, we're going to now change Pierre. We're going to say that instead of being authenticated by Active Directory, we're going to authenticate him in OneLogin. So the Identity is still AD, but the authentication will happen through the OneLogin Federation and which will appear right here in the dropdown list.
Just make sure that we sent over the email address because this is the value we're looking for. And we can even add a secondary MFA method to this very critical application. So this is what we're going to look here. Maybe not in the first time, we're going to do that the second step. This is great if you want to troubleshoot. Just maybe start testing.
On this case, back to the portal. Login as the user, providing your password and your favorite MFA method. In this case, we're going to use the OneLogin Protect application. To notice, as for the time being, we do not use the YubiKey as an OTP factor. So for the time being, we can only use things like email or Protect. So Pierre has received this application, and if he clicks now on the application, he should be able to reach the One Identity Safeguard for Privileged Password application without further questioning or authentication requests. As you can see here, upper right, that's Pierre. OK, let's logout.
And we're now going to change the settings. And we're going to request for him that he needs additional MFA even being authenticated through the OneLogin portal. And this is very much like what we've seen in the first scenario. The user accessed the appliance even being authenticated or identified by the OneLogin Federation, he would require additional MFA. This can be set on the appliance or directly in OneLogin at the application tile connector level.
The next and last item on the agenda is the OneLogin and One Identity Manager integration. Now, this is quite important integration as we have several options which go a little bit beyond simple MFA authentication. In fact, what we can do as of today is single sign on through the OneLogin portal, provide MFA services, and identity governance, and that directly from Identity Manager. So with the SSA integration we have today in OpenID Connect application, meaning that we can provide single sign on into the Identity Manager administrative console through a prebuilt connector, we also provide MFA support.
For example, for step-up authentication for request or attestation approval, simply what we have to do is connect the OneLogin instance and the communication will be done through API as we've just seen in Safeguard for Privileged Passwords. And now as I mentioned before, we would usually find the same information to be filled in order to run these configuration setups. The most interesting part of this integration is the OneLogin module. This is a module which is now available for installation during the installation process or when you add components into the One Identity Manager configuration.
The integration for us today is focused on mainly setting up and editing user accounts, meaning that we can provide user information directly from Identity Manager into OneLogin, set the permissions required we need for accessing application, providing authentication and authorization, and then, of course, everything that we've seen within Identity Manager in terms of identity and access governance being processed for OneLogin domains. That means attestation, identity audit, user account management and system entitlements, the famous IT self service shop, report subscription, and more. This integration, which OneLogin now provides with this MFA service will replace the Starling 2FA.
Now, since we're going to talk between Identity Management and OneLogin, we're going to use the API version two whenever possible in order to allow us to achieve greater granularity in terms of what we can do on the OneLogin side. We also support the custom user properties or the custom fields, as well as any information that is stored in the OneLogin site.
Some screenshots just to show you how this looks like from the One Identity Manager interface side. But we're going to look at a small demo. We're going to create a new user account directly into the OneLogin tenant. So in here, I'm now in the One Identity Manager interface. And as you can see, down there on the left, where I just clicked, there is the OneLogin option. Now, the one logging option-- we're not going into how we connect this to the Identity Manager-- but once it is connected, you can see that we're pointing to the instance that is running off OneLogin platform. And then here, I get all the information about roles, users, application, policies, privileges, and much more, even custom field definition. So I can have a detailed information, for example, of any user that is living in OneLogin even if it's an independent user which is completely unknown to Identity Manager. I can still query his properties, such as roles and applications.
In this video, what we're going to look at is the creation of an account, meaning that we're going to create an employee directly from Identity Manager using the One Identity logic. We're going to push out this information to OneLogin as you might have the habit of doing so. So what we need to provide is first name, last name. And you remember these are the minimal requirements, as well as the email address. Email address is being composed automatically according to Identity Management rules.
The next step, before we can create this account in OneLogin, is we have to assign an account definition. There you can see that I have my AD and my OneLogin tenant. I select this, save it, and then this will get sent off to the Task Manager which will then connect to the instance, creating through API call directly the account. If I do a refresh now on the OneLogin site-- and this is, by the way, in real time-- that will find Clement Dupont which has just been created. Again, we will find those fields here that we have filled in on the One Identity Manager side.
OneLogin has been configured, for example, to send an email presenting the user with the option to set the password. We can do this straight away of this avoiding, for example, to have to send out any letters or of that sort. The user just clicks on that link and is being directed to the OneLogin instance, asking him to set his new password. Keep in mind that for this example, this user does not have an account in AD. We'd simply create them in OneLogin. And again, using the password we've just defined, and we should be good to go. So as we might have seen before-- well, this instance is new first time log in-- we are now being requested to provide MFA. In this case, I'm going to use the YubiKey since this is available. And I can now access the portal, of course, after having accepted the terms and conditions.
So in terms of authentication, that one's very quick. But of course, the portal is rather empty. This is because Clement has not yet received any roles. And we're going to change that. So there's several options here, such as changing password or adding security factors or changing phone numbers. This is something we're going to achieve through One Identity Manager; therefore, we're just going to head back to the Identity Manager interface. From here we can also see which groups we belong to and above all, what applications we have.
In this case, there's nothing there yet, and we're going to change that now. Back in Identity Manager, we now can take our identity. And we can already see that, where this user is situated, in terms of what exactly attributes he holds as well as account definition in here, it will point exactly to the OneLogin tenant. What we're going to do now is, for example, enter information such as phone numbers and maybe add roles so in order that Clement can receive application. Phone number is important as we can use the phone number to provide SMS MFA.
By setting the department, for example sales in this case, will allow an automation as soon as this information arrives in OneLogin. By hitting save, this is being processed now. We are going to apply what we call mappings in OneLogin and these mappings will then provide the user with the necessary application. So if we are heading back to the portal, we go back into Clement's user information page. There's already the phone number and the sales department. As I said, the mappings are now being executed in background and, since the department field contains the word "sales," we're going to set Pierre into a group into a role. This is to provide best automation possible, again, without having to do this manually.
So when we go into authentication, we now see that he is part of the sales group being authenticated by OneLogin and has a group policy. The applications Pierre is entitled to-- that's the list because this is an automatic mapping. And if we hit a refresh here, now in the profile, we should see the phone number. There it is. And if we go back to his portal, now the application. As simple as that. Now, as this is being provisioned directly by OneLogin, all we have to do is click on the tile with the application, and we're now being redirected to G Suite. And we have to start using our new account.
This is a very nice example just shows how easy it can be to provision different users into OneLogin. This, again, is not even an AD account but a completely independent account that is being handled in terms of application access and security requirements through OneLogin directly. Of course, uses in AD can be provisioned the same way, either through the IDM, Identity Manager, or then through OneLogin directly via synchronization with the Active Directory connector.
Just showing you that we can even provision into on-premise systems. This is a SharePoint 2016 on premise. We are provisioning the user into Office, and we have a pending Salesforce provisioning here. So this usually takes not more than 2 to 5 minutes and should be fairly quick. And as we can see here, Office now has been provisioned and Salesforce needs to be approved. Now this step also could be done by Identity Manager but in this example, we just run the provisioning from OneLogin. And if I click on Office, I should be greeted with a new instance welcoming the new user. And there we are.
The last part of the OneLogin Identity Manager integration we're going to look at the MFA option that we can provide to allow, for example, access for One Identity Manager through OneLogin Federation. So what we're going to do now is we're going to try to access the One Identity Manager interface and, as we have configured that for specific users or specific authentication methods, we're going to point to the OneLogin database. And as you can see here, this is precisely as if I would access the application from an SSO portal, but I'm being redirected through the OneLogin process providing username and password and the MFA method. I'm then being led access to whatever options I have in the interface.
With this, this concludes our tour on the existing integration. As I said in the beginning, this is all work in progress so be sure to come back as we're going to shoot more recent videos on the integration status of this application. A very big thank you to Solenne. And a thank you for you. And I hope you enjoyed that. And hopefully we have the chance to talk again. Thank you and bye-bye.
[AUDIO LOGO]
58:49