Build a Single Source of Truth for Your Digital Identities

Speaker 1:  Good morning. Welcome to the life cycle management track. We're gonna be talking about building a single source of truth for your digital identities, but before we jump in a few housekeeping notes. This session is being recorded, so we ask that you please turn off your cell phones throughout the session and also appreciate you staying in your seats once the session starts.

With that I'd like to introduce our first presenter, Aaron Yee. Aaron is the senior technical marketing manager at Okta, and he'll be joined later by Isaac Brumer, project manager for information services from Planned Parenthood Federation of America.

Aaron Yee:  Great, thank you. All right, good morning everyone, and thank you for joining this presentation. Again, my name is Aaron Yee, and I work as part of the lifecycle management team over at Okta. You might have known this product as provisioning. We renamed it last year at Oktane because lifecycle management captures more of what we actually do. This presentation, in particular, will focus on Universal Directory, one of the key underpinnings of lifecycle management. We'll talk about how Universal Directory can help you create that single source of truth as you migrate toward The Cloud and as you push more and more identities to Cloud based apps. Forward-looking statement.

I'll be joined at the second half of the presentation by Isaac Brumer from Planned Parenthood. He's been an Okta customer for quite some time, and he'll actually take you through some live demos of some of the things I'll talk about. Quick agenda. We'll cover the problem statement. We'll talk about some of the problems that you might face as you're trying to create this single source of truth. Why do you even need to create it when you're going to an identity management system? Then we'll break it down, and we'll talk about how Okta can actually help you with each of these problems, and I'll show you some different features. And then I'll turn it over to Isaac who'll reinforce some of these key features.

So the problem statement, before implementing any sort of identity management system, whether it's Okta or one of our competitors, you need to have a single source of truth because without it you can't administer identities from a centralized location. If you have Active Directory, if you have LDAP, if you have an HR system, and they all contain different identities, there's no way you're gonna be able to administer IDM, assign applications, revoke access, and so forth if it's not centralized. 

There's a couple problems when you're trying to create this centralized source of truth. One is you've got multiple sources of truth. Some of our smaller customers use maybe one active directory as their source of truth. The larger ones have multiple ADs maybe spread across geographically over the world, maybe untrusted as well. They might also have LDAP, right. Some teams might use LDAP. Their apps need LDAP. They're not using Active Directory, so you have a different set of identities in LDAP as well. And you have an HR department that's separate from your IT department. The HR system also has probably the most complete set of attributes for a user, and it's probably the most updated set of attributes for that user.

After you consider your multiple sources of truth, and you're able to wrangle them together you now have to consider the different schemas, and the schema is just a collection of attributes for that particular data source. So AD would have a different schema than LDAP, which has a different schema from your HR system. Ultimately, you want to take that data, bring it together, clean it up, do some transformations, and make it in the right format because ultimately you need to get that data out to the right hand side, your Cloud apps. But even after you've done that work you might not have the data in the right format that your applications need. So you have to able to derive the data that your apps need. To date, the tools that do this haven't been particularly well suited for the job. If you're a small shop, and you're trying to save money you might be using customized scripts that bring in all the data. They have custom connectors. You might do some transformations within those scripts. You might reach out. You might have credentials stored in those scripts, so it's not easily maintainable. 

What if your on prem system, your source of truth, gets upgraded. The connector might break, and you have to bring in someone with the right skillset to rescript it. Now, if you're a larger customer you probably want to scale away from these scripts, and you might think, "I'm gonna use an identity governance and administration, IGA, software." These are your typical identity manager packages from Sun when they're around, Oracle, IBM, CA SalePoint. And they have provisioning workflows. They also have connectors to on prem apps. But these identity manager components, they're built for a Legacy paradigm.

As Ben Horowitz alluded to this morning, they were built for 10, 15 years ago when you only had 10, maybe, applications on prem. You had a few ADs and LDAPs, and that was sufficient. But they don't have a wide array of connectors, so if you want to mingle AD with LDAP, and I have an array of HR applications as well as all your target systems that you want to push that data to, how do you handle that? In the past this was done through custom coding. These identity manager products would provide you a template. You can code up the connector to the systems. You can even put in your own provisioning logic to do provisioning, updates, and forth. But it's not scalable. 

