 Good morning everyone and welcome to this talk on how to make your SAS app more secure with less work and go beyond SSO. I have a fun skit for you this morning to wake us up and energize us, but before that let's go through our safe harbor slides. So please read this note on forward-looking statements we will be making in this presentation. And also in Japanese, and then here is a disclaimer for the fictitious use of orgs I will be using in my fun skit today. So to join me in my fun skit, I'm going to call upon my colleague and angular rock star, Elisa Duncan, come on to the stage. So I will be playing a SAS company CTO called Streamward, pitching my amazing to-do app to a music industry CEO of Atco Pop Records, Elisa, and playing the enterprise company Point of View, and you my audience will be playing my SAS developers, playing the Point of View of the SAS developers. So bonus points to you if you really are a SAS developer. So here we go, Atco Pop Records, in 2021 you had $9 billion, you brought home $9 billion, you managed 10 record labels, and within those record labels you have multiple bands and employees. How impressive. You brought us the best K-pop band ever, BTW, and Sunshine, who could forget her, and the best number one hit song today, The Roses by Old Jeans. Thank you, Atco Pop Records. We at Streamward see your success, and so we want to support you with our latest product. We know you're busy creating events and concerts and you need some way to manage your day today. So we have this to-do app conveniently for your use, and let me tell you more about it. It's an easy-to-use task management tool. It has secure authentication with the trusted, secure identity providers like Okta and Auth0, and it even has AI to generate your to-do list for you. So all you have to do is wake up. What do you think? That sounds amazing. What an awesome to-do app. I know that my employees would love working with this, as they are so busy creating new songs and keeping up with our bands. Thank you for mentioning BTW. Aren't they awesome? They're about to launch on yet another world tour. Can you believe that? They're just so busy and so popular, and I love that your to-do app integrates with Okta with SSO, which will make things really seamless for us and make sure that we have great levels of authentication. Mentioning BTW, though, and their world tour, how we operate is that for every location that we have our concerts at, we hire project managers to help manage things there and to make sure everything goes okay, and we do this on a contract basis. So what that means for our IT admin staff is they have to onboard a whole bunch of new employees, and that has to happen immediately because you've got to get a head start, right? And once their contract ends, we have to make sure that they no longer have access to our act-go-pop systems. Of course, they'll need to be added to all the productivity tools that our employees use, including our HR application, time management, as well as this awesome to-do app. So that leaves me with a problem. I'm reluctant to bring on new applications because it is a lot for my IT staff to manage. Not only will they have to bring people on quickly and onboard them, but if anything changes with their user information in the meantime, they have to do so manually across all the different systems they use. And then, of course, at the end, we have to make sure that they don't have access anymore, and my IT staff just cannot keep up with that workload. Do you have anything that can help me with this problem? So what I'm hearing is you have a fast-paced, growing, successful company, and you need a SaaS app that can keep up. You have users all over the place and experience delay with adding users and getting them onboarded. That's because your IT team is having trouble adding, updating, and removing users. The last one being a security issue because you need a way to revoke access the minute they leave. We don't have a way to do that, manage users in our app just yet, but let me talk to my developers and see what they can do. All right, so Elise's part is done. Please give her a big round of applause. Meanwhile, I will continue to talk to my SaaS developers. So now, you heard it yourself, a CEO is reluctant to close a deal with us because we don't have a way to manage our users. How can we fix this? I did a quick Google search and I found a solution called skim. It's a system for cross-domain identity management and it allows us to skim through our users throughout across domains. That was a pun. It's kind of early in the morning, but who has heard of skim? Raise your hand. Whoa, a lot of you. Okay, well, for those, we're going to do it together. We're going to learn together. It's an open standard protocol. It's designed and managed by the Internet of Engineering Task Force. Sounds like a very serious group, but this means that it's not a proprietary protocol of any one identity provider or company, not even Okta. And its whole goal is to reduce the cost and complexity of user lifecycle management. This is exactly what we need. So let's do a quick overview on how skim works. So on one end, we have this skim compliant identity provider, also called the IDP, also called the skim client. It's the one making the request to our skim server. So as it provisions a user, we confirm that we added or stored the user on our end and then we respond back to the IDP confirming that. At the same time, it could be talking to another application separate from our own. It could be another work application that Atcopop employees use. But the main thing here is the IDP can communicate to multiple servers at the same time. And this is all made possible by skim, the skim protocol standardizing the communication between the two parties. And so what this means for us is or how it helps Atcopop is that it centralizes users for for Atcopop. And then it helps with managing IT user lifecycle, IT managing user lifecycle management. So lessening the workload and lessening duplicates. And then for us, it's interoperable so we can make use of the information being shared and maybe even add role based access if needed. And for our users, it would be a seamless experience because the minute they join and log in with SSO, they already have a user profile and our app will be aware of it and they would be able to log in and give us feedback the minute they use it. For both sides, it adds security. For Atcopop, it deactivates users the minute they leave the company. And for us, we don't need to manage users at all. It's all handled by the IDP. So now you might be wondering, can skim scale with us? Let's take a look. So if we can support multi-tenancy on our end and if the IDP can support multiple applications, Alisa mentioned that Atcopop uses Okta, we can go pitch to other companies who also use the same IDP. And if we support other skim-compliant IDPs, we can also pitch to those companies. Just like that local construction company that just won that deal, we could pitch to them. So bottom line is skim would not hinder us in scaling. It would support us with our current and future customers. So now let's get to the fun part. What do we need to set up on our end to enable communication? To enable communication between both parties, we need these set of restful API endpoints. This is what's going to allow creating, reading, updating, and deleting users. What's interesting is that skim has its own expression language, and so we can filter for specific users if needed. And to each of the URIs, we must add skim forward slash, letting us know that this is a skim endpoint. We can also add V1 or V2, with V2 being the latest version. The protocol also talks about different authentication options, because we really want to protect our precious resource info from random use and anonymous access, and OAuth 2.0 being the most secure. And then there's the content type. Whenever we receive a request from the IDP, the protocol says we should accommodate for the content type set to application skim plus JSON. We normally see just application skim JSON, but we need to remember this, write this down somewhere. So now you're wondering what is the information we're going to be sending between both parties? So the protocol also talks about how to represent a user, or also the user schema. So the first three listed are the core attributes needed for any resource type. So skim has let us know what resource type we're using. In this case, it's user ID would be the global user ID that we have on our end, and meta is when we created and last modified the user. The first three plus user name is the minimal required attributes to represent a user, but that's not enough. At copot might need more attributes, so there are additional attributes that you can use that the protocol states. You skim is also extensible. We can add to the core group information, such as what part, what group they're part of. And we can also extend the user core for enterprise related attributes. Say we want to know their manager info, their department or employee ID. Here are some attributes that are specific to identity providers. Some identity providers may want an external ID to ID the user on their end. And some use an active resource attribute, just wanting to know the status of the user. So for example, say at copot really likes a contractor and they leave and wants to hire them full-time at a later time, they can reactivate their user profile. All right. So now let's take an example integrating with octa, a skim combine identity provider, and let's see how that works. So when an ad copop admin assigns a user to our to do app, this is what's happening in the back end. Octa first sends a get request with a filter in the query programs to check if the user exists first. If the user doesn't exist, it sends another request, a post request to our endpoint creating the user. But in the instance where the user is inactive and you want to reactivate them, it sends a patch. Let's talk about the expected attributes that octa wants us to store. So again, the first three are the attributes we already would have on our end. And then username, first name, last name, email, external ID and active are all attributes octa expects us to store. Now let's take a look at it from a JSON payload. At the top we have the attribute schemas. We know what that is. It's defining the resource type. In this case it's user. And then the highlighted ones are all the attributes that octa asks us to store. And then the additional ones are optional. And then together when we confirm that the user has been stored and added to our server, we give a response back to octa saying we've added the user. Here's its ID on our end and meta. And this is a full representation of a user. So to recap, what do enterprise companies look for in sass apps? They want a sass app that's seamless, that can integrate with existing services. For example, octa provides sso and is also a skim compliant IDP. They want to be able to know who has access to our app. So centralized. And they want an app that can handle automating user life cycle management, adding users, updating them, deleting them. With the last one being a security issue, as we need a way to revoke access from users the minute they leave. So with that, that's how we're going to get our to-do app to be more secure with less work using skim. So my developers, are you ready to build a server with me? Let's go do this and win at copop. Thank you. So that's the end of this kit. But I'm serious about building that server. But before that, I want to mention that we at octa have a hackathon. It's AI and identity themed. And participants must build a web or mobile app that uses AI and implements all of the following. Open ID connect or OIDC, skim, what you've learned today, using octa and auth zero. So you can take a quick pick of the QR code and first place or is a reward of 10k and a guest appearance to the octa dev podcast, our octa dev podcast. So again, let's go build that server. Workshop session today is going to be at 115 third floor at the grand ballroom BNC. Thank you.