Welcome, everyone. My name is Gary Busby, and I'm a Solution Architect with One Identity. Now today's topic, we're going to be talking about how to make Active Roles your go-to Active Directory account lifecycle management solution for-- wait for it-- SaaS applications. That's right, SaaS applications. If you're currently using Active Roles, you're probably only integrating with Office 365 and Azure AD. However, today, I'm going to show you how to extend Active Roles to a wide array of SaaS applications.
First, we're going to talk about the manual way, the hard way, to do that. And then we're going to add Active Roles and make things a whole lot easier. And then we're going to add another component called Starling Connect, where we add a big Easy button for SaaS applications. So let's get started.
Before we dive into the solutions, is probably important that we do a quick overview of the fundamentals of the technology being leveraged to get to that big Easy button. A big part of that technology is called SCIM, yet another industry standard acronym to learn. It stands for System for Cross-domain Identity Management. And it's an open standard protocol that makes managing identities easier using a standard of service.
And this standard defines two key things-- one, the schema, and, two, protocol specification. The schema is defined by only resource types of users and groups. However, it is extendable. And the schema represents users and groups in a JSON format. JSON-- yes, another acronym-- stands for JavaScript Object Notation. And JSON is a text-based lightweight data interchange format that is easy for humans to read and understand but also easy for machines and applications to process.
Now, the second aspect of the standard is the protocol specification. And that defines a REST API to exchange that identity information. So under the cover, SCIM is a subset of the REST API.
Lastly, an important factor about SCIM that's really relevant to today's session is SCIM roles, and there's two of them-- one, a SCIM client. It's an IDentity Provider, an IDP. It contains the identities. And this is where Active Roles comes in. Starting with version 7.4 or greater, Active Roles is a SCIM client built in as part of the administration service.
And the second role is a SCIM server. And this is a server, Service Provider, an SP. And an application that kind of needs a subset of information, that SP needs the IDP's identities in order to work. And this is where Starling Connect comes in, because Starling Connect is a SCIM server. So when you put the two solutions together, you solidify the integration needed to give you that big Easy button for provisioning to SaaS applications.
With the fundamentals out of the way, let's walk through the journey of getting to the big Easy button by starting with provisioning the SaaS manually, the hard way, with no out-of-the-box solution. There's probably a half a dozen ways you can do this. And I use the term "manually" loosely because of that.
In this particular example, we'll use something as simple as PowerShell. If you use this method, you'll need to deal with encrypting credentials and storing it typically locally, which is usually user specific. And that makes it really difficult from a portability perspective. Then you would use REST-based cmdlets and most likely native Active Directory data. But if you need some additional data from other sources, that can make this script even more complicated.
And then the biggest aspect of working with SaaS applications is you need to gather a lot of information about it, such as required attributes, the available schema, the endpoints of the APIs, the URIs, the URLs, which can get very complicated, and a lot of data to manage from a manual perspective.
Some additional difficulties include lack of support. You can't pick up that phone and call anybody, can't phone a friend on this one asking for support with it. Also, the lack of features and capabilities within a script without making it extremely large and complicated, if it's even accomplishable at all. Overall, it's just a lot of work, a lot of resource-intensiveness.
But with Active Roles, we're going to take the hard way and make it a lot easier. So we're going to take a look at a demo of how to move that needle from the hard way to the easier way with Active Roles in the picture to make things a lot easier to get you to that big Easy button we're looking for. Let's watch this.
[VIDEO PLAYBACK]
- In this short demonstration, we'll show how to leverage Active Roles for provisioning to SaaS applications. We'll use ServiceNow for this particular example. For simplicity and time, I have the workflow and the PowerShell script ready for importing. But for detailed step-by-step instructions with screenshots, download the content of this UNITE session.
The first step we'll take is importing a PowerShell script. We'll open up the Active Roles console. We'll go to Configuration node, Script Modules. And I have my own container here. I'll right-click and import. I'll select the PowerShell script. You can name it whatever you'd like. It's obviously the PowerShell language, and script type is policy script.
Let's take a look at the PowerShell script itself. During the creation, you will define a function for onPostCreate. And within that function, you'll have the actual PowerShell script. As you'll see, it's not an overly complicated PowerShell script. It's relatively simple and straightforward. But to walk through it, we'll define variable for the ServiceNow administrator account. We'll define the password from the workflow itself. And you can define this workflow name anything that you'd like. But make sure you jot it down, because you're going to need it during the workflow creation process.
A couple lines to handle the encrypted password. The ServiceNow URL-- you'll need to change this to your ServiceNow instance. And then within the body, you need to know the ServiceNow attributes that you'd like to populate during the actual provisioning process. In this case, also, you could pull from native Active Directory attributes or Active Role virtual attributes, if you like. Then we simply convert it to JSON and headers, enabling TLS security. And then we simply use an Invoke-RestMethod to push it on its way to ServiceNow for provisioning.
Now that we've set up the PowerShell script module, we need to configure the policy workflow. Let's go within Configuration, Policies, Workflow. And here, I've got my own container. And I'm actually going to import already predefined workflow. This is the same workflow we have documented for you.
A couple areas you're going to need to configure-- first, how do you want to trigger the SaaS provisioning? I'm going to leave it at its default for this demo purposes. It's just any creation of any user. But you're definitely going to need to set a parameter for the actual ServiceNow password. Make sure you use the exact same name as you used in the script itself. They must match, or it won't work. Additionally, make sure the syntax is set to a SecureString, and the parameter must have a value.
And then lastly, you would want to set the actual admin password to your ServiceNow instance. And it's in encrypted format, and you can't see it. And then you want to drag over a script module and configure it to actually pull out that script that we just looked at earlier. So for example, you want to Browse, and go straight to that provisioning script. And then as far as the function to call, it's on the other one there, which is the onPostCreate. Once you're done, click OK to save changes. And you're ready to go.
So let's put this to the test. Let's actually provision to ServiceNow. Go within my Active Directory. I'll go an OU. And let's create a brand-new user. I already have a standard Active Roles provisioning policy that automatically fills all this information out. So all I need to do is a name, generate a random password.
And I do specify a mandated attribute for job title. I want that provisioned into ServiceNow. And I've already got an automatic exchange mailbox provision, and I'm done.
Now that the account is provisioned, let's validate in the Change History. And here, we see the workflow activities took place with our SaaS provisioning to ServiceNow. So let's go verify in ServiceNow that Matt was provisioned. And there is Matt Shiver's account within ServiceNow.
[END PLAYBACK]
After seeing that, wouldn't you say that Active Roles made things a whole lot easier than doing it manually? I think so too. So let's take a look at the benefits of using Active Roles versus manually. One of the benefits that we saw was the ability to leverage script modules. You have a centralized place to put PowerShell scripts, so you don't have to worry about doing this on someone's machine, and they walk out the door, get hit by a bus. You get that central management location.
Another benefit that we saw was leveraging virtual attributes. While you may get some data out of Active Directory, some data may not be there. So you can use Active Role's virtual attributes to store and retrieve that data. And finally, the biggest benefit we saw was the automation factor of a policy workflow. Being able to encrypt and store that credential information in a workflow parameter was a huge benefit.
And also, having that automation workflow start conditions to define the what, the where, and the when to provision makes it really flexible. As well as the ability to link a script to a workflow for execution is really nice to have. And lastly, the centralized audit trail and visibility within Active Roles to know the details of the SaaS provisioning of a user.
The next step is to move that needle all the way over to that big, easy button, is One Identity Starling Connect. For those in this session who don't know about Starling Connect, simply put, it's a cloud-based service that extends the capabilities of provisioning and deprovisioning to SaaS applications. And Active Roles has the ability to integrate directly with Starling Connect. One Identity does all the heavy lifting for you.
All these manual steps that we talked about earlier, like knowing all the APIs, the URIs, the URLs, understanding the schema exchange between the schema client and schema server, you really don't even have to know any of that information. We take care of all this integration for you. There's absolutely no coding or scripting required whatsoever. Starling connect is the Easy button. If you want to know more details about Starling Connect, take a look at the link on the slide.
Let's pause here and watch a quick video to introduce you to the Starling Connect website and the interface.
[VIDEO PLAYBACK]
- Let's take a brief tour of the One Identity cloud platform and one of its key offerings, Starling Connect, which will integrate with Active Roles to continue our path to the Easy button. To access the One Identity Starling cloud platform, simply go to cloud.oneidentity.com, and you'll get to this page. The Starling platform is where One Identity hosts a variety of cloud-based services that extend One Identity capabilities into the cloud.
You could sign up for Starling and register an organization and integrate with your products. Or you can try it free for 30 days, no credit card required. Today, though, we're going to focus on Starling Connect, the way to extend identity governance into the cloud.
As mentioned earlier, Active Roles has a built-in SCIM client. And Starling Connect is a SCIM server. Now, it offers a SCIM version 2 endpoint that helps define the schema for requesting users, groups, and the REST API for necessary CRUD operations, Create, Read, Update, and Delete.
And to see what those endpoints that are available to us, we have this Available Connectors link at the bottom, which leads us to all the available SaaS applications that Starling Connect can provision, deprovision, and update accounts to. There's over 50 available to date, and it's continuing to grow.
So let's take a look at the actual interface of Starling Connect and how you would configure the SaaS applications. Once you've logged into Starling platform and clicked on Starling Connect, you'll be taken to the Starling Connect homepage, where you'll see the Connector Catalog of all the available SaaS applications that you can configure. So for example, a simple configuration of any of these SaaS applications-- you just click Configure.
And you're given several options here. You can do version control. Maybe you're working with an older API version, and they've upgraded, but you haven't. So you can control that, as well as the connector type. A lot of vendors have a development instance and a production instance, so we do that as well. And you simply fill in the information about that particular SaaS application. You do a Test Connection. And you're actually-- that's it. You're configured. You're ready to go.
And once it is configured, it'll show up at the top as an Active Connector. So for example, in Salesforce, we'll take a look at that. When you open up a SaaS application that you've configured, you'll have some additional options depending if that application supports it.
So for instance, Salesforce supports the ability to configure the schema. We simply click at it, and we make a nice user-friendly way of toggling attributes that you want to manipulate. The ones with asterisks are required attributes. We already let you know that. Additionally, if that SaaS application supports it, you can build custom attributes to your needs.
Lastly, will make two final stops on this tour of Starling Connect. There's a Collaborators option where you can invite other administrators to assist with considering SaaS applications. You also have a Logs area where you can see your Active Connectors and validate that everything's communicating properly with Starling Connect. And at a broader sense, if you need to connect with a [? SIEM ?] solution or log management solution via syslog, we have the option in the Starling cloud platform itself that will work with any of the Starling offerings, where you can simply fill that information out and send that information forward.
[END PLAYBACK]
After seeing that tour, the Starling Connect website interface looks really easy, doesn't it? Very simple, very streamlined, and with a few clicks, you have your SaaS application configured for use in Starling Connect. Now let's keep that momentum going, and let's watch a demo with Active Roles and Starling Connect together, finally getting us to that big Easy button we've been talking about this whole session.
[VIDEO PLAYBACK]
- When Active Roles is combined with Starling Connect, you can make SaaS provisioning, deprovisioning, and updates very easy and extend Active Directory lifecycle management into the cloud. To get started, you'll first want to make sure your Active Role server is joined to the Starling cloud platform. Go into the One Identity Active Roles folder and open the Configuration Center.
You'll see in the Starling section, there's a Manage Settings. Now, I'm already joined to it, but if you weren't, you would have the option here to say, Join Starling. And you would just run through the registration process here or if you've already done it on the website. Either way, you can do it.
Once you've joined Active Roles to Starling, you see this "Account Joined" with a green light to let you know everything's good, as well as new tabs to the Starling offerings, including the Starling Connectors. You'll see what's already active and configured in Starling Connect. And there's nothing else you need to do here. So we'll close out.
And let's open the Active Roles MMC console and start configuring Active Roles to integrate with Starling Connect. Depending on what SaaS application you're integrating with, they may require some virtual attributes to be created. And we document this in our documentation with Active Roles in Starling Connect. In this case, I'm going to be using ServiceNow. And ServiceNow requires one virtual attribute to be created.
So we'll go into the Configuration node, Server Configuration, and Virtual Attributes. I've already created-- it's called [? edsvauserName. ?] This is going to actually store the username formatting that's required by ServiceNow and per your preferences.
The next step is to create a provisioning policy. So we'll go into the Provisioning, Administration. I have my own container. And I've already created the actual provisioning policy. Let's take a look at how simple it is. We'll double-click it, open it, and take a look at the policy. The policy is very straightforward and simple. The first thing I do is set a property generation and validation policy for that virtual attribute that simply says, what do I want the username to be, the formatting? Here, I've given it to be given name dot last name.
And the second aspect is the Starling Connect policy in and of itself. Here, you define the autoprovisioning properties for SaaS. You can define the object type, obviously, the user by default.
Conditions-- now, this is a great option you can have with the provisioning. So you can define how you want to provision it based off of certain criteria. So for example, if you only want to provision certain SaaS applications, say, if their title equals "manager" or some other attribute, you can do so here.
And lastly, you simply select what SaaS application do you want to provision. You can do more than one if you wanted to. And the last step, just like any provisioning policy, is scope it to where you need it. Here, I'll scope it to my North American OU. And now we're ready to provision not only our Active Directory account, but into our SaaS application. And in this case, it's going to be ServiceNow.
Now we're going to confirm that the SaaS provisioning into ServiceNow is going to work fine for a new user. But we're going to do so in the web interface for a really key reason. Within the web interface is this nice little feature that keeps track of SaaS provisioning, deprovisioning, or even modifications. If you look in the top right, there's a little bell. If you click on it, it actually shows you the status of everything that's going on within Starling Connect. So you can see history here of creations, deletions, and modifications. And you can even view all notifications, which we'll look at after we create a brand-new user.
All right, let's provision Wendy. Generate a random password. Go ahead and create our exchange mailbox. And here, we've already got checked the ServiceNow. Finish, and it says it was successful. And notice here in the top right, a red ball just showed up. And that means there was a new activity. And it shows us Wendy Hill was created. We can view all notifications and look at the history. So here, it just shows Wendy Hill was just created 13 seconds ago.
So now let's actually go validate this back in ServiceNow itself. And there's Wendy. And her records-- looks like it's successful in ServiceNow.
Now, Wendy's record here, as you see, doesn't have a ton of information. So what if you wanted to go back and add some information? Can it make modifications within Active Roles and go directly to ServiceNow? We'll check that out right now. Let's close out Wendy's record. And let's go back in Active Roles.
We'll go into the properties for account. And let's say we changed the department information. We forgot, hey, she works for HR. We'll save that, says, successfully. Let's wait for the red bell. And it went, and it says, successful. And let's confirm that in ServiceNow. And sure enough, there's the HR department has been populated.
Two last things we'll check with Wendy Hill. Let's close the record in ServiceNow. Let's go back to Active Roles. One, the SaaS provision also shows up in the Entitlement Profile. So you can validate there as well. You'll see this "Created in the Connectors." And within there, you see that Wendy Hill was provisioned to ServiceNow, the development instance. Pretty cool.
Now the last thing we'll check is actually, can you delete the object in Active Directory, and it also deletes in ServiceNow? Hit Delete, Yes. And we'll also check in the Starling Connect status. And sure enough, Wendy Hill-- DeleteObject was successful. And now let's confirm it in ServiceNow, refresh, and Wendy has gone.
[END PLAYBACK]
We just saw how easy it was to provision to SaaS applications with these two solutions. To sum it up, let's review the great benefits we get. One, Active Roles provides a built-in SCIM client. It's part of the administration service. There is nothing extra to install or configure.
Second, there's a built-in SaaS provisioning policy. As you saw in the demo, it's clicking through a simple wizard, checking the box for the SaaS application in Starling Connect, and you're off to the races.
Third, there's a built-in provisioning option in the web interface for a new or existing user. In the demo, we saw for a new user. But there is a link on an existing user that simply says, Provision SaaS, right there in the interface to make it easy for you. Fourth, there's a built-in Entitlement Profile specifier. Just simply look at the entitlements the user has, and SaaS applications will be there.
Also, you can leverage the deprovisioning policy. Just as we saw in the demo, where you can delete a user in Active Directory, and it's immediately deleted in the SaaS application, if you did the same thing in a deprovisioning policy, but, say, disable the account, move it to another OU, it would also be removed from the SaaS application.
And conversely, what if you accidentally deleted that user, or maybe the employee came back before the account was deleted, and you want to restore it? You can simply undo deprovisioning. And that SaaS application account will automatically be restored. That's pretty slick.
All the actions we've seen with Active Roles occur immediately in the SaaS application. Create it, update it, delete it-- there's no waiting. There's no synchronization at all.
And lastly, you get that centralized and enhanced auditing. Not only from seeing it on the Entitlement side, you can see it from the Change History side. And you get to see it on the Reporting and Notifications side of it in the web interface with that bell notification up there. And it lists everything that was going on in Starling Connect.
There's even an Export option there as well. Also, in the Starling platform itself, you can send off log data to any [? SIEM ?] or log management solution for an even broader auditing, reporting, and notification option.
In conclusion, Active Roles along with Starling Connect is a great combination to extend Active Directory account lifecycle management into the cloud with SaaS application fulfillment. I encourage you to go check it out for yourself. And my hope is that you got something out of the session today. Bye.
24:03