As we think about how to build the new next generation system we've gotta avoid what was done in the past. I came from what was done in the past. I actually wrote provisioning software for Sun identity manager and Oracle identity manager as a contractor. And this is what I would have had to do. This would represent a workflow for culling all that data from your authoritative sources, pulling it together, transforming it, and ultimately pushing it out to, like, one target system. You'd have had to do this for every single target system. You would have to mull this out with a process, code it up in some proprietary language. If you were lucky, it was Java. And then you would have to upload it into your identity manager solution that you bought. Again, this is Legacy. This was built for 10, 15 years ago. It's not easily maintainable. It doesn't have connectors to the Cloud based applications, and it's very limited. 

Let's talk about how Okta does it differently. We're gonna go through this step by step. Remember the ultimate goal is to have that single source of truth. The first problem is you need to wrangle those different sources of truth. Again, you might have multiple ADs. You might have an LDAP or two. You might have an HR system, and hopefully just one. But if you're doing mergers and acquisitions you might have more. Let's break this down. You might have a San Francisco office, and you might have a Las Vegas office in the simplest case. On top of the San Francisco office you have one active directory and one LDAP, fairly simple. In the Las Vegas office you might have several active directories, and they might be untrusted. They might not be connected together. And let's pull in your Cloud based HR systems, and you might also have AD running in AWS, so you might say, "Hey, AD is in the Cloud." How do you bring in all that data if it's Cloud based and on prem.

Our approach for the on prem systems that you see on the left hand side, we simply drop an agent behind the firewall, one agent for AD, one agent for LDAP, and if you have multiple untrusted AD domains, you simple drop in a different agent for each of those. If they're trusted, and they're connected then you just need to install one, maybe two for redundancy. But the key here is you don't need to poke firewall holes because Okta's not actually reaching in down into the firewall to your AD system or your LDAP system. The agent is actually reaching outbound to Okta, so it's fetching instructions to create a user, update a user, deactivate a user and so forth. So it's very simple for your on prem systems.

Now, for your Cloud based systems, this is where Okta provides real horsepower. We have our Okta that was formerly known as the Okta Application Network. It's now the Okta Integrations Network. It has 5,000 prebuilt connectors to the receps. About a hundred of those support provisioning capabilities meaning we can import from the sources. We can also push out to those sources.

Step two, now that you've actually wrangled all the different sources, the agent basted approach for your on prem AD and LDAP, and you brought in your Cloud based sources, how you you handle the different schemas? How do you handle the different sets of attributes that each of these data sources provides? Here's an example. On the right hand side you have Active Directory, which has its own schema. In this case it has four attributes. And your LDAP has it's own schema with about six attributes. Our approach is pretty simple. How many of you are existing Okta customers? Okay, about half the crowd. So you know about Universal Directory.

Universal Directory is our Cloud based directory, and it holds your identities, groups, and so forth. Universal Directory provides profiles, and profiles are a representation of the schema in your authoritative sources or even in your targets. In this case you would create a profile for Active Directory, and you would create a corresponding LDAP profile for LDAP directory. What's shown on the screen is a copy verbatim of all the attributes in AD and a copy of all the attributes in LDAP. With Universal Directory we also give you the ability to scale back what you want pulled into Okta. So, for instance, if you have PII Data, maybe you have a Social Security number sitting around in AD, you can choose submit that from the Okta user profile because you might not need to push that down to your downstream applications. With Universal Directory you get these profiles, and you also get mappings between profiles, and that's how you actually push attributes from one place to the other. I'll show you a screen shot of that.

