Okta Roadmap: The Next Lifecycle Frontier

Speaker 1:  I would like to introduce our first speaker. George Kwon is the Director of Product Management here at Okta. He is responsible for our universal directory and provisioning products. Prior to this, he has had eight years of technical product management experience, most recently with Euclid Analytics shopper and engagement and loyalty platform. With that, welcome George to the stage.

George Kwon:  Thank you. How's everyone doing? I don't know if you had to transfer the music, but it was like feel the pressure, feel the pressure. That was pretty intimidating hype music to welcome you on stage. Thanks everyone for persevering through the week. For some reason, people are always just a little bit more tired and slow on Wednesday morning. I don't know why.

We have a lot of great content today to talk about. Throughout the week, my colleagues throughout the lifecycle management track shared a lot of great content. We had Aaron talk about how you create a single source of truth around all your directories. We talked about managing difficult lifecycles integrating with ServiceNow and other ITSM products.

Joel talked about our APIs. We like to take this roadmap session and then have it towards the end and my goal is to do a couple of things. One, definitely share the roadmap in terms of where we are going and new capabilities that are on the horizon, but maybe more importantly explain to you guys why we are building lifecycle management. What are the problems we're trying to solve? What is our vision for the future? I think that's sometimes more important than the features because you're embarking on new projects. You're trying to make long-term investment decisions. Being in our heads and knowing where we're going is really important.

I have some legal leads here. I'm going to talk about future things. If you want to take a minute and read through every word, you can, but I'm going to just breeze to the slide. I'm George. I'd like to get to know you all a little bit here. How many folks in the audience are a customer today? Raise your hand. Wow! That's like three quarters of the room. Thank you very much for your business.

Our customers are really critical to the product management team because it's you guys who help us determine our future. We've really built our products on your shoulders and grown with all of you over time, so I want to thank you for that input. I look forward to all the feedback after this session and conversations here at Oktane and afterward.

How many folks here are a part of an organization with more than 2,000 employees? Maybe about half. Okta's Lifecycle Management product is really built for companies of all sizes. We have customers that are 100 employees and growing fast and needing to figure out how to scale for the first time. We have mature enterprises who have had identity access management products in their environment for 20 years and are looking to modernize and adopt the cloud. We really do serve a wide range of needs across different customer sizes. Any folks here international coming from outside the US? Nice. A lot of hands. Where are you coming from?

Speaker 3:  We have offices international.

George Kwon:  Have international offices? Okay. Some other folks looks like have traveled a long ways. Thanks for coming out here. That market presence is also growing for us quite a bit. With that, we're learning about some of the unique challenges in your markets.

I want to start by defining lifecycle management. At a very high level, we think of this as managing the lifecycle of any digital identity and I want to pause and define digital identity. Is it just a bag of attributes or is it also the user's credential and managing the lifecycle of their credential? Their factors, their device posture, the risk around that identity and the assurance you have around its identity, the entitlements, the roles.

With that in mind, while I'm primarily going to be talking about lifecycle management, I want you to think about how it's important for your identity platform to be integrated across these suite of products, across cloud directory, universal directory, SSO, our adaptive MFA product and mobility management. It's really critical for managing the lifecycle of all your digital identities and I'll dig into that in a little bit.

As I define lifecycle management, I often get this question. Is lifecycle management IGA? How many folks in the room know what IGA stands for? Most? IGA stands for Identity Governance and Administration. The primary goal of this product is to help you be compliant, pass audits for your most sensitive applications. You typically in your enterprise will have a financial system or an HR system that needs to be governed.

Is it a complete solution for managing the lifecycle of every one of your digital identities? Some of the things we think about is we figure out how much lifecycle management overlaps with IGA are with your identities is are you employee focused or are you managing any user in your enterprise? In parallel with governance, does the product help you manage security and secure access to all your users and resources? In addition to administration, what about end-user experience? Is it removing friction? Is it making access easier?

As we think about lifecycle management, we think of it a little bit differently than IGA and while we have a lot of overlap in terms of capability, policies, workflow, integration, from a use case perspective and from a problem statement perspective, we're less focused on audits and compliance and focused on the following four things. The first is lowering user friction. We get so much feedback from our customers that more important than the quarterly audit is making sure people are up and running and that the organization is productive. This is paramount and probably the number one driver of how we think about the product.

