Getting Started with Okta Lifecycle Management

Shelley: I would like to introduce Aaron and Maneesha from Okta, to share with you about getting started with Okta's life cycle management. 

Aaron Yee: Thank you Shelley, good morning everyone. My name is Aaron Yee, and I will be joined with my colleague Maneesha who's a sales engineer later. She'll be doing a demo, I'll be queuing it up. This session is meant to be a life cycle management 101 session. It's an introductory session, telling you high level what this product is all about. If you're in the wrong session, now is your time to jet. We have to provide a disclaimer, you'll probably see a lot of this going forward in basically all the presentations. It says there's a lot of forward looking stuff, maybe some, hopefully not financial statements, but claims about the product, what we're building, what's EA, what's in beta, what's in GA. Don't purchase the product based off of that, it might change.  Okay. To start out with, we want to set the stage by talking about why managing identity life cycles is tough in the first place. We've talked to a lot of customers, a lot of prospects like you. A lot of the common themes kept bubbling up. We'll talk about use cases first, and try to draw patterns from it. A lot of customers come to us with active directory already installed. Most of you guys use it. How many of you use it? Active directory on PRIM, right? But active directory, arguably it's one of the most successful identity matching products of all time. It's launched in 2000, this thing is 18 years old. It's like a legal adult. But it was built for a different time. It was built for on PRIM when there weren't a whole lot of cloud apps. Times have changed, but people still need to use active directory because they have on PRIM applications that need to authenticate. Even when you move to the cloud and start adopting more apps, you still want to use the credentials in AD. Maybe to authenticate against your IDP, maybe Okta, maybe something else. Because you don't want to make your users memorize another set of credentials. Additionally, active directory has information you want to port into the cloud apps as well. All the attributes they might need to actually provision an account. Sorry, the clicker's not working. The second use case that a lot of customers come to us with is, they try to integrate an HR system, which is a source of truth, and IT, which is another source of truth. HR is typically the best source of truth for timing, for onboarding and off boarding. Then IT handles the actual access to resources. In a lot of organizations, there's a tight coordination between these two different factions. We have different agendas. Because there isn't tight coordination, there isn't good automation between the two. What often happens is, you guys can probably attest to this is, you send emails back and forth, you get file extracts from an HR system, that IT then has to handle. There's a lot of manual processing behind the scenes. The third use case, and this is for a larger company, so you grow by acquisition. The third use case is, you buy some sort of company, and now you have to deal with their infrastructure. Do you let that acquired company run autonomously, or do you want to bring in their identities into your own larger company, so you can manage them centrally? Typically there have been three ways to deal with this headache. First is, you can simply migrate the child domain into your parent domain, and then apply your normal identity management processes on top of that for onboarding and off boarding. 

In the second column, and this is a big headache, in the second column, you might want to create a brand new green field directory, or Forest, and then migrate both the child and the parent into it. You can see as, if you do more and more acquisitions, this becomes a real headache, real fast. Finally in the third column, you might simply create trust between your child, and your parent domain. None of these are actually ideal. They're quite a big headache, there's some security implications, and it's a big burden on your IT team. The fourth use case, and this is similar to their previous one, distributed offices. You have maybe a California office, which has a couple AD domains, and you have a Florida one that runs ELDAP, entirely separate. Then you have maybe a Virginia one which also runs an active directory. How do you bring all these different domains with different pieces of information into the fold? If we look at the commonalities across the use cases, we see a few of them high level. One is connectivity. How do you connect to an existing on PRIM legacy directory like active directory? Maybe multiple ones, maybe different untrusted domains. Maybe even ELDAP. How do you bring that together? Then connect it out to SAS applications, so you can get that data from your on PRIM directories into the cloud. The second problem that we notice across those use cases was, multiple sources of truth.