The next step is, "Okay, I've collected all my different sources, on prem and Cloud based. I've handled all the different schemas with profiles and Universal Directory." The next step is to actually clean that data up before it gets stored into Okta's Universal Directory. And you do that with mappings and transformations. What you see on the left-hand side is a screenshot of Active Directory, and you have a user by the name of Tony Soprano. Now, you notice that the first names, it's a mix of caps and lower case. The last name is all capitalized. The display name's kind of munged. It's a mix of caps and lower case. The office is abbreviated. And the telephone number looks like it's all munged together. Ultimately you want clean data. You want the stuff on the right hand side. You want the name to be maybe in all caps. You want the department not to be abbreviated but fully expanded. And you might want to format the telephone number for dashes and an X.

Our approach is with Universal Directory in these mappings you control how that data flows from one place to the next. What you're looking at is a screen shot of the mappings. If you look at the very top in blue, that signals the direction of the mappings. In this case the blue highlights Active Directory coming into Okta, so AD feeding the Okta profile. But we also have the opposite flow. We have Okta writing to AD in the other table as well. What you're looking at here is the mappings. I don't actually show the corresponding attributes on the right hand. I'm focusing on the source attributes. You see here first name, last name, and middle name. You don't see any transformations in here. These are being copied verbatim from the source like Active Directory to Okta. 

Now, if you look down here, something looks a little complex, but it's actually not that complex. We've introduced expression language. This has been in UD for a while. But the expression language allows you to transform these values between one source of data and another. In this case we're looking at Active Directory, and we're saying, "Hey, honorific prefix. That's a fancy term for Mr. or Mrs. If that is not blank, if it's not null, then go ahead and use that and set that in Okta. Otherwise maybe set it as NA, not applicable, because I want to have some sort of default value in Okta." This is just a sampling of the expression language that we have. If you actually go to our website, we list the full amount of capabilities that we have for expression and language. 

So a quick recap of what we've done. We pulled together our multiple sources of truth, AD, maybe untrusted domains, maybe multiple ones. We linked it together with LDAP servers as well as HR. We pulled it together all on Okta using a combination of agents as well as Cloud connectors. Then we handled our schemas with Universal Directory's profiles. Those profiles were a representation of the schema from your sources. Then we applied some transformations. We also copied some stuff verbatim. The next step is ultimately you want to give that data to the apps on the right hand side. After doing those three steps, bringing together the sources, handling the schemas, and cleaning them, Okta still might not have the right data that your applications need. Here's an example. We're looking at two attributes, location and manager in Okta, as well as in two target application.

In Okta the location might be an abbreviation of a state. But Salesforce might need it in a code, zero, one, two, three, or four. OrgWiki might need it in some sort of directional text, north, south, east, or west. For the manager, Okta might have it as an e-mail address formate. Salesforce might actually need that as a first name, last name format whereas OrgWiki can copy it over verbatim. Instead of me telling you about this I'm gonna bring to the stage Isaac Bumer from Planned Parenthood who is a power user of Okta and actually go through some of these demos with Okta's product. So, please come to the stage, Isaac.

Isaac Brumer:  Thank you, Aaron, and good morning. So good morning. I'm with Planned Parenthood. We are the largest single provider of reproductive health services in the USA. We're a national office and 50 plus local affiliates, 600 plus health centers, and we've been using Okta for identity and access management since 2015. What I'd like to do is to share some of my insights of how we solved problems that were given to us, and how Okta Universal Directory and Expression Language helped with that.

Just to go back a few years, we were evaluating identity management systems, and we were going to implement identity management for our family, and to use that also to create and maintain application user profiles. An application owner said to use, "Our application needs every user to have a manager and every user to have a four-digit location code, and we need to indicate whether a user needs manager privileges. Can you do that?" We were new to this, and we were, "Well, we'll need to look into that." We had some background on this. Up until now we had tried to maintain these values for this application. We did it through Active Directory, not very consistently using extension attributes, using flags that were not necessarily made for that purpose.

So we worked with Okta, and we worked with our professional services team. We worked with our own internal team as well. We learned a lot from Okta Professional Services, from the knowledge base, from the courses. What we've learned at this point is if you can create formal as an Excel you can create Okta Expressions. What I'm gonna do is actually gonna demonstrate some of these in Okta. And we're gonna do case by case. Make sure every user has a manager. In the past what we would do is the manager's e-mail was maintained in a separate flag in Active Directory, not very well.