The second is administration at scale. Companies are growing. You're dealing with the extended enterprise. How can we help you automate, delegate and manage user identities at scale? The next is security first governance. While we want to help you with those compliance it needs, always taking a security first approach and making sure that any governance activities are also securing your environment. Finally, any digital identity and I'm going to spend a lot of time during this presentation talking about this, but how do we move beyond employees and think about every user you manage in your environment?

As a product, I'm going to give you just a quick overview and I know many of you have gone a lot of detail over the week of what the lifecycle management product is. You have your users, those digital identities. You're connecting them to resources and first and foremost you're building those digital identities and that might be from a directory, an HR system, self-service registration. Then, we have to connect those identities to resources and the reality is some of those resources may have an identity silo. We support that through provisioning both in the cloud and on-premise through our pre-integrated connectors and also through standards like SCIM. For applications that are federated, we're able to pass that identity information into those assertions as well.

Because we are the single source of truth for your digital identities, we need to be connected to the other platforms that need that identity in your environment. That includes ITSM, governance products that you may use to augment or manage specific applications, analytics tools, etc. Now, throughout this, lifecycles are not static. We deliver a set of workflows and self-service capabilities to manage an identity from onboard to offboard.

From a resource perspective, same thing, we help you assign the right resources to the right people and make sure we can manage those changes over time. This is just a quick overview of the product. What I want to do now is dig into our roadmap, our capabilities, things that are coming soon in the future and I'm going to do that by looking at these different personas. We'll start with employees. This is where our product really started and I'll give you a little bit of history and walk you through towards the future.

In talking to our customers, they are still facing big challenges managing their employees and it starts with security and governance. These are some of the problems we hear from you guys. "I have rogue accounts after a user leaves the organization. They have elevated access." From the end-user perspective, onboarding taking three weeks is not an uncommon thing that we hear or, "My user still have to manage multiple credentials and identities across these different silos." For your admin teams and your help desk, the Monday morning scramble to get a user onboard who didn't come through the HR system or your armies of people just creating task and closing tickets and creating accounts.

We set up to solve some of these problems when the provisioning product was made available three or four years ago where we started was a slice of this. We really began by trying to connect all of your employees to the cloud. Your identities were still an AD. We source those identities. We connected them to the cloud. We provisioned their accounts in cloud applications and we map in the lifecycle that you were managing an AD. When that user was disabled, we deprovisioned their accounts. We'd map access to the roles and groups you're ready to find in AD and that's how we determine to who had access to what.

A lot of our customers started here with our lifecycle management product and is often still even today the first step. We created that basic capabilities around directory synchronization around provisioning and then our customers ask us, "Help me go to the next level." There were few things driving that change. Your sources of truth like your HR systems were moving to the cloud. Your distributed enterprise still had a number of different directories and they were looking to consolidate and create a single source of truth. We did that. We integrated with the best breatheHR systems out there. We helped you consolidate your directories and, in many cases, the role of who own the credential changed.

We became the source of truth for your identities and your single pane of glass. We onboarded your identities from an HR system. We had them set an Okta credential, set up MFA, etc. We then connected them to resources and helped you understand who gets access to what and we did that through rules by saying that, "If you're in the sales team, here's what you get. If you are in marketing, you'd get a different set of applications." We then provided self-service around that, allowing your employees to request access, have that approved.

In many cases, while we still provision to cloud applications, the architecture flipped around and now we were provisioning your users into your on-premise directory as opposed to that being the source for identities. We master those directories, which you needed to keep around for your legacy applications. Because the identities and the credential were in Okta, we helped you manage your users manage their identities and their credentials in a self-service way and we terminated access by integrating with the HR lifecycle.

