Active Roles and OneLogin more than MFA and SSO. Provision access to SaaS systems using OneLogin

[MUSIC PLAYING] In this technical deep dive we'll be demonstrating the benefits of integrating Active Roles & OneLogin beyond the basics of single sign-on and multi-factor authentication, as well as some of the technical details showcasing how this can be configured in your environment. My name is AJ. I'm a Solutions Architect with One Identity, and for the agenda, I'll begin by walking through how OneLogin can provide SSO an MFA to the Active Roles Web Interface. Next, I'll show how Active Roles can drive user lifecycle management processes by synchronizing with OneLogin using the Active Directory connector. Then I'll briefly discuss an example of how you could take this integration a step further by utilizing the OneLogin REST API. And finally, I'll hand things over to Eric to demonstrate how you can enable self service provisioning to SaaS applications from within Active Roles. To kick things off, let's start with a demonstration of how OneLogin can provide SSO and MFA to the Active Roles web interface. First, I'll sign in to my OneLogin dashboard with my username and password. Now, depending on your OneLogin configuration your users may or may not be prompted for multi-factor authentication at this initial sign in. In my lab, I'm using OneLogin smart factor authentication. Since I'm signing in from my home office during business hours, like I usually do, OneLogin's vigilance AI has determined that this is a low risk sign and per my security policy has suppressed the MFA prompt that would normally appear there. However, I have a separate application security policy that will require MFA when I try and access the Active Roles application. So on my OneLogin dashboard I can access all three of the default Active Roles web interfaces. When I select the Admin page before OneLogin connects me to Active Roles, you can see that I will now get prompted for MFA. So on my Android phone I can accept the push notification and provide my fingerprint. Once that's finished I'm taken directly to the Active Roles admin web interface signed in as myself. In order to configure this you'll need a few things. First, in your OneLogin tenant, you will need a security policy applied to your users that requires them to configure and use MFA. You will, of course, need to be using a supported version of Active Roles. And on that Active Roles administration server, you will need to install the rSTS service, which is included in the installation directory, but not installed by default. Finally, you must have the Active Roles web interface. Now this first step here is optional depending on your Active Roles environment. If your Active Roles Web Interface and Administration Service are all on the same server, then this step is not necessary. However, if you wish to enable federated authentication on a web interface that is on a separate machine from its associated admin service, you will need to create a new AD Service account to use with Kerberos Constrained Delegation. To start with this, create a new Active Directory user account to use as the service account. On the Active Roles web server add it to the distributed COM users and IIS user local groups. Additionally, assign it permissions on that server to act as part of the operating system. Finally, configure Kerberos Constrained Delegation either manually or by using the set SPN commands. You can reference both the command line example and the PowerShell script example above to do this via the set SPN command. Now, we can install rSTS on the Active Roles administration server. For more in-depth explanation of what rSTS is check out the video about MFA to the Active Roles MMC and web interface. As a quick overview, rSTS is an internal One Identity utility that allows our applications to support federated authentication without requiring each individual application to implement those protocols and providers directly. Currently this is used by Safeguard for all of its authentication, by Identity Manager for Federated authentication, and it's available in Password Manager for federation both to the admin and help desk pages, as well for use within workflows. In the case of Active Roles this component has been included and available to configure for a while, it's just not currently supported. However, it is on the current roadmap for release as a fully integrated and supported component in the upcoming 8.2 release. To install rSTS on a current version of Active Roles, launch an administrator command prompt and navigate to the web/rsts folder within your Active Roles installation directory. By default, Active Roles will install two program files/OneIdentity/ActiveRoles/ your version number. Then run rSTS /install and wait for the installation to complete. Once it's finished, you should be able to confirm that it's installed correctly by checking for both the secure token server application event log and the redistributable secure token server Windows service. One important note here, if you followed step one to set up a federated service account, make sure to update the rSTS Windows Service to run as that account rather than the default local system. Now that rSTS is installed, we can configure Active Roles to authenticate against it. Active Roles natively supports authentication via WS Federation. However, this was initially implemented to enable Federation via Azure and is therefore designed around the way Azure specifically handles WS-Fed. Your experience configuring WS-Fed to point to other providers may vary. The point here is that rSTS supports it and it can then Federate from itself to other providers using SAML 2. In short, we're just configuring Active Roles to utilize rSTS as its Federated authentication provider via WS-Fed and rSTS to utilize OneLogin as its authentication provider via SAML 2. So starting in the Active Roles Configuration Center, after selecting web interface and clicking the authentication option, you'll be taken to this authentication settings screen. In the Federated tab start by selecting the custom identity provider. In the Federated metadata URL you need to provide the URL where rSTS is hosting its WS-Fed metadata page. This will always be /rsts/wsfedmetadata on the URL of the server that rSTS is installed on. In my case in this example, Active Roles in rSTS are on app.ajlinder.local. For the realm field, use the realm provided by rSTS. By default this is urn:rsts/identity. For the reply URL, this should be the base URL of the web server that is hosting Active Roles. In my case, everything is all on app.ajlinder.local, but if your web interfaces on a different server, you'll want to point this to that URL instead. Finally, you will need to provide the claims needed to identify your users. In this case, I'm using email address, but have also configured this in the past using UPM. After clicking modify to apply the settings, if you followed step one to create a Federated service account you will need to modify a few settings on the IAS application pool on your Active Roles web server. On the AR web app pool, change the identity from local system to the Federated service account that you configured earlier and change the load user profile setting to true. This might have to be repeated every time you make a change to the Federation config. At this point, we now have Active Roles configured to authenticate against rSTS via WS-Fed. By default, rSTS will already have Active Directory as an authentication provider. So if you were to navigate to the Active Roles web interface, it should redirect you to an rSTS login page that prompts for Active Directory credentials. But we want to configure rSTS to use OneLogin instead. So first, we need to create a new SAML application in OneLogin. For this, navigate to applications and create a new application using the SAML custom connector advanced option. Give it a unique name, and in this case, be sure to turn off the setting to make it visible in the portal. Once it's been created you can assign access to it appropriately. Remember that if a user does not have access to this application in OneLogin, they will not be able to sign into any Active Roles web interfaces. Finally, from the More Actions menu, download the SAML metadata file for use later. Now we can finally, configure rSTS. Start by navigating to the rSTS admin configuration web page. This will be located on the rSTS server at /rsts/admin. And the first time you access this page, you will be prompted to create a password for the rSTS admin account. After signing in, you'll be taken to the configuration page for rSTS, where you can make various changes, such as updating the certificate and the ports that the web server is running on, if needed. But for now we'll navigate to the authentication provider section. And in a fresh install you should only see a default Active Directory provider. So start by clicking Add Authentication Provider to create our OneLogin SAML2 connection, give it a unique display name, and be sure to check the box for set as default provider. This setting bypasses the rSTS login screen, which normally might offer multiple authentication provider options and redirects automatically to OneLogin instead. Under Directory Type select External Federation. Under connection information, we'll fill out all the details for our OneLogin SAML2 application that we just created. For the realm, set the email suffix of the users who will be authenticating against this provider. For example, if your users are something @ajlinder.xyz like in this case, you'll just set ajlinder.xyz. For Federation metadata, copy the contents of the SAML2 metadata file you downloaded from OneLogin and paste it in. Everything else can be left at the defaults, which should match what's in the screenshot. At this point if you were to navigate to any Active Roles web interface it should automatically redirect you to OneLogin to authenticate. But there can be multiple Active Roles web pages, and there's currently no way to go straight to them from the OneLogin dashboard, and that's where quick links come in. In our configuration these basically just act as shortcuts to your various web interface pages that can be assigned to users in OneLogin appropriately to display on their dashboard. For each web interface create a new application in OneLogin using the Quick Link SP GET SAML 2.0 template. Give it a recognizable name and set the URL in the configuration section to the appropriate Active Roles web interface page. Then assign these to users who need to see them on their dashboard. To summarize what's just been configured, the Active Roles web interface has rSTS set as its Federation authentication provider using WS-Fed. rSTS has OneLogin set as its authentication provider using SAML. Users in OneLogin have Quick Links to show up on their dashboard that simply take them to the various Active Roles web pages. So when you navigate to an Active Roles web page, behind the scenes it will redirect to the rSTS login page, which will automatically redirect to OneLogin for the user to authenticate. If the user already has a valid session to OneLogin, it will then redirect straight into Active Roles. To force MFA specifically when users launch any of these Active Roles web pages, you can create a new application security policy assigned to the SAML2 application that we created earlier and configure that policy to require an MFA prompt. Now moving beyond SSO and MFA, let's talk about using Active Roles as a front end to drive user lifecycle management tasks by synchronizing users to OneLogin with the Active Directory connector. The OneLogin AD connector synchronizes data between AD and OneLogin in real time. In our use case, AD will be acting as the source of truth for OneLogin to drive ULM processes, provide role-based access controls, provisioned SaaS applications, and dynamically assign security policies. This is all controlled via the Active Roles web interface along with configuration that will enforce data quality to find, and automatically assign roles, and force approval processes, and delegate permissions to manage certain aspects of user's OneLogin account that are synchronized from Active Directory. So in the end, we can standardize and improve the quality of the data that arrives in OneLogin, control user objects based on provisioning policies and ensure that attributes used for OneLogin mappings line up correctly and build custom change approval workflows, user self service processes, and help desk functionality. To show what this looks like, I'll start in the Active Roles admin web interface. Navigate to my enterprise OU and create a new user. And as I fill out the web form, you'll be able to see my provisioning policy in effect. First, right here when it auto generates the user's log on name, then on the additional info page, where it requires attributes like employee ID, job title, et cetera, and restrict some of them to a specific list of options to select from. We'll create John Smith as a software developer in the engineering department, place him in New York City, and make him report to Mike Manager. We'll provide a password, which we'll need in a moment, and skip through the Azure options since they aren't needed in this example. Once it's completed, we can locate John Smith in the engineering OU, where he was automatically created based on his department. Next, in a separate browser, I can sign in to OneLogin as John Smith with the password that I just provided and set up his required security factor using the OneLogin Protect app. Once that's finished, John can now see all the applications that he's been automatically given access to in OneLogin. Now let's say some time later John moves to Atlanta and changes roles to a security engineer in the IT department. I can update his AD account via Active Roles. Now, as soon as that change has been processed, it immediately updates in OneLogin. So as soon as John refreshes his browser, he'll be able to see an entirely different set of applications that were automatically assigned to him. Finally, when John leaves the company, we can deprovision his Active Directory account in Active Roles, which will immediately kill his access in OneLogin. In order to set this up, you will need a OneLogin tenant integrated with Active Directory via the AD connector and a supported version of Active Roles running the web interface. In our example, we've configured OneLogin as a one-way sync from Active Directory as the source of truth. User objects are synced from the selected organizational units and attributes are mapped accordingly. For more information on how to install and configure the Active Directory connector, check out the other deep dive on OneLogin in an AD centric environment. Also in OneLogin we can utilize mappings to automatically assign permissions, security policies, roles, applications, et cetera based on attribute data in OneLogin. In our example, we've created a role for each of the job titles, departments, and locations that will be available to select from in Active Roles. Each of these roles contains a list of applications that are automatically assigned to users within those roles. And finally, each role has an appropriate mapping to automatically assign it to users based on their attributes. For example, our job security engineer mapping will assign the job security engineer role to any user whose title attribute is security engineer. And on the Active Roles side, we need to configure provisioning policies to require the attributes that we're using in our mappings and to restrict them to our predefined list of options. So when you create or modify a user that is synchronizing to OneLogin, their job title, department, location, et cetera will always be a valid option that has an appropriate role and mapping. Additionally be sure to customize the Active Roles web forms to ensure that those attributes are available wherever they might be needed. With the basic setup finished, you can take this even further. We'll finish this presentation up by discussing a few examples. Since Active Roles workflows can run PowerShell scripts, you could automate all sorts of other processes for a user's connected OneLogin account. As an example, I'll briefly walk through how you can automatically send a Magic Link invitation to a new user's email address so that they can set their initial password rather than you providing them with that first time password. After that, Eric will show you how you can enable a self service process to request access to applications within OneLogin from Active Roles. So as a quick high level overview here's one way you could set up a Magic Link invitation for new users. We start by creating a virtual attribute in Active Roles called personal email. Then we need a provisioning policy that requires this attribute for user objects in our target OUs and makes it available in the appropriate forms within the web UI. Then we can create a change workflow that runs whenever a new user is created in any of those target OUs. That workflow can then run a PowerShell script that uses the OneLogin REST API to make a POST request to the Send invite link endpoint. And in the request body you can include an email key that has a value matching that user's unique email in OneLogin and a personal email key that matches the personal email stored in that virtual attribute in Active Roles. Once this is done, whenever a new user is created in the target OU, they'll receive an email from OneLogin to their personal email account with a hyperlink that allows them to set their initial password in OneLogin and configure any required security factors for MFA. Finally, I will pass this over to Eric to show how you can enable self service access requests to SaaS applications in the Active Roles self service page. Hello, my name is Eric Hibar. I'm a Solutions Engineer at One Identity. Today I'm going to be talking to you about extending the capabilities of Active Roles to SaaS applications through OneLogin. So I'm going to walk you through this recorded demo. And today I'm logged in as the administrative user. And I'm just going to go ahead and create a new user for us to play around with during this demo. And we're going to create Darth AJ. Now, as you can see here, I'm putting him in to certain departments and offices, so on and so forth so that this user automatically has the rights to go in and modify the attribute that we're going to be controlling, we're using to control access to Salesforce. So as you can see I've automatically created the user account, or automated a lot of it, and when I log in as Darth AJ, we're going to open up a new incognito window here. We're going to log in to the Active Roles web self-service portal. And I'm going to go into my user profile editor. And there I've created a custom attribute or custom box that allows us to select whether or not we want access to Salesforce. So when I click on that link here, you can see I have access to modify, like my telephone number, my favorite color, all of that, but I'm going to click on the Application Request tab and select Salesforce. Now that's going to prompt me for change approval where I can then add in my reasoning, and it will send that to the appropriate approving parties. There we go. And it has been requested. So next we're going to be looking at the window from the perspective of the ultra admin account, which in this case is designated as the Approver. So I can see that the user is attempting to gain access to Salesforce. The old value, the new is true, and I can put in my reasoning for approving the process. Keep in mind, this is all within Active rules at this point. And that will go ahead and check the box. Now, flipping over to OneLogin, I'm going to log in as Darth AJ @OneIdentify.local. And in my process here, I have to go through to a face setup. So this may take just a second. But we can see as I log in as that user, and I'm going to go ahead and look at the properties here, the profile, so that you can see that the user is indeed brought in from my domain. So Darth AJ @OneIdentify.local. And now I can click on the Salesforce button there. There's other apps and things of that nature that I can click on, but it SSO's me into Salesforce as Darth AJ, whereas my account in Salesforce did not exist before. So that's how seamless all that can be. So why would someone want to do this? Active Roles already comes with a powerful sync service that has a generic SCIM connector. It's very simple, actually. By combining the power of Active Roles with OneLogin, you get much more granular control over provisioning, not just SSL. So to that point, OneLogin has more than 140 application connectors that are pre-built and ready to deploy for your user provisioning. Additionally, the sync between Active Directory and OneLogin is instant. There's no need to wait for a scheduled sync job to occur. This makes it possible to use Active Directory as the source of truth in your environment. We can also integrate other features of Active Roles into this process, such as the workflow approvals that you saw within the demo. So, for our example, these were the prereqs. Your mileage may vary depending on what application you attend on provisioning users to. However, you'll need a dev OneLogin tenant that you can get from the OneLogin website with Active Directory integrated. You'll need a dev SalesForce tenant for testing, and then of course, you can get a free version of Active Roles from our website. You can download a demo today and start kicking the tires right away. So, first, you'll need to add Salesforce as an application to OneLogin. You'll essentially go to the Administration page and create a new application. We have a built-in connector for Salesforce, of course, that will request a number of things that you see here on the screen, like the organization ID, the login URL, things of that nature. So enter in your information and other data for SSO into the appropriate Windows. Next, we'll need to do a bit of configuration for your application, in this case, Salesforce. We typically have a KB article for each application and how to integrate it on our website. So, in this case, we're going to enable SSO for Salesforce using Federated SAML authentication. And of course, that involves importing the metadata from OneLogin to Salesforce, and then of course, the certificate as well. So, lastly, we need to create user assignments to Salesforce. Now using OneLogin mappings we can assign that attribute that's changing to a role essentially that will then provide the user a Salesforce license or give them the ability to SSO into Salesforce. Using Active Roles we could then possibly create an approval workflow to request access to Salesforce in this case or approval workflow to modify a singular attribute, like the checkbox that we saw in the previous demo. Now, automatically any Active Directory change will synchronize to OneLogin and Salesforce provisioning will then take place afterwards, depending on what mappings you've set up. And that's more or less it. That's how you can utilize the power of Active Roles to control and govern how a user would get access to Salesforce, and not just utilize OneLogin for SSO. To finish off, here are a few relevant resources that may be worth checking out. If you weren't aware, One Identity has a GitHub with all sorts of useful utilities, product, enhancements, and integrations. If you're looking to utilize the OneLogin REST API to extend the capabilities of Active Roles, check out the repository for the OneLogin and Password Manager integration. This contains a PowerShell module that partially wraps the OneLogin REST API making it significantly easier to develop scripts. Finally, check out the video on multi-factor authentication to the Active Roles MMC and web UI to learn how OneLogin can also protect the Management Console and for more information on the rSTS component. [MUSIC PLAYING]