But what we have found is Okta has a great feature in their Expression Language called get manager user Active Directory, which will retrieve an attribute from the user's manager's Active Directory. It could be e-mail. It could be other attributes. You already have this because you're maintaining a user's manager in their Active Directory profile, so we have this. We can do it just straight up. We can just take the attribute as it is, but we want to attach some logic to this. We found that there are some users who are not gonna have managers. What we can do is we can use the conditional logic, if, then, else, from the Expression Language. The question mark and colon say, "Okay, us the get manager user Active Directory. Actually test it. If it's not equal to null, then let's take that value, get user manager, get manager user active e-mail." Otherwise, if it is null use [email protected]. That's our HR director. What I've done is just ...

Let's take a look at our profile editor. This is ... There we go. There is a core user profile in Okta, and this maintains every user attributes for your user. These come with 31 or so base attributes, and you can add, you can extend this with your own custom attributes. And then every directory and every application has its own profile. You can map attributes from the directory into Okta or from Okta into the directory and from applications into Okta and Okta to applications. What we're doing here is we're mapping from the Active Directory, and there is a list of all these fields of all these Okta attributes on the right and the sources or expressions on the left of how we get these attributes. You can actually, there's a drop down list. Even nicer than that is if you go all the way to bottom of the drop down list, you even have a link to Okta's great reference on all the various expressions that you can leverage.

What we have done is we have already inserted that expression, the if, then, else expression from manager ID, and you can even test this. We've tested this on a user, Rene Smith, and actually the results of these expressions come up, so you can actually test this before you save. You exit. You can save your mappings, and it will actually apply it. And also just a note here, once you have this in place this is working for you 24/7. Whenever information is added, whenever information changes that thing is now feeding your user profile or feeding your directories and applications. If we go to our users, taking a look at somebody like this user, Nikki Tang, she's got a manager set in Active Directory. Actually she doesn't. And sure enough she's got a default manager ID, Adam Human. Problem one, solved. 

Then, assigning locations for two different apps. Remember, we said, "Salesforce needs location as a four-digit code. OrgWiki needs location as a string." In the past we used to maintain these different values for different applications. Not very efficient. Let's try to leverage what we already have. We most consistently maintain states for a user profile, and we can interpolate state to be the location string for OrgWiki or the location code for Salesforce. We can do this with additional expressions, and this is where we're getting a little more, we're having some more fun here. We're using StringSwitch. For those of you who code you're probably familiar with switch statements. What we're doing is we're checking a field. We're checking the user's state just a bit for consistency. We're also converting it to upper case. And if it's Nevada then the code is 0000. If it's Illinois, it's 0001, Minnesota 001, et cetera. And if there's no value, TBD as default. We've already set this up.

I'm gonna move on, just take a look at this. Let's take a look at Salesforce. We've got a user. We already did this. There's a user. She's in Illinois, Chicago, Illinois. Our mapping ... thank you. We've got a user profile. She works out of Chicago, Illinois, so we tested Illinois, and sure enough she's got a location code of 001 in Salesforce. When we did this we mapped this in Universal Directory in the Salesforce profile.

Trying a different variation on this, OrgWiki. OrgWiki wants a string, so we're gonna do this a little differently. And OrgWiki actually wants a person's title, comma, a string representing location. Regional manager, north regional office. What we're doing is we're combining. We're saying user's title. We're also checking that value. If it's null we're saying we've got an if, then, else statement. If the user's title is not equal to null use the user's title. Otherwise TBD, then plus common, so the plus is a concatenation there. Plus another string switch. This is again we're checking the state, and if it's Nevada, corporate headquarters, Illinois, North Regional Office, et cetera. If there isn't any, then there's the default of TBD.

Going on to OrgWiki, let's see the results of that. We're just cutting straight to the chase here. This is how this shows up. You've got Sinema Guadeloupe, regional manager at North Regional office. Tom River who has no manager and has no state, TBD, TBD. Nice, reasonably clean data. Problem number two, location, solved.