Especially if you’re dealing with HR and IT, you have two different sources of truth which provide different values to different parts of the user profile. Finally the last one, I think this is the trickiest. Vary different processes for onboarding and off boarding. This isn't complex business processes, these are vary business processes. What I mean by that is, think about how one company onboards a user. They may look it, in the simplest case, a net new user who was created in an HR system. Another company might look at an attribute change that triggers an onboarding of a user, and another company yet might look at maybe a movement from on OU, to another OU in active directory as their trigger. These are all different business processes that could trigger on onboarding and off boarding. It's hard to build a one size fits all solution for that. In the past, you've had customized solutions using work foot engines to do it. The solutions to date that you might've used aren't ideal. If you're a smaller customer, if you're a startup, you might've gotten away with doing this manually. You might have your IT admin create accounts in your applications manually. I also lump in scripts into this category. But it's pain staking and it's prone to errors. Now if you're a larger company, if you're an enterprise, you can't do this manually. You might've tried to actually introduce some sort of automation using a legacy identity manager tool. How many of you guys have used SUN identity manager, ORACLE identity manager, ID identity manager. Tim Tam? Yep, a number of you. These were built for yesterday’s world, right? Where everything was largely on PRIM, you didn't have a whole lot of SaaS apps, and therefore you didn't need a lot of SAS connectors to do provisioning and so forth. These are also difficult to set up. The require professional services, consultants who have their expertise in setting up these solutions. If you quantify the pain, and our legal team made me put this in big red disclaimers, right? 

Where did I get these numbers from? These are from a model we created based off of customer surveys. If you quantify the pain looking at this manually, a lot of customers say, "Well it doesn't really cost me anything, I'm doing it manually. IT team has their hands full." How much time are you actually spending doing this? How many dollars are you spending doing a service? The way you evaluate this is, well you look at the wage of an IT admin, roughly 50 dollars an hour, and you see how much time they spend on a create, read, update or deactivate event for a given application. It's roughly 15 minutes. It's about 12 dollars and 50 cents per event. For organization, about 4,000, roughly 20 percent of them will require some sort of create, read, update, deactivate event in a year. Multiply 12 dollars and 50 cents by 800, and you get a figure of about 10,000 dollars if you’re doing this manually. Now if you're using a legacy identity management solution, are you saving money by introducing automation? Well it really depends. How big is your user base? It tends to be more of a fixed cost. The fixed cost is the consulting fees that you pay to get this up and running. You have to build out a workflow, which typically costs about 50,000 dollars. It lasts for about three years before your business process changes. Then you have to bring on the consultants again, to re-engineer that business process, upload it, and so forth. Then you have annual cost of connector maintenance. These solution are mainly geared to on PRIM legacy web apps. If your web app gets upgraded or if your container gets upgraded, you have to upgrade that connector. Our customers want an easier way, they want a cloud first way, they want to be able to share the system with IT, maybe HR and business app owners. But also have the same visibility, and they don't lose any control. This quote is from Call & D, one of our power users. As we think about building a new solution, we want to void what was done in the past. This is the rule I came from, right? Before I came to Oktane, I was working at Booz Allen. Basically coding out onboarding and off boarding workflows for the DOD. The work that I would've had to do was, I would first model out the onboarding process. I would do what you see on the left hand side, I would write this out on paper. Then I'd code it up in maybe Java, or in the case of sun ID express, which is their proprietary XLM language. Then I would troubleshoot it, and ultimately upload that whole business process into the legacy identity manager tool that you see on the right hand side. This is a painful process, it took about maybe three months to the tune of five digits. That was just for an onboarding flow, we'd have to write one for off boarding as well, and changes. We want to avoid that. Instead, you want to have a policy-based approach that's geared towards IT admins, and not developers. With the policy based approach, you'll see easy to use settings for onboarding. For step number one, we're sourcing identity, you want to have maybe rules that say, "What should the username be?" In every single case. In step two, how do you automate the assignment of resources once you've brought in that user? If you skip steps three and four, you go to five which is off boarding. Also have a policy based approach. When does my user get deactivated?

What does he lose access to immediately? What maybe does he lose access to in 30 days? A policy based approach, one that's geared toward IT admins is preferable. Here's an example of what that might look like with Oktane. Easy to use, but also granular and powerful. On the left hand side, you're looking at active directories, opt ins for doing create, read, update, deactivate events. It's a simple check box. But on the right hand side, you also see the granularity of options for deactivations and reactivations. For instance, when a user's deactivated in an active directory, how do you handle it in Oktane? Do you want to do nothing? Do you want to maybe deactivate the Oktane user which will then kick of deactivations for downstream applications, so maybe like BOX, G-Suite, Google Apps, Salesforce? Or do you want to suspend the Oktane user? You cut off user, you cut off the user's access, but you don't actually kill the account yet. I want to call to the stage Maneesha, who's one of our sales engineers, and she'll give you a full demo of onboarding changes and off boarding. That will bring a lot of this to light. The clicker's not working.

