Uplevel Your Out-of-the-Box Lifecycle Management Systems
Ashley: Rafael Kabesa is the senior product marketing manager at Oktane, managing Okta Lifecycle Management product. He started his career as a software engineer in the defense sector working on reconnaissance systems for jet fighters and later moved on to a product marketing for a new virtual storage business at VMware. Rafael holds a bachelor in science and computer science from The Technion as well as an MBA from the University of Chicago. He'd also like you to know that in his spare time he enjoys snowboarding and playing soccer. With that, help me welcome Rafael.
Rafael Kabesa: Thank you, Ashley, for the introduction. Glad to have all of you over here. What we'll cover today will be a premier for lifecycle management. We'll talk about why Lifecycle Management is important, how Okta can help you and then I'll have a panel of customers talking about some of the more advanced use cases.
To kick us off, why Lifecycle Management? Why should you care about managing life cycles? It's just because everything in the organization has a lifecycle. Obviously, you know about employee's life cycles but there's external users, there's partners, there's contractors, there's contingent workers. Also, there's developers, whether inside the organization or outside the organization. You need to manage their lifecycle as well as APIs the access to. The common thread around all these identities is that all of them have a lifecycle.
It starts with establishing the identity and sourcing the information about the identity. It moves on to assigning resources that identity can access to. Then auditing that access and trying to figure out whether that should change or not. If it doesn't change, you need to make sure those changes happen in a timely manner. Finishing off, you also end the relationship, in some cases, and you want to make it in the most effective way possible.
While you're probably familiar with already managing life cycles for employees, managing life cycles for outside developers or APIs or devices your organization doesn't own is fairly new. What happens is that now it's more challenging than ever. The reason is, first and foremost, the rate of change in business has never been higher. We're not just talking about users that are internal and external, so you have a lot more users and identities to manage, you also have exponential amount more of apps. If you heard Ben Horowitz in today's keynote, we used to have 12 apps in the organization, now we have 800.
Those relationships between users, their apps inside the organization, outside the organization, are all becoming more complex and changing a lot faster. At the same time you're also pressured to deliver both security and productivity by the business. In some cases, with less resources than in the past. To top it all off, the existing solutions you might have just don't keep up with that rate of change I just mentioned, right? They don't adapt to the new cloud architectures. They don't adapt to the requirements you're getting from the business. If that's not enough, in some cases, it's really expensive to maintain them. Any update might be very costly.
How can we help? What does Okta Lifecycle Management? How we like to describe it; it goes into those four core feature areas, and I'll talk briefly into each one of them and then jump into a quick demo about it.
Extensible pre-integrated provisioning is the core of our product. We have over 95 out of the box integrations for provisioning for different cloud applications. That library of provisioning integration keeps on growing thanks to our SCIM developer program where we have ISVs coming and developing those provisioning connectors for us. That is going to keep rapidly growing thanks to our ecosystem and our work together. Those connectors are not just about creating, updating, or deleting users, it also has deep integrations in terms of what it can do.
You can master from some of the apps, especially in terms of directories, whether these are HR, CRM, or ERP directories. We have the ability to do things like Schema discovery in some of the apps, so we can look up the profile of the app is expecting, expose that into Okta, so you can easily create the profiles as part of the provisioning integration. We have things like license management for apps like G Suite or Office365, so you can decide how to assign or remove licenses based on the changes and lifecycle states.
On top of all that, I just mentioned our extensibility, we support SCIM 2.0. That allows, not only ISV to integrate with us, but also for you. If you are developing an internal app and you want to create a provisioning connector, you can also join our SCIM developer program and have all the user profile and provisioning automated there.
Our universal directory is much more than just a user store. It has lifecycle states, it's lifecycle aware and we can extend the user's profile. Even if you're mastering from a certain source of truth, whether it's an active directory or an HR directory and you need some customized special attributes as part of the user profile, it's really easy to extend within universal directory. I think one of the best features in universal directory, and maybe if you were here for the previous section, you saw how effective attribute transformation can be. You can take any set of attributes and manipulate them using our expression language to fit whatever the app is expecting or you need it to, in terms of provisioning.
In terms of lifecycle orchestration we have a host of features, starting with our ability to centrally manage groups. We had group push for a while, but now we added an additional capability on top of that to link two existing groups and have you master all the group management within Okta. We implemented that initially for the three key apps, G Suite, Box, and Active Directory and I'll show a quick demo of that in my part two.
Policies for access decisions, this is all around our group rules as how do you automate. Somebody joins, somebody moves within the organization, how can you create rules that constantly evaluate and give the right access to people. I'll touch on that in the demo as well.
Last is our workflow for process automation. Our access request [inaudible 00:07:47] one of the recent things we released in the last year is the ability to delegate an access decision from IT to the app owners. In IT you don't want to be the one stuck in the middle between the end user and the app owner, just being the mediator. You want to delegate that access decision to the right person so there's no need for IT tickets, et cetera.
Last, simple access governance. We released a new set of reports, which we call the app access audit reports, helping you to figure out who has access to what, what accounts got de-provisioned and then our recent report release was around orphan or rogue accounts. I'll showcase all of those in the demo as well.
In Todd's keynote, you might have seen him talk about scheduled suspension. With the contractor use case in mind, we want to make you more efficient in how you manage identities, life cycles that are not employees. For contractors, you can schedule suspension and that just ... The first phase, which we call the lifecycle policy, the lifecycle policy will enable you to move any user from one lifecycle state to another based either on date or number of days or also based on activity. There's more to come around this but that's further down the road.
Now I want to switch to a demo and show you a little bit about what I just talked about. I already pre-populated a Workday here. I talked about our ability to master users from an HR directory. I already pre-populated a Workday with my new employee here, Jerry Seinfeld, has a great show here in Vegas. Jerry here is going to work in marketing. Notice his title, senior manager in field marketing that's gonna play a role in how I'm gonna automate his onboarding. I just pre-populated that. I hit submit here to get Workday started with his hiring process. It has completed. Before I look for Jerry's profile, I want to show you why I told you to look at his title. It's really around these group rules that I created, if you notice around the second rule here is old marketing. I look at the user title and if it contains the word marketing, I put it in the marketing group. This is a very simple rule, of course. With the expression language you can create a lot more complex logic. Just to simplify things, this is where Jerry should be assigned.
If I go to my groups, and I look up my marketing group you can see that the access that is associated with it is very specific to someone in marketing. Somebody in marketing needs Marketo for his job, so he will get assigned Marketo and maybe I want to give them RingCentral for whatever communication needs they need. Let's look up Jerry. You can see Jerry was automatically created in my Okta org. I didn't need to do anything because I have that tied integration with Workday. I'll click on Jerry's profile and then if I jump here to his profile, you can see all the attributes flowed from Workday into Okta automatically. Not only did I create a profile, I also sourced all the attributes. This is where I can read into the title and automate his access. If I look at the apps Jerry has access to, you can see Workday, Marketo, and RingCentral.
Let's go ahead and activate Jerry. Jerry gets an email, "Welcome to Okta." We click it. We just do the initial onboarding here, setting up his password. Jerry really didn't like fish as a child. Create his account. Then you can see how Jerry already has access to all these apps. One of them is a [inaudible 00:12:33] so we need a plugin. Jerry also wants to collaborate with other people in the organization, in terms of content sharing. He clicks on add apps and says, "Oh, here's Box, Box is perfect for what I need but I currently don't have access to it." How can I help Jerry be self service and not have this flow through IT through an IT ticket? You can see I have this request button, and once I click it Jerry can specify a reason why he's asking, as well as looking at how these things go.
Let's say I need to collaborate, then hit request app. Request is getting sent. To keep things simple, I keep myself as the approver, as the Okta admin but just to quickly show you how easy it was to set up that workflow as an admin, you can see there's the configure approval process here and under self-service in the app and you can see I add the Okta admin here as the approver, but I can have anybody in the organization and they don't need to be an admin whatsoever approve. I can drag and drop the order of the approval so it's a multi step approval process. Same goes for, maybe I want to group people approving, so I don't want one person. Maybe I want the management group to be part of that process and anybody in the management can be an approver. To keep things simple, I just keep myself but other things you can do here is set up way what happens if there's no response after a week, et cetera.
Let's go to my task inbox. As an approver I have a task inbox and you can see I have an old request here for Office365. Here's is Jerry's request for Box that came in just a few seconds ago. You can see I can see the reason why he's asking for it but not only that, because we have entitlement management and group management with Box, I can also assign Jerry to the marketing group. I know Jerry is in marketing, I can assign him to a marketing group and I can also make him a user or an admin based on what I know about Jerry. Once I've finished, I can decide whether I want to approve or deny or can also put a comment about it. Once I click approve, I can go back to Jerry's profile, click on refresh and you can see he gets immediately a notification about being assigned Box. Not only he got assigned Box, we also created his account in Box because we have provisioning integration with Box. Obviously, there's still an activation process that goes through box but you can see I can already access into Box and get started.
Another good thing about the group mastering that I just mentioned is the ability to sync group management. I'll just refresh the users. This is the Box admin view and I'm just showing you that so you can see his memberships. Jerry was already created, he has an account, and then in terms of group membership you can see I assigned him to the marketing group as part of the approval process and he's a member of that but not a member of these two other groups. I created this test Box group just to showcase that. If I go back to my admin console you can see ... I'll go back to the Box application and I want to show you how I set up the group mastering feature. Under the push groups tab you can see I have these three different groups continually syncing between the Box memberships and the Okta group memberships. Every membership change I'll do in Box test in Okta will automatically flow into Box. Just to show you that, I'll look up Jerry. I'm back in his profile. In terms of groups, I'm gonna add him to the Box test group. I added him to the Box test group in Okta and now I expect him to show up simple as in Box. What I'll do is go back, just refresh here, go back to his profile. You can see, now, he's automatically a member of Box test in Box. Very easy to set up, very easy to centralize your group management within Okta without needing to jump between one admin console to another.
Next is, security may be coming to me and saying, "Well, we need a report about everything Jerry has access to." This is where we have the app access audit report. I can switch here to all the applications assigned to a user. I can look up Jerry and want to report and see what Jerry has access to and how he got that access. I can see the Box app was through the approval process. The Okta admin approved and I can see who approved that request. I can see, also, how he got access to Marketo, RingCentral through the group rule and for Workday through an individual assignment.
Let's say I want to do that on an app level and maybe I want to look at an app like Salesforce. Similarly, I can see a list of users and how they got access to Salesforce, whether it was a group rule like the sales group rule I have or maybe an individual assignment by an Okta admin. Maybe I need to add a little more information for an auditor to interpret this, so we have this advanced option, where I can add any app attribute to this report. The profile in Salesforce usually tells me a little bit about what the user can do and maybe I want to also look at what department that they belong to. Maybe they're not in a sale related department and I want to look at that. Once I add that and I click run report and I can see all the profile. I have just the demo tenant with Saleforce so you can see only Chatter users, but you'll see the appropriate profiles there.
Sames goes for department, I can look at what department things look like and maybe I want to audit Duke's access because he's in HR, why does he have Salesforce, right? I can export all that and send it across to auditors, et cetera. Now you might say, "Okay, that's great, but that's only who's assigned in Okta, right? How do I know if an app admin in Salesforce added somebody behind my back." This is exactly why we created the rogue accounts report. If I go to Salesforce and I click run report, what happens now is Okta is asking Salesforce, "Tell me who are the active accounts in Salesforce.", pulls that information, cross references it with what Okta knows, and then tells me all these 8 accounts only show up in Salesforce but are not assigned in Okta. You might want to check why they're assigned access. Maybe Brian Adams here got assigned Salesforce by a Salesforce admin without letting IT know, so we might want to audit that.
On the flip side, I can also see who's assigned in Okta but is not assigned in Salesforce. Maybe Grace is assigned Salesforce but once she clicks the chiclet, she won't have access and maybe that app admin delivered that access by accident. I can preempt the IT ticket that might get created.
This is all I have for the demo and I want to switch, now, to the panel discussion. I want to welcome to the stage our three panelists. Please welcome to the stage the Triple D's, Dave, Dan, and Diana. Please, come to the stage.
Diana Birsan: Are we pulling these up?
Rafael Kabesa: Yeah, I can pull it a little bit further.
Diana Birsan: This is weird.
Rafael Kabesa: Thanks, guys, for joining us. If I forget your name then I'll just say D, right?
I'd like to kick it off with maybe just introduce yourself to the audience. Tell them a little bit about who you are, who you're working for. If you want to just tell a little bit of a background, what you had before Okta and how did you handle life cycles identities before Okta. Then, a little bit about the challenges and how Okta helped you with those challenges. Dave, you want to kick it off?
Dave Lavelle: Sure. I'm Dave Lavelle, I'm the IT manager with Pure Storage. Been a long time Okta customer, been about six years with three different orgs. You're making me think back to the dark ages before I had think pre-single sign on and Okta. It was a lot more manual and it was a lot more painful.
Dan Bowden: I'm Dan Bowden, infrastructure engineer with a company called Xero from New Zealand, we do accounting software. The accounting software itself was born in the cloud, which is great. Our infrastructure, we started off with Okta directory and had all sorts of onboarding and offboarding issues. What apps to assign to people, trying to work out what we need to give them and how to get them that access. Putting Okta in solved all those problems. We've been with Okta, coming up on four and a half, five years now.
Diana Birsan: I'm Diana, I'm an internal security developer at Shopify, it's an e-commerce Canadian company. We have been with Okta for two years now. I think before Okta we never had an LDAP, we were full G Suite only. We were pretty small so it was relatively easy with tickets to assign people the right access that they needed, but it just progressively got worse. Lots of SASS apps, lots of things. The same issue with de-provisioning and everybody joining, leaving and not being able to audit things very easily, no automation. Okta came about because of us IPOing. We needed a proper system for auditing access for making sure that our auditors know who was granted access to what and when it was removed. That was the big thing that made us change into this system of using Okta for everything, really.
Rafael Kabesa: For data management?
Diana Birsan: Yeah.
Rafael Kabesa: Dave, I remember from our conversation that you said you implemented Okta more than once, right?
Dave Lavelle: Yeah, in addition to Pure, I've done it at two other shops. We've done it without needing the infrastructure, similar to what Diana's done. We've also put it in a couple of other places where we had to work around preexisting infrastructure and things like that. All of them, the common thread has been the automation has really paid off for us, in terms of being able to save a bunch of time, keep it only on help desk staff and of course, SOX and security are always a big pluses when you can keep both compliance and the security team on your side.
Rafael Kabesa: I think a lot of companies, as they think about IPOing, and we hear that from a lot of customers, as they think about an IPO and understand it, "Oh, I need a lot more visibility in terms of who is accessing what. When accounts got de-provisioned, et cetera." We see that common thread of, "Okay, we need an identity management in place. Something that can get us that visibility and management and streamline things." Great points.
One of the reasons I asked all of you to join me in the panel is because you're leveraging more of our advanced features. One of them that I just talked about, the advanced mastering, so mastering from a source other than active directory. Most of our customers will use active directory as a master but you chose to go in a different route. Can you share with the audience why you chose to master from a different source and then how did that help you achieve whatever goals you had in mind? Diana, you want to kick that off?
Diana Birsan: Sure. Like I said, we were very G Suite oriented, we didn't even have Workday in place two years ago. It was just a no brainer. We rely on Google groups a lot in our environment, not just for email lists but for making sure that the right people have the right access. The fact that we could profile master through G Suite, we were able to retain all our Google groups the same way that they were there. Once we actually pulled that information through mastering, we do a lot of our provisioning through those groups. The big thing that we try to do at Shopify is be invisible with that kind of workflow.
A user enters Shopify, gets provisioned an account and their team does an onboarding for them based on their role, developer UX, whatever. They get put into these mailing lists, or so they think they're only mailing lists, just to get information through email. What they don't know is we actually use those to provision the apps that they need, like Neural or for a developer it's the AWS, all that kind of stuff. It's so automated and seamless that our IT team never really has to do anything. It's just right off the bat, they hit the ground running, have all the apps that they need just based on simplistic Google groups.
Rafael Kabesa: A lot of automation around onboarding, offboarding, right? What about you, Dan?
Dan Bowden: Before we mastered from Workday, as I touched on before, when we were setting up a new user the way that we assigned apps was to find another user that had a similar role and go through and guess some apps, basically. That was obviously very manual. We're putting in Workday with the HR team decided on it. We just saw that as our opportunity to really automate the whole process. It took a little bit of work with the HR team and it was good, we've got a really good relationship with them.
Rafael Kabesa: Yeah, that's important.
Dan Bowden: Because we were kind of ... we had the control before that of setting up all the users, and suddenly we're giving it away to another team. There were a few bumps along the way when we were doing that. Now it all works really well. We use anything from location role, the team they're in, to provision into Okta and then we push through to Google, set up different distribution groups, but also into apps like Slack. We assign users access but also different channels based on where they are or what group they're in. Same with Zendesk, different agents and different groups are all automatic, it just all happens without us even thinking about it.
Rafael Kabesa: Dave, you're also mastering from Workday, right?
Dave Lavelle: Yes, we're also using Workday. We found in addition, Dan did a great job of summing up a lot of those, we've also just found the value of having all that stuff in universal directory and being able to flow it downhill, too. When you've got something like an LMS or something, where you need additional information about the person, you can assure that it's the most up to date information and it flows right into where it needs to be. Having that ability to be able to get those things in the right place-
Rafael Kabesa: That real time sync. Yeah, that makes sense. Alright, that's great.
I guess my next question is more around, you're taking advantage of advanced mastering, are you taking advantage of ... I think you kind of implied to it in your answer for maybe group rules or access requests or any other things you're taking advantage of, Dave?
Dave Lavelle: Yeah, absolutely. In addition to having it flow from Workday into Okta, we also have a small AD instance underneath. It gives us the flexibility to either work with the Okta rules to be able to assign things, to work out scripts for some AD groups for some of those older LDAP applications, which maybe not much longer on that. A bunch of other neat, forward-thinking things. We've looked into some chat bots, for example, to provision apps to people when they ask on Slack, and things like that. Try to automate leave of absence situations, things like that.
Rafael Kabesa: With a Slack bot?
Dave Lavelle: Yep, that's the goal. We've got it provisioning apps right now like Lucidchart and a bunch of those standard ones, where maybe you don't need on the day somebody's hired, but once they realized they need it, no reason not to get them set up right away so they can get to work.
Rafael Kabesa: Delegating to the robots. What about you, Dan?
Dan Bowden: Yeah, we use a lot of group rules. We use push groups as well. We're still running active directory, so we push groups down from Okta into there.
Rafael Kabesa: We hear a lot about customers just flipping the order. If they used to master from active directory, now they're pushing into directory.
Dan Bowden: Exactly. We still have a little bit of reliance on active directory that we're trying to get away from that.
Rafael Kabesa: Yeah. Like most.
Dan Bowden: Seems like we can get a little bit closer, I think.
Rafael Kabesa: What about you, Diana?
Diana Birsan: I guess I'm blessed for never having to deal with active directory, as it sounds, so that's a good thing. We've recently gotten into everything, really. We've always been using Google groups for provisioning but now we're trying to sell service for applications that are sort of one off, somebody just needs it, it doesn't really have a heavy license cost, whatever. That's just ... very open culture at Shopify, everyone's sort of trusted with that amount of access. For the more expensive apps or the seat license apps we do access request workflows, now. We do them the same way for our in-house apps, as well. We find who really runs that application. Who really should be making that decision so that it isn't an IT ticket anymore. We make sure that we assign that app access workflow for everything possible. We're well over 100 apps in Okta, a lot of in-house apps as well. Whoever is the project lead is, we make them the sole approver or we do a Google group for approvers and we make that open to just those owners so they can add or remove anyone they want. It takes a little bit of time to set up but once it's done, it's just out of our hands, which is great.
Rafael Kabesa: It sounds like you're also taking advantage of our delegated admin option.
Diana Birsan: Yep.
Rafael Kabesa: Yeah, that's great. We had a couple of exciting announcements in the keynote around lifecycle management. One was self-service registration, and the other one was around scheduled suspension, or lifecycle policy. Do you envision yourself maybe using those features, Diana?
Diana Birsan: Definitely. Self-service registration maybe for contractors, as well, but I think the scheduled suspension is huge for us. Once again, this automated task of somebody leaving or we already know they're just a one year contractor, being able to just set that, forget it and revoke access right at the time it needs to be revoked is huge. That's going to be great.
Rafael Kabesa: What about you, Dan?
Dan Bowden: Definitely the scheduled suspension. Also the number of days, if they haven't logged in for a month or something.
Rafael Kabesa: Adaptivity part.
Dan Bowden: Yeah. We currently have some scripts in active directory doing that and having to maintain those and everything. Just being able to put it all in Okta sounds really great. I'm not sure about the signing up ... What's it called?
Rafael Kabesa: The self-service registration.
Dan Bowden: Yeah, not sure we'll use that too much, because all our users have to go into Workday anyway. I'm sure we will probably find a use case for it.
Rafael Kabesa: Yeah, alright.
Dave Lavelle: Yeah, we can definitely see both of them being a big plus. The self sign may actually help us resolve an ongoing back and forth we have with the Workday admins around what needs to take up a seat in there and what's appropriate to put in there for a number of reasons-
Rafael Kabesa: Because it cost money, right?
Dave Lavelle: It does and from an audit and compliance perspective. Legally, there's some stuff that they think there's differences about where we'd like to place certain kinds of contractors and pro-services and things like that. We can definitely see that. Circling back to that leave of absence idea, being able to apply something like that with the suspension, as well, and not just have it be people that time out or maybe people that need to take a hiatus for some reason and have their access come while they're on maternity or paternity leave, that kind of thing.
Rafael Kabesa: Perfect. We have about eight minutes left. I want to open it up for a Q and A from any of you in the crowd. Questions to myself or anybody in the panel. Please, just raise your hand and the microphone will come to you. We've got a few folks here. Thanks for kicking us off.
Audience 1: Thank you. Just a question to the panel regarding the use of AD. Why do you use it and how come you haven't moved to [inaudible 00:36:07]?
Rafael Kabesa: Why are you using active directory?
Audience 1: You talked about legacy go into detail.
Dan Bowden: We have a couple of requirements, still, for it. I think potentially that AD, what they were talking about this morning, may actually solve some of that with Confluence and JARep. We still have wireless radio service and things like that. I can't think of all of the reasons but basically everything new that we put in, obviously we try to go for something that's similar and can go into Okta but just a handful of legacy systems.
Rafael Kabesa: And some apps that are still very much dependent on AD.
Dave Lavelle: Yeah, same reason. It's a lot of the hardware driven stuff, which I think this morning they did a good job of checking a lot of those items off the list. Things like being able to do VPN or things like that and have it still go back to the same option. There's also some occasions where AD groups in their own right are a little bit useful. I was lucky to enjoy what Diana did, my last shop didn't run it at all. There's pros and cons to both, I think that's the beauty, Okta lets you make the choice.
Rafael Kabesa: Any other questions?
Audience 2: This is to the presenter.
Rafael Kabesa: Okay.
Audience 2: One of the records that we found work in Oktava is some of the integrations are pretty shitty, especially with the provisioning. It's not on your end, it's on the app end. How'd you like to address that? Especially anybody you have that requires licenses and stuff like that.
Rafael Kabesa: In terms of license management? In terms of provisioning integration, we work very closely with all the top apps in the Okta integration network. We do communicate. If you open a ticket with us around something that doesn't work like deactivation or license management or something, we'll have a communication line with the apps themselves. In terms of ISV management, we saw some approach with larger organization that have a little bit of leverage with those ISVs that communicate that to the ISV and put some pressure on their side because sometimes we don't have that clout. Some of the larger organizations help us push those improvements. Then there's always alternatives. There's over 5,000 apps in the Okta integration network. You can always look for an alternative that maybe works better and that also can be either a card in your end to help push them to make an improvement or just make a switch. Dan actually did that.
Dan Bowden: We were using FlowDoc previously and the provisioning and de-provisioning, the promised it for a very long time and we just recently moved to Slack because it's got everything.
Rafael Kabesa: So you have the power to use whatever app that works best, take advantage of that. Maybe your contract ends in a few months. Either a negotiation card or just do the card over.
Dave Lavelle: We've even gone so far as to even include it in our security survey when it comes time when we're signing on with a cloud app. There are requirements that our security teams put in there in terms of it needs to be strict SAML and it needs to have good provisioning. If it's not, that's a great, "Hey, we're filling out this form but that's gonna be an important part of getting the contract signed.
Rafael Kabesa: Yeah. Any other questions? Probably have time for a couple more.
Audience 3: Going back to the example of Jerry Seinfeld you created in Workday and it went down to okta. He was in a password reset state. Let's say that Okta was active directory integrated and you wanted that account to show up in AD as well, would he still have been in that password reset state and if he were to reset his password, would that become his active directory password, as well?
Rafael Kabesa: We can push the password down to AD and we can provision the account, not only in AD but in the specific organizational unit based on that group association. I didn't show it this time but I did do a presentation as part of the Okta form where I actually show it flow and it puts the person in the marketing organizational unit and then we can also push the password down to AD so that's the same password that you'll have with AD.
Audience 3: So the password policy would be the Okta password policy that would apply?
Rafael Kabesa: Yeah. We're enforcing it on our side, obviously it will be enforced down in AD, yes.
Audience 3: Thank you.
Dave Lavelle: You can set it up either way. We master out of AD for the password policy itself but it's uniform through the whole stack.
Rafael Kabesa: Okay, thanks.
Audience 4: Hi. We're developing a push versus pulls strategy where push is based upon access by policy and pull is access based upon individual approvals. I noticed a number of you had individual approvals already built in, which is advanced, and congratulations. I'm just wondering what the UI is for those? How do people get access to it?
Rafael Kabesa: To getting the request button?
Audience 4: Yes, the request specific access to specific applications.
Rafael Kabesa: It's a good question. Right now it's very easy to turn it on. I didn't mention that but access request workflow is still in early access so you need to ask to turn it on from your support person if you want to use it. We have a host of companies already using it, Diana is one of them. In terms of the self-service option, right now it's just for apps but we did get feedback that people want it for maybe specific groups or rules, et cetera. That's part of the improvements that we're doing for the next iteration on this feature. There's some interesting stuff coming off the line but at the moment it's just for requesting access to an app. It's very easy to turn on. As you saw in the configuration, you just flip the flag there to require approval and then the users see it in the self-service option. Yeah.
We have another minute, maybe another quick question.
Audience 5: Just to ask the question you can how does the [00:43:05] get the email? If [inaudible 00:43:06] uses, for example, google apps, if I give you access to the account to work as a master, he gets an email you said without having an account in there.
Rafael Kabesa: That's a good question. As part of the workday as a master we could also master what we call attribute level mastering. We can master different attributes from different sources. While I master from Workday most of the attributes, I can actually choose to change priority on the email attribute to be Exchange or Office365. That's what decides your email and then I can get that into Okta and send that as your primary email.
Audience 5: The problem those, we are controlling everything through Okta, even Office365, Google Mail, everything is controlled through Okta. Unless you have a password, you cannot access any of those applications. You're a brand new user to the company. How do you communicate your credentials? Like this is your ID and this is your password.
Rafael Kabesa: You can also have a secondary email that can also be their personal email. You can also send it to that if you want to activate that just for the first time use.
We're out of time. I'll be hanging around here a little bit on the side if you have anymore questions. I'd like to thank my panel. Thank you, so much, for coming. Making the long trip from New Zealand, too. I hope you enjoy the session and enjoy the rest of Oktane.
New to managing identity lifecycles? Do you still rely on scripts or manual processes and tickets? In this session we'll cover the basics of lifecycle management, along with all the latest features released in the Okta Lifecycle Management product. This session will also include how to use Okta to automatically create accounts in downstream applications, how to sync multiple sources into Universal Directory, how to leverage that to create groups with specific access to applications and entitlements, and how you generate reports to figure out who has access to what. A panel of Okta LM customers will also share their use cases.