Problem number three, automatically identify who's a manager. Okay. In the past we had a separate flat for that. Is the user a manager or not, not maintained very well. Great thing is you can get this from Active Directory. Inactive directory if someone is a manager they're direct reports appear as an array in Active Directory. We can map that to Okta, and we don't really care who the direct reports are. We just care that there is a value in that string of direct reports, so we just check the length on it. We use the function string length appuser.directReports. If great than zero, then that user is a manager, true, otherwise false. Let's see this in action. Here we've got a user. We've got Debra Miller. She's got a direct report. Rose Granite, sure enough, is manager has been set to true by the expression that's already been built.

Okay, so we want to assign application to people who have direct reports, who are managers. We've created a workday app. It's not assigned to anybody right now, but we've assigned it to group Oktane Managers who has nobody in it right now. What we're gonna do is we're gonna use a great feature of Okta called group assignment rules, which also uses expressions to assign people to members of groups based on values of attributes or other group memberships. I'm gonna create a rule, and I'm gonna call this managers. For string attributes and numeric attributes you can actually use this sort of builder feature to create the expression. Since is manager is a boolean field, we're just gonna use an expression editor. We put in the expression, user.ismanager=true. Then assign to group. Just picked that up, Oktane managers. We can actually test this.

Isaac Brumer:  Oh, thank you. Thank you team. User doesn't match the rule. Let's try a user who is. User matches rule. Add rule. Activate the rule. Now let's check the values of that group. Oktane Managers now has all the people who are managers. The group assigner rules has made life a lot easier now in allowing you to not have to manually move people in and out of groups.

Fast forward three years, we've learned a lot here. Some of this has been the evolution of Okta as a product. Some of this has been Okta training. Some of this has been our team. Some of this has been professional services, but all in all I like this product. I like the Universal Directory. I'm always looking for new problems to solve with this. I just really enjoy using it. Going back to that question from the application owner from 2014 is we need every user account to have a manager and a four digit location code and a flag that tells they need manager privileges. Can you do that? The answer is yes we can. Thank you. Back to you, Aaron.

Aaron Yee:  Stay on stage for questions and answers.

Isaac Brumer:  Okay. I'll stay on for questions and answers.

Aaron Yee:  Great. Thank you for those demos. One thing I would like to reiterate, in the last example you saw a slightly different use of Expression Language. In the first two examples we used Expression Language within the actual mappings to get data cleaned in the right way you wanted. In the first example that Isaac showed, the first one was to actually provide some soft of default value for a manager. Provide the manager's value. If it wasn't there, put in some default value, the HR director. The second example was a demonstration of the scenario I presented earlier, which was, "Hey, if Okta doesn't have the actual data that you need, and the apps need it in a slightly different format how do you derive it?" He did it using a switch statement.

The third scenario was slightly different. In the third scenario we still used the Expression Language but in a slightly different way. How many of you are familiar with group membership rules? Okay, some people, fewer people than before. Group membership rules allows you to automate putting users into and pulling them out of groups. It's important because groups power a lot of capabilities within Okta. Frequently they're used to assign users to an application by way of groups, so put all these users in a group, assign that group to an app, and anyone in that group gets access to the app. The groups are also used to set particular entitlements within an application. So someone might be a system admin if he's in this group. Someone might be a contributor if he's in this other group.

Groups are also used to enforce single sign-on policies and MFA policies. So it's very, very powerful what you could do with these feature. Without this feature you would have some admin putting people into groups and mainly pulling them out of groups, maybe when their position changes, maybe when they get removed from the org. If you rely on those manual processes, you might make some mistakes, so users might get the wrong access. This automates that. What Isaac effectively showed was attribute based access control based off of attributes. If you're assigning an application, in his case workday, to a group that was automatically populated by those rules, everyone who's in that group should have access to that application based off of good, clean data.