This is kind of gen two and maturity level two of where customers get to with the lifecycle management product. They start by connecting AD to the cloud and then they start to create a single source of truth in Okta and drive the lifecycle of identities through our product. Now, where are we going? We're continuing to invest in this use case. One of the focus areas for us in this past year was as a source of truth for those identities and what they had access to, we needed to provide better reporting around who had access to what. We provided some audit reports. We have a new capability around identifying rogue accounts and applications. We improve our group mastering capabilities by allowing you to take over management of groups and Box, G Suite, AD, so that you could centrally manage core IT manage groups and have those automatically synchronize to your apps.

In the near term, we have gotten a lot of great feedback around our access request workflow and we are working to close some of the gaps there including being able to request any app even if it's worth provisioning. Supporting manager approvals is part of that approval workflow. We know that that's a key requirement for a lot of customers. I'll mention the LDAP interface here in the context of that architecture shift that I just described. While we provision to AD and LDAP and allow you to synchronize to this directories, we're trying to help you simplify that architecture further by allowing you to connect some of those legacy applications directly to Okta via LDAP.

Of course, our lifecycle management product, a huge amount of devalue is around the integrations, around the directory integrations, the application integrations that drive that automation across the lifecycle. We continue to invest here in new HR integrations like SuccessFactors, new capabilities across those integrations like adding schema discovery. We are looking at improving the performance of our HR integrations by supporting incremental imports. A lot of work here to make sure that you're not building connectors and that for the top applications that are using your enterprise that you have a pre-integrated provisioning capability.

I want to just do a quick demo here. I'm not going to go too deep, but I just want to highlight some of those new EA features that I mention. The first one I want to show here is around synchronizing groups and some of the enhancements we've done there. We've always been able to take groups in Okta and provision them out to other applications. We are limited by only being able to create new groups and the feedback was I have existing groups in Box. I have a sales group in a marketing group and I want Okta to take that over. With push groups, you now have the ability when creating a push mapping to go into Box and say, "Do I want to create a new group in Box or do I actually want to link to an existing group in Box and take that over?"

What we are active here, my Wi-Fi works, is search through all the groups in Box, let you link to one and start taking over management of those memberships. I only mention some innovation around reporting. I wanted to just highlight a couple new reports that you can start using today. Looks like I got booted here, trying that again. We have some new reports that help you again audit that access and the assignment of applications in your environment.

If you go here, you have easy ability to look at any application that you've assigned to users and get a quick view of who is assigned that application and who has access. Some of the details here matter. You can see detail like, "Was that application assigned via group or role or was it individually assigned as a one of exception and by who? Or was that application requested and who are the approvers as part of that chain?" Some pretty table stay its functionality, but again, quick visibility into who has access to what.

We also now have a rogue account report which allows you to pull in account information directly from an application. You may have admins going around Okta and creating accounts locally in the application. You can pull a record via CSV of all those accounts, compare that to the access rates in Okta and we'll flag for you rogue accounts that maybe are not tied to an identity lifecycle in Okta.

I'm going to switch back to here. I want to switch gears now from employees to talking a little bit about our roadmap for the extended enterprise and customers. We, like I mention, are continuing to invest in those employee use cases, but our customers are telling us that managing the lifecycle of the extended enterprise, your contractors, contingent workers, your partners is often time a bigger challenge than your employee base.

As I talk about the extended enterprise and customers, it's also important to note that while we're building the solutions for IT, the lifecycle management product can also be used by to enable the line of business and your developers who are often the people managing these external identities. We want to equip the folks in the room on the IT and security teams to be able to manage these loosely coupled users to empower the business to maybe manage those identities on their own.

I'll dig into these in the same manner, starting with some of the pain points. The extended enterprise, your contractors, your partners, their lifecycles are not necessarily driven by HR. Even if they're in your HR system, I would challenge you and say, "Is there an HR business process actually going through and terminating those accounts? Who are the people in your organization who know when a marketing contractor should stop working or stop having access to the system?" It's not always folks in IT or folks in HR.

These extended enterprise users are not second class citizens. They're essential to helping your business move forward. In order to collaborate with them, your employees need them to have the same levels of access, the same levels of convenience that you have. We hear problems like orphaned accounts, new users going through manual processes and waiting weeks after their contract to start to get access. This is an additional load on the help desk of course.

