Transcript
at Okta. Today, we're going to dive into the topic of delegated administration. And this is a very important use case to us because a lot of our B2B customers look for very optimized and effective ways to essentially delegate control to their customer admins. So allowing their customer admins to manage users, manage user life cycles, be able to control access, control access to applications, and so forth. Now let's dive into a little bit of history in terms of the evolution of Okta Dell Admin and how some of our customers have used very standardized patterns or designs to solution out a way for this particular use case. The first one is a single or using multiple groups. Now this is implemented using a single Okta org with a wide varying degree of the number of groups created. The idea is that each group is used to represent a respective set of users. So whether it be for a specific customer or a specific partner, these groups are used to logically separate customers within a single Okta org. It's also very important to note that isolation controls, so being able to really institute the layer of security needed to separate out these different user populations, would all be contained outside of Okta. Now evolving forward, there is the alternative solution of using multiple organizations as well. So in this case, a specific B2B customer or partner would be represented by its own Okta org. We do have the capability of creating Okta orgs via API, so being able to stand up an Okta org via API, each respective customer or partner would have its own set of resources, users, contained groups, policies, all of it contained within the Okta org itself. So this is completely siloed, and the respective customer or partner would be responsible for managing their own separate Okta org. However, one thing to note with this solution is there are hidden complexities that do arise, which led us to kind of think about what are the next steps for delegated administration. And this is where I'd like to introduce Advanced Directory Management, or ADM. As part of the Okta Identity Governance Charter, we have provided the solution that is introducing this concept of a realm. So effectively enhancing the notion of universal directory, one Okta org, and extending it so that each customer or partner is now represented by a realm. And all of the security controls in place would be represented as rules or policies so that each respective customer or partner is logically separated and isolated in regards to how they're represented within the Okta org itself. Now let's dive into how and what the makeup is in terms of what each of these institutional designs look like when it comes to implementing for Okta Dell Admin. Now the first one, again reiterating that the single org, multiple groups implementation is as it sounds, right? You have a single Okta org with all the necessary resources contained within it. We have the applications, policies, authenticators, identity providers, and then we have the groups. Now the groups are going to be used to represent each of the different customers or partners in that B2B scenario. You can see here in the image that we have the ACME and the labs users and admins, and then we have the ATCO admins and users, which would sort of represent the overarching entity or the actual initial parent company, if you will, that is providing the services. Something to note is that groups provide a very low degree of separations, all logical, right? Anything that has to deal with security controls would have to be extended outside of Okta and implemented using custom code, maybe through a custom application and integrated with the Okta platform. In addition to that, again reiterating that any necessary security controls would have to be implemented outside of Okta, and this is very much mandatory, and which translates to quite a bit of a level of effort when it comes to building the application layer outside of the Okta domain. And inherently, there is this added complexity when it comes to considering an implementation using this path forward. Now moving on to the multi-org solution where we have one Okta org per customer or partner. As it stands here, we have a simple diagram outlining the parent organization being ATCO or the service provider connected to two additional Okta orgs. The first one we have on the bottom left, which would represent the ACME B2B customer, and then we have LABS, the other B2B customer. Notice how they're both connected to the parent as well, such that any member of the parent organization can SSO directly into the child organizations to be able to manage users, configurations. Think of the ATCO admins as more of like the super administrators. So in the event that they need to maybe provision something or grant overall access to resources, they do have that capability as well to potentially act on behalf of the B2B customer admin. So that's why you're seeing those arrows connected from the application layer within the parent organization that is ATCO down to the ACME organization and the LABS organization in the identity providers section. But ultimately, think of it as you have this central parent organization, which contains the super administrators, the parent users. Those super administrators can also administrate the child organizations. The child organizations would be representing the actual B2B customer themselves, which in this case is ACME and LABS, who they themselves will also have administrators that can provide capabilities to manage their own users. For example, you'll see ACME admins. Those admins can manage their own users, their own applications, their own policies. Each of these organizations is completely isolated from each other, completely siloed. That is what allows us to effectively implement for any data residency requirements, such that complete customer isolation is necessary. So a couple of pointers here, again, reiterating the point that this is very much the most viable solution when it comes to mandated or mandatory physical customer isolation. And one call out here is right now I only have two child organizations connected to the parent one. However, in the event that let's say I have 100,000 B2B customers, so 100,000 ACME and LABS, how does this scale? The amount of overhead associated with this is mind-boggling when it comes down to the number of groups, maybe applications, policies, authenticators, essentially all the resources contained within the Okta.org itself would be multiplied. And the inherent nature of the complexity is very mind-boggling when you think about it because again, all of these different resources are going to have to be replicated. And for the parent organization admins or the super admins, they aren't going to be able to keep up with the propagation of these resources in a scalable fashion. And that could sort of lead to the notion of, hey, if my organization only needs simple user management and delegated admin tasks, inclusive of maybe letting our B2B customer admins manage their own groups, their own very high-level policies, access to applications, this could be very much overkill when it comes down to the implementation path, which led us to, again, reintroducing ADM or Advanced Directory Management. And you can see here, introducing the concept of realms, back to the simple use case of just delegated admin tasks, like being able to manage users, user lifecycle, journeys, application access, et cetera. We can contain everything back into a single Okta.org and essentially facilitate the division of these different B2B customers in the form of a realm. So within the realms that you can see in the diagram, in the beige diagram there, we have the two realms for both the ACME and Labs B2B customers. They are represented by subgroups to kind of help organize between maybe general users and administrators. And then they're also tied back to their own identity providers as well for SSO. Now within realms, we have the ability to select the identity source or sort of the profile source, if you will. So that's where the identity providers come into play. So any particular user that's coming in through maybe ACME SAML or Labs OIDC, they can automatically get propagated into that respective realms through dynamic realm assignment. And we can also have group rules defined to support dynamic group assignment as well. But realms is effectively the ultimate player here controlling the different segmentations of customers. The biggest, I would say, aspect I do want to point out would be the inclusion of what we call a partner portal within the Okta platform. This allows us to effectively delegate quite a bit of control to our B2B customer admins. So these are essentially Okta-hosted portals that can be created when a specific realm is set up. So for example, we have the ACME realm. That has its own partner portal provisioned where an ACME administrator can go in and only see their own users and their own groups and their users' group access, application access. They can manage their own users, their own users' group access, application access, lifecycle. They can kind of go in and manage anything that's pertinent to their respective realm and vice versa for the lab's users as well. So this is a very powerful tool, but it kind of keeps things into perspective as it relates back to the multi-org solution. We want to contain everything within a single Okta org and really provide that simplified respect when it comes to Dell Admin. Now a couple of pointers here, reiterating the idea and the notion of delegated control to our B2B customer admins with this built-in sense of simplicity. We're kind of going back to the basics here with a single pane of glass view. So we don't have to manage multiple organizations and sort of that propagation of different resources within the organizations themselves. And then if in the event that we do need any sense of data residency, we can combine it with the previous multi-org design system as well. So let's say we have a customer with 100,000 B2B customers and they're divided by different regions. Now, instead of having 100,000 separate Okta orgs, maybe we can distill that down to two different Okta orgs, one provisioned within the US and then the other provisioned in our EMEA cell. Now, contained within each regionalized cell, we can now have X number of realms created in each organization to be able to implement this Dell Admin functionality in a more streamlined perspective. And it's important to also note that kind of tying back to the previous point, ADM is not necessarily a silver bullet. So we'll probably have to get a little bit creative at times when it comes to meeting all of our different compliance requirements or implementation requirements as it pertains to lines of business. But at the end of the day, the goal is to be able to provide this simplified, delegated administrative control so that, again, our customers are able to streamline the way they think about Dell Admin as it comes down to implementing with the Okta platform. So without further ado, let's go ahead and take a look at the advanced directory management demo so that we can take a closer look at the visual, how it's represented and how it's effectively implemented within the Okta platform. Okay, great. Now that we're at the Okta Admin console, logged in as Atco Admin, now this is very much representative of the diagrams that we were taking a look at earlier. We will be driving the sort of administrative tasks from the perspective of Atco Admin for now so that we can take a look at how it's represented and set up within our Okta work. Now let's take a look at the directory. First and foremost, the realms component as part of the Okta platform. We see that we have the Acme realm and the Labs realm pre-created to be representative of the B2B customer. And then we also have realm assignment conditions written here. And you can see here previously when I was talking about dynamic realm assignments, we're able to leverage these so that we can effectively tie it back to a condition. This is very preliminary and very much kind of brute force, but essentially I am able to auto-assign users to a specific realm based on a particular attribute matching. So right now I'm just kind of tracking based on the first name because I have defaulted based on the demo itself. But if I wanted to, I can do maybe the login, I can do something a little more complex. Maybe kind of say, hey, if the login or the email contains a particular string value, then let's go ahead and auto-assign them to a specific realm. And we can also see and track different assignment completions. So you can see here previously I did run these assignments so that we can get the respective users assigned to their realms defined here. Now taking a look at the ACME realm from the context of the ACCO admin, you would suspect that as the ACCO admin, I am pretty much the super admin, so I should be able to see users in both of these realms. So if I were to click in ACME, we'll see, yep, I'm able to see that the ACME user and the admin, they're contained within this particular realm. Now if I navigate to the labs component or the realm, I can also respectively see those users defined here as well. Now if I take a look at the groups, you'll see I've pre-created these groups. So we have labs users, admins for labs, ACME users and admins, and then same for ACCO as well. And then taking a look at people just to verify, yep, I can see all of the users defined here. From ACCO's perspective. Now one other thing I do want to define and show would be identity providers. This is where we can define IDPs to facilitate SSO. So when we are creating a realm, for example, let's just kind of go through the process here and let's say I wanted to create a temporary realm. We can include a domain, so making sure that only users with this email domain can belong to this realm effectively, as well as creating a portal so that partner admins would be able to manage users in that respect as well. So if I were to create the realm, we can see here, I don't have any users in this realm. So relatively straightforward, however, now let's go ahead and take a look at this from the ACME admin perspective or one of the B2B partner customer admins perspective, essentially. So no longer from the POV of the super admin, that would be ACCO admin. So if I were to sign out, and then now let's log in as ACME.admin. So again, now I'm trying to log in as the partner administrator. So I can show you what that experience could look like. Redirected back to the end user dashboard. We have this neat handy option here to select to navigate to our partner admin portal. And now we're opened up and shown the partner portal, where as the ACME admin, I can only see the ACME realm effectively, or represented here as the partner. And as the ACME admin, if I click on ACME, I can see these are the users that belong to this respective realm. That's perfect. And as the ACME admin, I can actually go in and reset the user's password and also reset their authenticators, multi-factor, clear sessions, all of which would correlate to the Dell admin capabilities and tasks that are very much pertinent to that particular use case. And you can also see, I can see the application access, unassign if I would like as the partner admin or the customer admin, right? In addition to that, I can also take a look at the groups that this particular user belongs to as well as unassign them from the groups themselves. One final thing I do want to show is for this particular user as the admin, I am able to edit their attributes as well, whichever are allowed. And just taking a look, these are the different attributes that I can edit on behalf of this user as the admin for this respective realm. Now, if I were to log out, and this time, let's try to log in as labs. So the other, right, customer or the partner to see what essentially from this POV I would be experiencing. Now, very similar to how the experience was for the Acme admin, as the labs admin, I am only able to see the list of partners represented as labs. So if I click on labs, these are the only users I can see with respect to my own organization, right? And then same deal, the different controls that I have and the different actions that I'm able to essentially partake in, same deal, reset password, reset authenticators, I can suspend the user, I can go ahead and unassign the user groups, and then also edit the user profile as well. So this is the partner portal that I was referring to that's very powerful, that we can leverage out of the box within the Okta platform, it'll scale with the number of realms created within the Okta platform. One thing to note is currently in a single Okta org, we can have up to 5000 realms, but that doesn't necessarily preclude us from supporting use cases that maybe need 100,000, maybe separated, you know, environments or portals, right, effectively, we can kind of drop down that number. Instead of 100,000 separate Okta orgs, maybe we can have 20 Okta orgs, each one with up to 5000 realms. You can see the simplicity that's sort of embedded with that approach and kind of taking it down so that instead of having to manage 100,000 separate Okta orgs and the complexity associated with this, all we have to do is maybe manage 20 and sort of maybe automate that as well, right, automate that process and provide logical separation within each Okta org using ADM through realms, through the partner portal, through policies that are provisioned as well, and also combined with our APIs and potentially Terraform if we prefer that avenue. A lot of ways to optimize the process that'll sort of streamline and rethink how we implement delegated administration within the Okta platform. I do appreciate the time, thank you so much, and if there are any questions, let us know. Happy building. Thank you.