Now let's do a recap. Again, if you want to implement any sort of identity management system whether it's Okta or one of our competitors, you need to actually bring all that stuff together, to bring all those authoritative sources together, and create that single source, that one source from which you can administer access. If you have a variety of sources we've got the answer to help you solve that through agents as well as Cloud based connectors. We've got, of course, Expression Language to clean that stuff up. Planned Parenthood has derived quite a bit of value from using this. They've got clean data. Their apps can depend on it. But also their app administrators would also be very happy. They don't have to go looking around for the right source of truth if it's dirty.

Now we'll open it up to any questions. Isaac and I will be happy to answer them. I think we have about 10 minutes or so. I'll be at the expo hall at the lifecycle management track if you have any questions. I'll also be at the birds of feather lunch sitting at the identity governance table. Any questions? We're passing around the mic so please wait for the mic. One in the front.

Audience:  I just have a quick question in terms of the code that you did for the mapping, in Okta is there a way for us to keep that as a separate table where we can reference instead of hard code it in the expression?

Aaron Yee:  The expression is actually written within the mappy itself. There's no way to actually put it in some other table. Any other questions? One right here, second row.

Audience:  Hi. I was wondering if it's possible to create app specific attributes that are separate and not mapped to user profile attributes in Universal Directory?

Aaron Yee:  Sure, good question. You can certainly create your own app user profile. So you've got the Okta user profile, which represents the actual Okta user. And then you have another profile that represents your source of information, so for instance AD for that user would have its own profile with its own set of attributes. And then your target app, let's say it's Salesforce or in this case OrgWiki would have its own app user profile as well. And you can add custom attributes to it and not choose to map it, so you could use it as a store of information. Did that ... Sorry.

Isaac Brumer:  I think you don't have to have the exact attribute from the app in your user profile. You can have an app, if you've got an attribute in the user profile you just need to define either an attribute or an expression that is the source for that attribute in the app profile. There's no redundancy in the user profile. Also you can choose not to make something, not to push an attribute from the user profile to the application as well.

Aaron Yee:  Question right here.

Audience:  I'm currently using a lot of apps assigned to all users group, but sometimes people call me and say, "Hey, I'm not assigned to the app." What happened there? Is it timing issues? The person is not assigned to the app even though I assigned the app to all users.

Aaron Yee:  Right, so we have a group in Okta called the everyone group, and by default all your users that you create, whether or not they go into it, if you've assigned that everyone group to an application. I assume the application supports automated provisioning. Yup, it does. If your everyone group is assigned to an app that has provisioning turned on, what should happen is everyone in that everyone group should be provisioned up to the app. There's certain problems that might prevent that. Timing. Something might have failed out on the API call to the application. Maybe you're missing an attribute. Maybe the user just didn't have that data. Maybe it's just slow. Or maybe you've had some sort of limit exception on the app side.

Audience:  So what's the best way to deal with this problem because when I do it manually there's nothing wrong with it. So it's really the timing issues where this person might have missing attribute, but I guess there's a certain process you do on the other side to cycle that.

Aaron Yee:  Right. Good question. We have something called a jobs cue, a job server. So anything such as like an authentication or a provisioning even gets basically stacked on that, and the job sort of just crunches through it. Maybe your job server is just slow for whatever reason. You may have a ton of imports that's slowing you down and just taking a while. By default Okta will just try to retry it if it misses hit the first time. We also spit out tasks if something fails. So in your case it sounds like you're not missing any data unless you're filling it in completely different manually. But it will kick up in a task if something fails for an exception. But if there's no exception we'll retry it.

Audience:  I have an application that uses SAML for SSO. It needs an attribute that we want to dynamically create, and that would be a district assignment for this particular user. That district lookup information is available in an oracle database table where I have keyed my employee ID. I have the district number. Let's assume that in my Active Directory I've got the employee ID as an attribute. Is there a way in Okta natively to go and dynamically retrieve that district number based on a lookup by employee ID.

Aaron Yee:  Right. Apparently there isn't a way to do a dynamic lookup, so at the time of sending out the SAML instructions we can't say, "Okay, query the Oracle database and pull out that value." It needs to be populated in Universal Directory.