Maneesha: Okay. Thanks Aaron. With this demo, I plan to showcase everything that Aaron just talked about with our lifecycle management feature. I mainly want to show you how a user operation would propagate from a profile master, from Workday here. Two Oktane, two downstream application. With that I want to cover three main things. First I want to talk about onboarding a user. If you have a new home you would go on without using a profile master. I want to show how that user would propagate to Oktane automatically, and how Oktane would provision that user to a downstream application.  Then there's updating user attributes, when people are moving within your organization, the information changes. This can be something like an update to a title, a role, a department, or it can be like an update to a personal attribute, like a phone number, or an address change. I want to show how when you make those changes in the profile master, they get automatically updated and synchronized in Oktane, and then in your downstream apps. Lastly, off boarding users. When people are leaving the organization, you will go and deactivate them in your profile master. I want to show how the deactivation goes to Oktane to a downstream application. I can get started with the demo. For the profile master, I'm using Workday, in an extra as a master scenario. Profile master, it's basically your social truth. You can think of it as your very top level directory, that you're going to perform, use the crowd operations. Creating, reading, updating, deleting users. Then I have my Oktane admin counsel here, and I'm going to go to our universal directory, which is our cloud directory, and I want to show how this gets updated when I'm making changes in Workday. While I'm here, I wanted to pull up my Workday settings to show you how it's configured for provisioning. If I go to my provisioning settings here. 

When you're unable and apt to support provisioning, there's going to be an APA integration. You basically enter your applications, admin credentials in Oktane, and save them, and Oktane can use that to validate the API, and gain access to application APIs, and then the application can gain access to Oktane APIs. Provisioning can be configured by directionally, so you can have a two app where Oktanes pushing changes to the application. You can also have a two Oktane, where the application is making changes in Oktane. Since I'm using Work Day as my profile master, as my top-level directory, I have provisioning configured from Work Day to Oktane here.  Lastly we have the active directory. I pulled up AD users to show you how this gets updated when I'm making changes in Work Day. But you can think of this as any type of downstream application. It can be a cloud app, a on-prem app, it can be a custom homegrown app, it can also be a directory or a database. I'm going to start by onboarding someone, so I'm going to go here and hire an employee. I'm going to create a new hire, I'm just going to give this user some information. First name, last name. I'm going to give her an email address, because you need an email address in order to have an act to Oktane account. Okay, I'm going to make it their work email. But in a typical onboarding scenario, it would give this user all their attributes, like phone numbers, and addresses. I'm going to make the hire date today's date, because I want this to happen in real time. Let's say it's filling a vacancy. I'm going to select one of the pre-defined positions in my Work Day tenant. They're going to be a regular employee. I'm going to add this user to my sales department. Let's say they're the director of sales operations. They're full time, and I'm going to say they're based out of San Francisco. Okay, so the user has been onboarded in my profile master. If I go to Oktane, and if I got to the universal directory, I want to see if this user has automatically propagated. Provisioning ... 

Maneesha: I want to see if this user has automatically propagated. Provisioning happens in real time, it takes up to usually about 30 seconds or less, to create and activate this user in Okta account, and then push this user downstream applications. While that's happening, I wanted to talk a little bit about automated app assignments. It's great that we can automatically onboard users, but we also want to make sure that whatever applications that they're supposed to have access to as a part of our organization are assigned to them automatically. Because, if you have to manually go from app to app assigning it, then it kind of defeats the purpose. So, to do that, we use groups-based app assignments. If I go to my groups here in my Universal Directory, you can see the different types of groups that I have. Some groups I imported from applications, some are imported from directories like my AD security groups, and some groups I have created them in Okta. Two types of groups I want to go over. First, there's the everyone group. By default, everybody in your Okta tenant belongs to this group. If your organization has any birthright applications, apps that everybody has access to, you can assign them to this group. When users are onboarded, Okta's going to automatically assign those applications to that user. So, I have three apps here in my box, O365, ADP, everybody has access to them. And then there are groups that are only accessible to a particular set of users. My sales group, for an example. So, my sales department is assigned to this group, so whatever apps that are particular to my sales team, like my Salesforce, Salesfusion, et cetera, I have assigned them to this group. What I want Okta to do is when it's onboarding a user, I want Okta to automatically assign that user to whatever the groups that they're supposed to be in, so whatever applications that they're supposed to have access to are automatically assigned to them. To do that, I use group rules. So if I go to rules here … Okay, now I'm zoom in a little so you can see it. These rules automate the entire app assignment process. They're created using the expression language, I have two examples here. The first one, it says if the user title contains the word “sales,” assign that user to the sales group. The second one, similarly, if the title contains the word “marketing,” assign them to marketing group. You can get pretty granular with the expression language, here. You can configure these rules to whatever you want to, based on someone's title, someone's department, position, someone's location, full-time/part-time status. Many of our customers, they use these rules to replicate their existing organizational structure, and match the way they're assigning applications today.