The lifecycle looks a little different here for the extended enterprise. We have those core capabilities still on the right, universal directory or synchronization and provisioning capabilities, but the lifecycle and how you onboard that user is going to be a little different. You're going to need to support more self-service options, make those available to your partners, your contingent workers to quickly get up and running. On the back end of the access, because HR may not be driving that lifecycle, you need more automation to close that loop. Being able to suspend the access at the end of a contract date set that date when you create the user and then it's off your mind as an IT team. It gets cleaned up.

We're also looking into time and inactivity base suspension. When the user stops using the service, we can suspend that account. Because of all this automated suspension, we don't want to add too much friction to the user. You don't want your account suspended every 30 days when you're trying to use the service every month. We're looking at ways to provide self-service ways to extend your access to prove that you still are a legitimate contractor or a partner and be able to do that in a self-service manner versus going through the help desk.

Customers. Security and user experience and scale really take on a whole new meaning here with customers and I'll explain why. Your customers demand a whole another level of user experience. They are interacting with your brand. They're interacting with your services and digital experiences. They expect a consumer-grade experience. The scale is at another order of magnitude, I should say. You may have thousands, tens of thousands of employees, your customers will grow into the millions. Thinking about how you're going to manage those identities at scale and as automated a way or self-services of way as possible is critical just for survival.

Some of the challenges we see here on the security governance side. This is less about passing audits or compliance audits and more about making sure that the privacy of that user is honored. Another aspect to this is as consumer goes to register and get access, if that user is getting access to health records or going to make a financial transaction, how do you know and make sure that George is who he says he is? That's where identity assurance becomes an important consideration. In terms of user friction, making sure you deliver that single brand around identity across all your different experiences and I mentioned administration at scale.

Again, same products, same set of capabilities in terms of our directory, our integration, our policies, a slightly different lifecycle and on the front end, leveraging registration is the only way to go here with customers. I have conversations with IT teams about the customer use cases and they say, "I don't manage the digital experience team. We're not building that application." On the flip side, I'll say, "It's an opportunity for the IT teams to deliver identity as a service to their line of business, to everyone building an application or service or an experience inside your company. We want to empower you to be able to deliver identity centrally to your developers and the line of business."

We're doing that through a host of registration pages that can be a central way to onboard your customers. We'll be able to support multiple apps that are using your business on top of the same registration. We'll look into, again, those more secure consumer experiences, ways to integrate with proofing services and to support workflows that require verification during the registration process. Because you need to make sure that every touch point is a self-service as possible, we'll make sure that in the same way we deliver sign in and registration that we provide you the tools and the legos for your users to be able to manage your profiles and manage your credentials. Finally, terminating access means something a little bit different. You are less concerned about cutting a customer off every 30 days and instead thinking about account clean up. If they've been inactive for a year, maybe I want to recycle that identifier.

Our roadmap across the extended enterprise use cases and the customer use cases really starts with registration, self-service registration, which we demoed on stage yesterday during the keynotes. That's really our first step to thinking about building digital identities, not from a source of truth like HR, but building that identity in a self-asserted way. Expect that to be in beta in the coming months. We are looking forward to getting you all involved in that. Then, on the lifecycle side, again, we now support the ability to schedule suspension, to set a date to automatically suspend an account. On the roadmap following the release of that, we're going to start looking at inactivity and time-based triggers as well.

I'm going to jump back to my Okta word here and just show you those two capabilities, registration and scheduled suspension. If I jump back here, I know this is covered in a few other session, so I won't go too deep. On the right here, you have a login page and this is going to be very familiar to a lot of you who login and use Okta every day at work as an employee. What we've added to this is the ability to support registration and think of this as a site in front of your partner portal, in front of your customer experience or digital experience and something hosted by Okta in the same way that you login with Facebook, with maybe some of your favorite consumer experiences. This can become a central ID site for all of the applications and experiences that are used within your enterprise and by your business.

We got sign in and now we have sign up. As you can see, I can fill out email, first name, last name, a password. We enforce password policy. Just to show you how easy this is to configure, I'll jump over to the admin side and show you how this is enabled. This registration page is, again, sitting in front of my partner portal app and I have that app represented here in Okta as an OIDC app. With self-service registration, I can now enable registration. I can assign users to groups after they register. I can identify the fields I want the user to enter and whether they were required or not, and I have two options in terms of how to onboard that user. I can require that they verify their email address and walk through that email workflow before they're active, or I can send them right in. Again, remove the friction and handle email verification later.