Audience:  So if I don't want to statically provision that in the Universal Directory would you recommend an option like a virtual directory that could stand up, perhaps, an LDAP interface and then use that an additional source of truth.

Aaron Yee:  Yup. Because then the virtual directory could then crawl that stuff dynamically and provide the information to Okta.

Audience:  Right.

Audience:  We have a situation where we would like Okta to be able to provision groups within Google. So based upon some AD like location and their job title we would like them added to distribution lists in Google. Is that possible?

Aaron Yee:  Sure. I don't know about the last mile, which is distribution groups. You can talk to Kyle Deidrich from AD who would know the specifics of that integration between Okta and Google if it's a distribution group. I think we can push it. The previous part of that question is can you then use attributes in AD to put users into groups and then push that group membership out to Google. You certainly can using that feature that Isaac showed you, group membership rules. You would just write a rule, identify a group that you want to put the user into if they match that rule, and then you would then in your application map that particular group to your distribution group in Google or any other group in that target app.

Audience:  Question about which attributes do you decide to port over to Okta. We've got Workday as a master right now integrated with Okta, and we have our choice of 250 attributes. Which ones do you pull over, and I'm thinking in terms of Salesforce the second part of the question is what about PII data?

Aaron Yee:  I'll take the first part of the question. You talk about maybe PII if you want? By default I think in 2013/2014 we pulled over what we thought was the best set of profile data, about 20 attributes, from Active Directory into Okta or the same 20 attributes from Workday into Okta and then downstream it to Active Directory. Since then we expanded that. So we said, "Hey, we're doing a bad job at guessing what these 20 attributes should be because customers have different needs." So we opened it up, and as you mentioned we put power into the hands of customers, and now customers want to scope it back down because you now can choose from whatever Okta finds in Workday, in AD, or in LDAP. It does a schema of discovery, so it basically crawls out to your source of truth, AD, LDAP, or HR, and it says, "Hey, give me your entire schema. Let me see what's available, and then you can choose what to bring in."

We probably have old documentation that shows what we thought was best three or four years ago. Going forward we don't have good guidance for that. It really depends on what the customer needs, and we just say, "Limit the amount of data you bring in to what your apps need" because you can always go right. Within Universal Directory it's easy to say add another attribute and just map it in if I'm missing it initially.

Isaac Brumer:  I think every industry is gonna be different. There are gonna be times when you need a certain attribute, and therefore you're gonna include it, and there are times where, "Okay, this is really not needed, and it's not prudent to include that," so you just don't.

Aaron Yee:  If you have PII it's typically an extended attribute, one of your sources. When you build the profile in Universal Directory and you add a custom attribute those are all stored encrypted, so you know if you have PII we can store it securely.

Audience:  Can you utilize the group rules to connect multiple groups off of one rule itself, so when you have one rule is it one to one membership for assignment or can you utilize one rule to assign to multiple application groups?

Aaron Yee:  Yup, good question. I think right now there is a one rule to one group limitation. I know Amy Kim who spoke previously was actually working on a feature to allow one rule to assign to many groups. I have to see what state that's in. What we've heard from customers is we're writing the same rule for all the different groups. We just want to be able to consolidate that.

Question?

Audience:  Question's about if your source of truth is a SaaS app that in your example was Workday, take for example an application that may not have provisioning. Is that completely off the table? Is provisioning a requirement to have this mapping of data?

Aaron Yee:  Right. In order to get this to work you typically need to have some sort of API connectivity to the application. If the app doesn't provide it, then we would have to build some sort of custom integration to it. Maybe if it doesn't expose any APIs at all then you might have to do an export of like a CSV, and then using our OPP on premises provision connector you would then have to code up something to read from that CSV, and we could treat that on premises provision connector as a master source. Anything else? Okay. Thank you very much. We appreciate it. If you have any other questions we'll be around after the forum. I'll be at the expo hall and at lunch, so thank you very much. Appreciate it.

Isaac Brumer:  Thank you very much.