All right, so let's go to people, and I'm going to zoom out. Search for my user, okay. So, she has propagated. As you can see, their account is active, and it says it's mastered by Workday, because that's where I initiated the user creation process. If I go to profile, you can see that the attributes that I added in Workday, they have propagated to Okta. Okta used them to build the Okta profile, and this includes their title, that they're the director of sales operations. If I go to groups, this user is in everyone group, and she's also in sales group. It's telling me that it ran the sales rule on this user's profile, detected the work “sales” on their title, so it automatically assigned them to sales group. If I go to applications, all these apps are automatically assigned to this user. The birthright apps, and their sales apps. If you have a lifecycle management enabled in these apps, then Okta would automatically create and activate an account for this user within the app that they can access via single sign on Next, if I go to my Active Directory, I'm going to run a search for this user. Okay. So, they have propagated to AD, and if I go to organization you can see that the job title has populated as well, that they're director of sales, so whatever group policies that you have for your sales department in AD, they apply to this user. This user also has an AD account created and activated that they can use to access any AD resources. All right. So, next I want to make a change to this user's profile. I'm going to go to their profile in Workday, and I'm going to make an update to their job title. So, let's say they decided to move from sales to marketing, they switched departments. I'm going to submit it. What I want Okta to do is update this user's Okta profile with the new title, and I also want Okta to change this user's access rights. I basically want Okta to remove any access rights they had as a part of my sales department, and assign them a new set of access rights that are particular to my marketing department.

Let me go back to my Okta directory. Okay, so I'm going to refresh it. Okay. I'm going to give it a little bit of time for it to synchronize. Okay. As you can see, the title has been updated in Okta. Now, they're a marketing manager. If I go to groups, you can see that their group memberships have been updated as well. They've been removed from the sales group, and been assigned to the marketing group. If I go to applications, they have a new set of applications here. All the sales apps, they've been automatically unassigned and this user has been assigned to a new set of marketing apps. So if you had lifecycle management enabled in those sales apps, then Okta would go and automatically deactivate that application account. Let's go to AD, and I'm going to refresh it. Okay. The AD title has been updated as well. You can see that they're a marketing manager in AD, so this updates AD group policies. Lastly, we want to perform user offboarding. So, I'm going to go here and terminate this employee. Let's look at their profile, and let's say I'm going to give it a reason. It's an involuntary termination, and I want this termination to happen immediately, so I'm going to set the termination date for today's date, and the last day of work and pay-through date are today's date as well. Okay. So, what I want Okta to do is deactivate this user's Okta account, and then push the deactivation to downstream applications. User deprovisioning, it happens in real-time as well, it usually takes Okta about 30 seconds or less to run the deactivation through Okta and downstream apps. While that's happening, I wanted to talk a little bit about different types of deprovisioning flows.

