 Okay. Our next session, good follow-up from the previous one, now going beyond MVP, going beyond that minimal viable product. And to discuss that journey with us, please warmly welcome with me Aaron Perrecchi. And this is our Senior Security Architect at Okta please Aaron Kawano. Alright, hi everybody. Thank you for being here. I'm excited to talk to you about going beyond MVP, but before that, of course, must present the safe harbor slide to remind you that if there are any forward-looking statements, please base your purchasing decisions on generally available information today. But what you just heard was all about getting single sign-on working. So, of course, single sign-on is the minimum you need to get into enterprise companies. What I want to focus on now is what happens once you do that and what happens where that goes from there. So, single sign-on, the idea is you're going to have some sort of login box in your application. You're going to ask the user to type in their work email and go discover that company's IDP and do a single sign-on flow, hopefully open to interconnect. And eventually, you will end up with a user signed in. Now, you're going to have multiple different customers signing in to your applications from different companies, which means they're going to be using different IDPs. It's not just like signing with Google where it's all just one giant IDP. It's signing in with this customer's IDP, this customer's IDP. So somewhere in your app, you're going to need a list of an email domain at the company mapping to that company's IDP. So, let's say you have the example.com email domain and when somebody enters that address, then they are going to redirect over to that company's IDP, which let's say it's Okta, and then a different company is example.org, you'd redirect over to that company's IDP. Cool. That means in your user database of users in your app, you're going to end up with not just a list of users in one giant list, you're going to have to map them to that IDP. Ok, so you're going to get, you're going to go through the OIDC flow, get their email address, enter a user record in your database, which is IDP1 user at this email address. So you'll end up, you know, doing this as people sign in. And as users from a different tenant login, you're going to end up with a different tenant ID in your user database. This is all great. But quick side note here, don't actually use email addresses as the user identifier in your apps because email addresses are not necessarily stable identifiers. For example, you just change their name or a company gets acquired and the email address is changed. Luckily, when you do an OIDC flow, you do get back a stable identifier, which is a usually opaque string. It's called the subject identifier. And it will depend on the IDP, sometimes just a random string. Sometimes it is a username depends on the IDP. So that's great. You are now signing up enterprise companies left and right. You're getting all these users signing in through SSO. Wonderful. Your database is growing and growing. But you have now created a couple of new problems for yourself by doing this. SSO is great, but you've got a problem of deprovisioning and also incomplete the incomplete picture. And we're going to talk about these two problems. What happens when a user is removed from an identity provider? Well, one of the benefits of single sign on is that that user won't be able to log in to the app anymore. That's kind of the whole point, right? User gets deleted from the company's IDP. If they try to go do a sign in flow with your app, your app would do OIDC out of the IDP. That would fail because these doesn't exist there. Cool. They weren't able to sign into your app. But that also means that you're just going to never see that user ever again. You're never really going to know if they were deleted or if they just didn't, if they just stopped using the app. You don't really get that picture. Which basically means that in your giant list of users, there's going to end up being these kind of orphaned user accounts that just kind of just have a last login date of years ago, and you don't know the difference between they just stopped using your app or they were deleted. And this can be a particular problem if, for example, you are charging your customers a per seat license of how many users are using the app. Well, how do you know how many to charge for? Were they just inactive that month? Should you remove them so that you stop charging them indefinitely? And that's kind of just a missing, a missing piece. And the other problem is that you don't have the whole picture. You only know about who's logged in. So what about users at the company who have not yet logged in? And a reason this might be important to you is, let's say you're building like a to-do list app. And you want to make a little, you know, assign field, assign a task to a user. And you want to have it do, you know, autocomplete, type of head search, or whatever. So you want to know who are all the users at this company that this user who's logged in can assign a task to? Where is that user database? Well, it's not, your database is not a complete list of users at the company. It's only a list of users who've signed into your app. So how do you get that information? And these are the two missing pieces if you only implement single sign-on. So let's take a look at how to solve this. And that is where skim comes in. Skim is an acronym for system for cross domain identity management, which sounds like a mouthful because it is, because it kind of got renamed, back renamed style. But anyway, this is a protocol that syncs users between two systems, usually between an identity provider and the applications that are being used through that identity provider. To talk briefly about why skim is valuable before we get into how it works, I want to introduce Brendan Edelson, virtually, CTO of Zoom, to tell you about how skim has helped Zoom win enterprise contracts. SSO is a vital tool for integrating Zoom's platform with identity providers such as Okta. But SSO support only provides user authentication, not user management. That's where skim is valuable for Zoom and companies that use Zoom. When a new company signs up with Zoom, our skim support enables them to bring in all their users automatically and keep their profile information in sync and up to date. No more manual data entry or upkeep. Our customers can hit the ground running with Zoom on day one. It's important to note that skim support is not just a nice to have feature. It's crucial to winning enterprise contracts. Enterprises often have hundreds to even tens of thousands of users and manually managing those user records on even one platform can be daunting and time consuming. Furthermore, user records falling out of sync can result in various disruptions to the business, leading to lost productivity and potentially even security breaches. By offering skim support, Zoom demonstrates its commitment to delivering happiness by leveraging industry standards to make these tasks as smooth as possible for enterprise customers, saving them valuable time and resources and minimizing the risk of costly disruptions. Okay, thanks for that. Let's take a look at a high level of how skim actually works to make this all come into place. Basically, what's going to happen is once you've configured skim to go between the customer's IDP and your app, things will just kind of start happening behind the scenes. And what's going to happen is the IDP will just start sending requests to your skim server to manage those users. It'll do things like check if a user exists. If the user does not exist, it will go create the user. As users are deactivated and or activated again, they'll start making requests to tell you about those events. There's other things like if the user updates their profile information, you may get an update saying, oh, now this user's name is different or their role is different, things like that. So essentially, once you've stood up this skim server, it'll just sort of start being their handling requests and telling your app about all of the users at this company. So let's, in the case of Okta, this is from the Okta documentation. This is kind of the first thing that you'll see is Okta will ask your application, does this user exist? And it'll make a get request. It'll say filter on username as this user. And what your app is supposed to do is respond, yes or no. Basically, return a list of users that match this query or say no, there are no users. If you say no, there are no users, it'll then create that user. It'll create the user by sending a post request with that user's full profile information. There's lots of things behind the scenes of how the customer can configure mapping, the different attributes between Okta profiles and what your profiles might look like if field names are slightly different, but that's all something that the customer can configure. So you'll get this post request and then, all of a sudden, your application now knows about a user that hasn't yet logged in to your application. There's other operations that might be sent. This is, again, the list from Okta's side, things like check if a user exists with that query, create a user in your user database, get a list of all users in your database, retrieve a specific user by their user ID, update a specific user's attributes in case of a name change or role change. Users activated will send a different request with flipping that bit. The skim spec itself is very, very large and defines a lot more different kinds of things that happen to users, but in practice, there's actually a much smaller list that you need to actually worry about, and it will differ between IDPs. So again, this is just a list from Okta, but you may have to add a couple extra methods to support other IDPs. So, once you've got this all set up, now you have two different ways that users are created in your application's database. One will be the sort of just-in-time creation as the user is logging in, and maybe they don't exist yet in your database because the skim server hasn't notified you about it yet, but as long as the IDP says that the sign-in was successful, you should go and create that user record in your database. And then the other way is through the skim events of just pushing new user records. So you've got two different methods feeding this in, and what this does is it gives you the complete picture of users so that you can actually get these little assign a task dialogues to work, where you now do know about all the users at the org. And of course importantly, you know in real time when a user is deactivated because you'll get that event before having to just sort of wonder if they stopped using your app or were deleted. So there's a lot more to resources available to learn about how skim works or how to implement it in your apps. There is a great video on the Octa Developer YouTube channel that talks about the details of more of the details of these requests, so definitely check out that. And we also have an upcoming workshop to talk more about how to actually integrate skim into your apps. So customers like skim because it helps them better manage access to apps in their org, but skim also helps your apps work better by knowing more about the customer's organization. Speaking of things that customers also like, they also really like Octa workflows. I'm not here to sell you on why you need to use Octa workflows, but I want to tell you about how your customers use Octa workflows and why they like it and how you can take advantage of that. So Octa workflows is a no code, low code automation platform. It gives the admins a way to do drag and drop configuration of creating actions and things that manage, help manage their apps. It's all based around events and functions and actions. Basically, it's a way to connect any API and let coders or non coders build experiences around identity within their organizations. And it's basically a way to let people beyond developers actually build new experiences for people at the companies. In Octa workflows, there's a lot of out of the box integrations available for admins to plug things together. So some of the examples of plugging things together basically is replacing custom code and even manual tasks with all these automations. So things like when a new user is created, maybe you need to go and do a few actions in a couple different applications that the org might be using. Moving users between groups or assigning apps might trigger certain other events. So it's also a way to perform deep actions inside of an app like assigning a region and sales force or in Slack, adding them to certain channels. The whole platform is based around events. So events could be things like a new user is created or a user enrolled in MFA factor. Maybe you want to do something at that point. And a user is assigned an application or if the org rate limit is exceeded or even it can be driven by events that happen in your apps. So these are all events that Octa admins can be using to drive experiences with other apps that they're using. Enterprise customers like workflows because it lets them replace custom code with just drag and drop actions. It also means they're not running servers to maintain all this code running. It's all happening in Octa workflows. It also means that IT admins rather than developers can actually create these things. And there are lots of out-of-the-box integrations available that connect common applications that are often used together. So how are Octa admins able to create all these complicated workflows without writing any code? And that's because there are what are called workflow connectors that know how to talk to the APIs available in those apps like Box and Slack and Office 365 and maybe your applications. So let's take our to-do list app. What happens if you wanted to be able to let Octa admins create automations for your applications? Well, you would create a workflow connector to expose parts of your app's APIs to let the Octa admins create these automations. So a connector, it's a way for workflows to connect into your applications. It has actions and it has input and output parameters. You define these blocks and then they're able to connect into the other blocks and workflows. You can essentially create a connector to expose your app to Octa admins using workflows and you do that by exposing API endpoints that you're writing. So think about the common API endpoints that might let admins expose useful features of your apps to the rest of the company. That could be things like create a to-do item or mark a to-do item as complete or update an item or get a list of all completed items. And even just with that small list, which is maybe not your full API, but even just putting those few actions into workflows will let them create a lot of really interesting workflows. Like every Friday at 5 p.m., it can get a list of all the tasks completed within the last week, then email to a list. What did you have to do to be part of this? Well, you just have to write an API endpoint that says get all completed tasks within a week. You don't need to worry about how it gets sent over email or what email provider that admin is using. Or if a customer opens a Zendesk ticket from your system, send a notification to Slack, create a new task in this to-do list app. So now your customers can create these automations without writing code to do all this. So basically it's letting your customers use your products more effectively. You can even have workflows trigger other events based on things that happen in your application. So like if somebody completes a task, your to-do app can fire off an event inside of workflows that let other things run. So you can really see how you can let your customers enrich their whole experience by driving these from events in your apps. If you have a lot of common cases that you've found your customers using, you can turn these into templates. And that way they're just like super quick for customers to install. And there's a handful of these already available in the workflows catalog, which you can check out if you're curious to see some examples of how other customers have done this. So basically help your customers get more out of your apps by supporting workflows, by adding the connectors for it and figuring out what API endpoints you need to expose to enable these kinds of rich experiences. We have a YouTube channel with lots and lots of tutorials about how to do this. And there's a link here on the screen, but the QR code is also easier to scan version of that link. Lots of information there. And again, we do have upcoming workshops to talk about how you, to walk you through adding actually, adding this to your applications. So a few upcoming workshops, we're going to go through adding Open ID Connect to your apps, getting users signed into your apps, using Open ID Connect, syncing your users with SCEM, enable automations with workflows, and also automating octa management using Terraform. Thank you all very much.