I'll quickly show what it looks like to add a new fields here. I'll just add birth date, and I actually want to call this birthday in the form. When I save this, you'll immediately see that this registration page, if I refresh it, adds that field here as another field for the user to register. You see some requirements here around the password, and I'll show you how easy it is to manage that as well. Again, thinking about how lifecycle management works with our access management products. If I click here, I'll go and see the password policies that I currently have configured for this org. Registration uses Okta password policy to enforce user's password during registration.

If I go to this policy right here, I can go ahead and edit it. You'll see that this policy and the configuration matches what it is required of the user here. If I go and edit this policy and require a symbol, you'll see that that's now a new requirement in the password policy. Couple clicks to configure exactly what you need to register new users for your digital experience or your partners.

I'll jump to scheduled suspension. Again, you have these users with their loosely coupled lifecycles. They're not tied to an HR lifecycle. How do I make sure that their access is controlled? What I'm showing here are a list of users who are currently scheduled to be suspended tomorrow and on September 1st. This is a running list of folks who will be suspended automatically by scheduled suspension in lifecycle policy.

If I want to set this for another user, it's as easy as going to their profile in Okta, enabling scheduled suspension and setting in date and time and we'll make an API available to set this date if you want to do that programmatically during user creation. Now, all of your users are tied to a managed lifecycle. You have your employees tied to HR. You have contractors whose access is bounded by their contract dates, and you're not ending up at the end of the year with a list of a thousand contractors who still have access that may or may not have left the company.

Jumping back to the presentation, a few more minutes here and then I'm going to save some time for questions. I like to get up here and talk about some of the new big ideas and the big themes that we're talking about, but as a product manager, it's also important to remember the little things. The next couple of slides are about some of the nitty-gritty details and are continuous improvement of the product based on the feedback and usage from you guys. Some recent enhancements. We've simplified our matching rules and confirmation settings when configuring an integration with HR. We've added search to our applications page. Customers now have hundreds of applications they manage in Okta, being able to efficiently get to the right app and the admin UI is something folks have been asking for a long time.

This is just a view of those lifecycle settings. If you look at the bottom here, I now have the ability and this is a configuration for Workday. I have the ability to decide whether when the user is terminated in Workday, do I want to suspend them in Okta or deactivate them and have deactivation triggered the provisioning? I also have options now to reactive users as they become an active employee again in Workday.

Some in progress enhancements. We're adding to our people page. Now, this is very basic, the ability to add a user with a password. Today, when creating a service and account as an admin, you have to create an account, go through an email activation flow, do a fake email address. We're going to add just the direct capability to add a user with a password, and you'll have the ability to decide whether the user on their next login will be forced to reset that password. Just a nice little removing of friction there in creating users.

We're also going to support in UD user relationships. This is a big one that we've heard over the years whether that's for a manager, a sponsor, a parent-child. We're going to support the data model to link two users together and then use that in our provisioning, in our workflows for approval and for your custom use cases on top of the API. Also, in UD the ability to find enums, T-shirt size small, medium, large, rules, sales, marketing, engineering, whatever you need to help define a user's identity get them into the right roles. This can be define in both the Okta user profile as well as your app user profiles as well if you want to use that for managing entitlements.

We're going to be removing first and last name as required fields in UD. This is a big one for those customer use cases for our platform customers who again want a user to be able to register in as low friction way as possible, and that means not requiring them necessarily to enter first name and last name. We're constantly enhancing group membership rules. This is one of our most used features in lifecycle management for assigning roles, for automating, for birthright provisioning. We're going to have the ability to have a rule add you to multiple groups. This is just to reduce the number of duplicate rules you may have configured, take out some of that management overhead.

Hopefully, some crowd pleasers in there. Just some closing thoughts and then I'll open up to questions. I want you to think about lifecycle management as your core identity platform across employees, your extended enterprise and your customer base. Again, thinking of lifecycle management beyond governance and more focused on the four pillars we talked about today, lowering user friction, administration at scale, security first governance, and managing any user.