Many companies, they have two types of deprovisioning scenarios. First, there's involuntary deprovisioning, where someone's leaving the company due to something like poor job performance, and in that case you might want to revoke their access to applications immediately. Then, there's voluntary deprovisioning, where someone's leaving on more of like an amicable term, like let's say they're switching companies, or transitioning between jobs. In that case, you might want to revoke their access to applications gradually, maybe over like a two-weeks-notice period, or like a month period. Depending on how you're going to handle that, you can get pretty granular when you configure deprovisioning in Okta, especially within HR as a master use-case. I'm not going to go too deep into it, I just wanted to mention that, but we do have a session coming up later today on HR as a master that you can definitely check out if you're interested in learning more about it. So I'm going to go here and refresh it. Okay. As you can see, this user is in deactivated mode. As the admin, you can either go and delete the account, or you can reactivate it. If I go to applications, all the applications that were assigned to this user, they've been unassigned. If you had … First, this prevents unauthorized access, because they won't be able to access these applications outside of Okta. And second, if you had a lifecycle management enabled in these apps, then Okta would go and automatically deactivate the application account and release that license as well. One thing I want to iterate here is that we are only going to deactivate the application accounts, and their Okta account. We won't delete it. So, as the admin, you have the option to either go and permanently delete it, or reassign it to someone else, or you can transfer whatever the information they had in those application accounts to a different account.

So, let's go to AD, and I'm going to refresh it. As you can see, I'm not sure if you can see it, but there's a small downwards arrow next to their profile, showing that their AD account has been deactivated. If I go to their account options … Okay. So here, it says that the account is disabled. This user won't be able to access any AD resources, as well as any applications that use AD credentials. All right, so let me go back to my Okta admin console. It's great that we can automate the lifecycle of a user, but another important thing is gaining visibility into everything that I just did. This can be crucial from an admin perspective, or from a security perspective. To do that, we use reports and system log. If I go to reports, some reports that are relevant to lifecycle management are current assignments report, or deprovisioning details. These reports you see here, they are available out of the box, but you can also create your own custom report categories. If I ran the current assignments report just to show you how it's set up. This report is going to give me information on how users are assigned to a particular application. If I ran it for my Salesforce … So, this is giving me information on who is assigned to Salesforce, when they were assigned, and how they got assigned. So you can see information on how these users were assigned to this app, whether it was a groups-based assignment, or if it was an individual assignment, or these users manually requested access to this app. On a related note, we also have the system log. System log, here, it's actually one of my favorite tools, because it's pretty powerful in the sense that it generates a log for every single thing that's happening in your Okta tenant. If I scroll down, you can see that everything that I did over the last couple of minutes, there's a log generated, and you can get pretty granular with the way you search the system log using different queries. You can run a query saying something like show me deprovisioning details for O365. Or, show me updated attributes for my Google apps. Or, show me provisioning for my Box account.

These logs here, they also contain sub logs, and you can get additional information on who generated this, who triggered this event, the geographical location, even down to their ZIP code, and also the outcome of the event. So, system log here can be pretty helpful if your company went through a security incident, and if you have to go back and audit like a particular user, or a particular application, or for general auditing and compliancy purposes. This is quite a high-level overview of our lifecycle management feature. One thing I wanted to point out is that everything that I just showed you, it's available out-of-the-box. There are no custom configurations required. Typically, other customers take about … I mean, I do this with customers on POCs a lot, they take about an hour to set up a profile master, connect it to Okta with provisioning, and then set up a downstream application and enable it to support lifecycle management. Yeah, so with that being said, I'm going to hand it back to Aaron.

Aaron Yee: Thank you, Maneesha. So you saw the power, there, of what we call the crème de la crème, that's connecting HR with IT. Having Okta in the middle grabbing onboarding and offboarding events from HR and propagating them down to IT.

A lot of you might not actually want that sort of model, and you might want to actually just master off of another authoritative source, such as AD or LDAP. We certainly do that, as well. We'd use an import model to bring in data from AD into Okta, and then we push that out to various applications. What you saw was the crème de la crème. Next, I want to review the three problems that we talked about earlier, just to bring it all together. So, connectivity, right. How do we actually do all that in the demo with what we had out-of-box in the product? To connect to Active Directory, we used agents. Agents sit behind their firewall, they allow Okta, which is out in the cloud, to actually communicate to AD and get information to and from AD. Maneesha also showed actually talking to Workday, which is a cloud-based HR system. So, how do we do that? That was with our catalog of applications. Workday is one of them, so that was via an API approach. We have about 5,000 applications in our catalog, roughly 120-150 of them support some sort of provisioning, meaning we can either push to it or import from them. We also talked about how we can combine multiple sources of truth, right. We've got the notion of a profile master. With Okta, you can have multiple profile masters, so you could have multiple sources of truth. If you combine it with a feature called attribute level mastering, you can basically have different profile masters feed your Okta profile for particular attributes. So, you can have maybe HR feed in the first name and last name, and maybe your IT systems like AD feed in maybe the email and the phone number into your Okta profile. From there, it can flow out to your cloud-based applications. So, you saw how we offered the turnkey workflows for onboarding and offboarding. That was all done via a click of the mouse. Maneesha mentioned that it takes her roughly an hour to work with customers during a POC set up this full end-to-end demo. It's all based off of configuration and IT is able to do that, so you don't have to develop anything custom, it's all out-of-the-box. You saw how we were able to process access changes, right. So when a user was first onboarded, they were given access to sales apps. When they changed their title, they were removed from the sales apps and given access to marketing apps. That's done with a feature called group membership rules, we kind of glossed over it really-

Aaron Yee: That's done with a feature called Group Membership Rules. We kind of gloss over it really quickly, but if you're a current Lifecycle Management customer, and you want to learn more this, bring this up to your CSM or your sales folks. It's called Group Membership Rules. That's what does all the automation. High-level takeaways? Most people know us for doing Single Sign-on. We have a lot more products than just Single Sign-on. Lifecycle Management is one of them. We provide workflows for the masses. It's not going to serve every single purpose. We don't have a customizable workflow engine, which is what some of the legacy identity products from the past used to do. We've taken a different approach where we're catering to IT admins and not developers. With that, I'd like to point you to a few other sessions that are happening today. If this interested you, there's one in particular at the end of the day that's HR in Masters that's at 3:45 PM. These are all presented by our product managers. Orville will be handling the one at 3:45. George will be handling the one in the middle and that's about the broader vision for Lifecycle Management. He'll talk about extensibility options. He'll also talk about how we plan to handle more than just the employee life cycle. What you saw there was an example of how do you handle employee life cycles? In many organizations, there are contractors and partners whose life cycles aren't mastered by an HR or an AV system. They might be in different repository and therefore, accounts get traded for them and they just last indefinitely, so how do you handle those accounts? Then Ankar, he's doing the first session right after this. He's talking about the access for cluster approval Workflow. Are you guys familiar with that? No? Yes? What we showed was all automation handled by Okta. If your user needs to request access to resources and this happens all the time, we have a Workflow to do that as well. It brings in approvals into the fold. Then Ankar is also going to talk about a new feature that he's working on called 'triggers and actions.' This might provide a little more, or it will provide more capabilities for these workflows that you see here.  For instance, if a user's about to become inactive in 30 ... or if he's been inactive for 30 days, what kinds of actions do you want to take on that user or if his password's about expire, what kinds of actions do you want to take on that user? He's building a framework specifically for the those use cases, but he's also opening up to the other product managers in office so they can build on top of it. We have a few minutes left. I'd like to open up the floor for questions and answers. We have a mic floating around.

Speaker 1: Thank you for the demo. That was really helpful to see. The examples that you showed were with apps that were already configured in the marketplace. How do you set up provisioning, de-provisioning for your own custom apps for say, applications that you developed in-house?

Aaron Yee: Are these applications that are in the Cloud? Are these applications that are On-Prem?

Speaker 1: I guess On-Prem.

Aaron Yee: On-Prem We have an On-Premises provisioning agent, which would require some sort of customization between that connector we provided, it's an STK. It's your downstream application. What's going to happen is some work with the AD agent that we have, that sits On-Prem and gets calls from Okta to import users or maybe do an authentication. This On-Prem agent would also pull Okta, so it would look for, "Hey. Someone's been assigned to this On-Prem app. Here's his information in Okta."  It comes down in a SCIM message to that agent. The agent forwards it over to this STK that we have and you would code up the last mile from the STK to your application. If you have a Cloud-based application that you want provisioning to and we happen to not provide it in our catalog of applications, we are kind of opening up the ecosystem, sort of trying to promote a standard called SCIM for provisioning. Hopefully, if you're building a net new application out of the Cloud and you want provisioning to it, you should think about SCIM-enabling it.

Speaker 2: Thanks. Going back to the system logs, what is the default retention period for it and are you able to automate sending those logs over to a SIM?