Just to leave you with a little bit of a flavor for where we're looking and where we're going one, two, three years out from now. We believe when it comes to lowering user friction that that's best achieved by making as much self-service as possible. You don't want to manage it in your help desk. Users want a low friction way to get access to manage their profiles and accounts. We also want to deliver consumer-grade experiences out of the box. The experience you have logging into Google and managing your Google accounts across all the different services, that's something we think we can deliver with Okta.

Administration at scale. Again, there's a lot that can be done here with automation through our integration, but it's also about driving workflows and manual tasks, providing more extensibility in our product so that you could integrate it in other workflows during the sign in process, during registration to extend the automation beyond what's automated in Okta. In terms of governance, more reporting not just on applications but on users, groups, roles.

As we think about investing more in governance, in the near term, we've had a lot of customers give us the feedback that they're successful in having Okta Lifecycle Management side by side with a governance product that they may already have. As we think about innovating in that space, we want to be thinking a little bit more about temporary access instead of persisting entitlements and assigning an application and meaning that that is something you have forever until we remove it. We think there are some innovation around more temporary access. I need Salesforce access for this project. I use it once and then it's gone. Again, that's where the power of the Okta platform and how our products work together can really be leveraged.

Finally, with any digital identity we talked today about employees, contractors, your customers, we are seeing a lot of interesting use cases around other types of identities, parent-child relationships. A user who is not only a student, but also a TA and an alum and how we manage that identity and eventually things and devices, again, managing a digital identity not necessarily a person, but a device or thing. That wraps up my presentation. We got six minutes left. I hope you guys got a lot out of that.

A little bit of the tactical of what's new, what can I go home and try today, things like scheduled suspension, the new reporting, our group synchronization enhancements, a lot of our new integrations like SuccessFactors, being able to automatically suspend accounts, registration. There's a lot we hope you can go home and try today, and we're looking forward to your involvement in our beta programs. I hope you also got a sense of where we're going, what lifecycle management means, what problems we're trying to solve both now and the future. Thank you very much. I'll open it up for questions. Any questions up there? We'll start over here on the left.

Speaker 4:  Thank you. You talked about lifecycle management and you gave like this old way, the midway, and the new way of how people are doing this and it's like, "AD hook up to the cloud and then some mapping, magic happens and so on."

George Kwon:  Sure.

Speaker 4:  It's a hard sale I think to infosec to be like, "Hey, let's move all of our access controls off of an enterprise system like AD." Then, you're talking about in the midway that Okta was eventually then going back in provisioning AD. I guess my question is with this new things sort of outlined, does Okta support in these mappings and things going back to those enterprise systems and provisioning that back up in AD so they're in parity?

George Kwon:  Yeah. I think if I'm getting your question right, AD is still a critical piece of infrastructure for our customers and it's not going away any time soon. What we've done though is provision new user accounts during that onboarding process into AD, into the right OU with the right attributes. We can synchronize a password. We even have customers who maybe aren't using an Okta password. We provision a user to AD. We still [inaudible 00:39:57] to AD. They have an AD credential. There are a lot of different architectures though that are possible, but fundamentally, we enable people to continue to use AD, but leverage lifecycle management for managing that onboard-offboard process for any of their users and if they choose also use an Okta credential and password, if they want to do that as well. 

Speaker 4:  The user object still can exist in AD, but the ACS they inevitably live in Okta then, right?

George Kwon:  That's right. They live in both places.

Speaker 4:  Thank you.

George Kwon:  I think there was another question back here.

Speaker 5:  I've got a little concern about the first name, last name suggestion about making that not required, maybe this is feedback in general. When removing something, are we going to get a heads-up?

George Kwon:  Absolutely. I want to clarify there. Today, first name and last name are required fields in UD and you can't change that. What we're adding is the ability to decide if you choose that I don't want first name and last name to be required. That's typically an ask of people building applications on top of UD and leveraging UD as identity store for their apps. Any other questions? A couple more? If that's it, I'll be up here in front if you want to connect with me and ask some questions in person. Thank you very much.