Aaron Yee: I think the retention period is at 90 days? Yeah? Six months. Six months. Thank you. So the retention period is six months and we expose the data via API so you extract them and put it into your SIM.

Speaker 3: Another interesting question, when you deactivated the account, it stays in Okta unless you delete and has an activator, what happens if you hit activate in Okta, does it change things in Workday and in AD?

Aaron Yee: So the question is if you ... so I deactivated the user from Workday into Okta. If you then activate it in Okta, what happens?

Speaker 3: Mm-hmm (affirmative).

Aaron Yee: It won't reactivate it. It'll still look to the master source for that account. You can also delete that user completely from Okta.

Speaker 4: Hi. I was just curious with respect to the AD integration, right? Right now, we source everything from AD up to the Cloud. How easy would it be to reverse that if say we get a Cloud-based HR solution that we want to master the data? Would it be as easy as just turning it on? How complex would that conversion be?

Aaron Yee: Right. Setting up the tech part is easy. It's determining the process, right? Are there going to be collisions when you make that change? You have to think about that part. The technology's easy to do. You'd run an import and have Okta establish the matches, but the actual collisions and handling any errors, you have to think about that, and our PS team does a lot of that. We do have customers who started out mastering from AD and they wanted to switch to an HR as a master approach and they did that pretty easily.

Speaker 5: Thanks. Hi. I'm thinking about fully automating the onboarding Lifecycle process and a big piece of that is a ticket that allows for things like laptop issuance or other hardware. What would fit into this process for the service desk? I know that you've kind of removed all of the complexity out of it in terms of coding, but what could we expect in terms of possibilities for that?

Aaron Yee: Yep. Great question. So, the use case, we showed automation to applications that expose APIs, but there are a lot of other applications, maybe, that require some sort of ... or resources that require some sort of manual handling. In this case, it might be a physical resource, or it might also be an application that requires manual provisioning because it doesn't expose APIs. Ideally, what we would do is create a ticket in maybe Zendesk or ServiceNow and then track the full flow of that, so once the ticket is closed, meaning the laptop was provisioned or the manual app was provisioned. A message would come back to Okta and we would close that loop and assign access, if it's an app, and just maybe keep track of the task if it's a hard asset. I know our product managers have been thinking about that, with extensibility, so we're going to have potential webhooks that can do some of that sort of work. This is called the manual provisioning flow, by the way. In the past we talked about maybe sending an email over to ServiceNow or Zendesk because that seemed to be the least common denominator. All those different ticketing systems seem to be able to construct a ticket off an email. We've backed away from that as we looked at a more scalable approach using webhooks. That hasn't been created yet. Our PMs are just thinking about it. Any other questions? Right here in the middle.

Speaker 6: Thank you. Great presentation. Question about terminations. Maneesha was showing us the RTS termination, but most of our terminations come in before last day worked, so they're subject to the import. That means that they don't actually get terminated until the first refresh of the next day. Is there anything we can do to accelerate that and use the actual time that they're supposed to be terminated from Workday?

Aaron Yee: Good question. Are you using involuntary terminations for those folks that you want to kill access to? I think for voluntary terminations it actually handles, I think at the end of the day, but doesn't handle it immediately. Next day? So, next day if it's a voluntary termination, involuntary happens now. Also, talk to our product manager, Orville would be the right guy to see. He's doing the 3:45 session. He'll be able to tell if it's on the roadmap to shrink the actual voluntary termination. In the middle.

Speaker 7: Regarding terminations, end of day depends on the time zone, where in the world you are. How do you set that up in Workday?

Aaron Yee: Right. That I don't know. I have to defer to Orville at the 3:45 session, or if you want to drop me an email, I can look that up for you.

Speaker 8: Hi. My question is about the group rules with an Okta. You mentioned that you can automate it to add users when they onboard to certain groups. Can you do that via active directory groups also if they're a part of-

Aaron Yee: Absolutely.

Speaker 8: ... office groups or whatever?

Aaron Yee: Yep. The group membership rules that we showed, with Maneesha did was a rule that was run off a particular attribute, value. You saw it here that we looked at a user’s title of sales and marketing. You can also incorporate that with group memberships, so any group that Okta knows about, maybe an Okta group or an active directory group. You can also put that into the expression language that you see here to really enrichen that rule. In the front. Oh, sorry. We'll get you next.

Speaker 8: Hi. I have another question about group membership here. In the scenario where you're using Workday as the master and let's say you're trying to provision access to Salesforce. To fully realize the dream, you don't just want to give access to that app, but you want to get the specific permissions-

Aaron Yee: Entitlements-

Speaker 8: Right. Yeah.

Aaron Yee: Yep.

Speaker 8: Is there a best practice for the data structure on the Workday side to use to power the granular entitlements?

Aaron Yee: It really depends on how you want to do it. You can either do it on the Workday side to put users into particular groups or you can have group membership rules populate users into specific groups within Okta based off of attributes or combinations of attributes and group memberships. Once the group is in Okta, whether it's a Workday group or an Okta group using Group Membership Rules, you can then assign it to specific entitlements within Salesforce. I think it's profile and role was the other one that you can group assign. Does that answer your question? I don't know if there's best practices. It's really how you want it done. Right here in the front. In the purple shirt.

Speaker 9: All right.

Speaker 10: Hey. My question is if you already have a ... We have Oracle IT manager provisioning to the legacy systems, so obviously it's not as easy to unplug it. What are your recommendations if you want to Workday to Okta connectivity and then still have that in the mix temporarily until we cannot find a path for those apps? What are the recommendation on that and-

Aaron Yee: What kinds of apps are these? Do they expose any sort of API? Probably not, right?

Speaker 10: No. No APIs. They were legacy systems including SAP. We have workflow there, so it could be anything, not out of the box connectors from OIN at that point.

Aaron Yee: Got it. Are you hoping to replace OIN slowly and maybe have Okta provision to his On-Prem apps?

Speaker 10: Yeah. We will have a whole bunch of apps that we are going to provision probably through Okta for the immediate needs, but then we also want to look at what do we do with legacy systems?

Aaron Yee: Right.

Speaker 10: How can we get those over?

Aaron Yee: The option here that we would recommend is On-Premises provisioning. You would have to code up that last mile from the STK to the actual app itself, since we don't know what that last mile looks like for those On-Prem maps. If they don't expose the APIs, then you'll probably have to write directly to a database with that STK connector.

Speaker 10: Thank you. One more question.

Aaron Yee: It'll be tough.

Speaker 10: Right. One more question, real quick. We have service now for ticketing requests, like the workflow requests that you talked about. Is there any type of ready integrations with in-service, where workflow gets taken care of there with approval process, but then Okta's just doing the fulfillment and then replying back to service now that it's complete?

Aaron Yee: Yep. We do have an integration for that. I don't know the details of it, but I can put you in touch with one of our sales engineer, Tark, who actually worked on that integration. Find me afterward, and I can exchange emails with him. Question?

Speaker 9: We're out of time.

Aaron Yee: We're out of time?

Speaker 9: Yeah.

Aaron Yee: Do we have time for one more question?

Speaker 9: One more.

Aaron Yee: Last one.

Speaker 11: Hi. Thanks. Today, we use Workday, but in terms of source of truths, from an HR system perspective, what type of limitations or requirements are considered when using an HR system as a source of truth?

Aaron Yee: Workday is actually one of our most robust HR systems, so we have a pretty good integration there. With the other HR, four or five integrations, they support fewer features that you, for instance, Namely, is a new master source for HR and they only support a few attributes. They're going to expand that. For Workday, I'm not too sure there too many limitations. Which ones are you thinking about in particular?

Speaker 11: ADP.

Aaron Yee: Oh, so mastering from ADP like Workday? We don't actually have a connector to ADP, so the approach there would be to use our APIs, so you'd run the script, find changes in ADP and then call our APIs. That's one way of doing it. Is it On-Prem or is it Cloud?

Speaker 11: It's Cloud. 

Aaron Yee: Oh, it's Cloud?

Speaker 11: Yeah.

Aaron Yee: Okay.

Speaker 11: I was just curious if there were any other technical specs or limitations.

Aaron Yee: It would just be whether we actually have an integration with that API for that particular HR solution.

Speaker 11: I see. Thanks.

Aaron Yee: Yep. We're out of time. I'll be outside if you folks want to ask any more questions, but thank you. I really appreciate it.