This video is number twelve of the Zero Trust Authentication Master Class series.  

Transcription

I'm Jasson Casey with Beyond Identity, and you're still watching. So now let's talk about scale. So there's two parts of scale that we're going to talk about, scale-down and scale-up. So scale-down really is more about...let's say you want to try this out, but reasonably so, authentication is a critical part of your business, right? 

Your workforce depends on being able to successfully log in every day to get their job done, effectively, to help you make money, assuming you're a business as opposed to a government, but still, you want your people to be able to log in successfully every time they try it. So when you try a new technology, you don't want to try a technology that forces itself upon everyone in your organization right at one go, right? 

You need an ability to kind of start small, check things out, get comfortable with it, not just from a technology perspective but from an operational perspective. So when we talk about scale-down, that's really what we mean. And there's a couple of different patterns that have emerged there, and we'll just kind of talk about how we support that. And here we go. So just to remind everyone, like, every organization has some constellation of applications that, you know, your happy little workers need to access. 

Oh, I might have drawn it off-screen. And you know, they're all coming to these apps, right? And so these apps can be things like Slack. They can be things like O365. It's just your cloud apps or even premise apps, for that matter. 

There's almost always, behind these apps, some form of IDP, right? So some trade names that I'm sure you've heard of, Okta, right, Azure AD, Ping, ForgeRock, etc., right? And then there's probably an identity directory. 

And maybe this directory is kind of really part of this whole complex, and this is kind of where all the information of your people live. There is a federation between these applications and your IDP, usually in two different ways. So the first way, right, this is the delegated authentication protocol. 

It could be SAML, could be OIDC, could be, like, a form of OAuth plus some legacy API calls, could be WS-Fed. There's actually a couple of different ways that you can kind of integrate there. But then there's also usually some form of identity lifecycle protocol that's happening up here, right? And the most common protocol that you may know about is called SCIM, right? 

It's kind of an out-of-the-box protocol that every time you add an employee in here, the protocol will propagate and makes sure these applications know how to handle that employee the next time that employee tries to log in. There's also another flavor of it called Just in Time. Again, I cannot smell... 

I can smell, but I can't spell. So Just in Time. And Just in Time is the idea that, well, maybe I don't have to tell this application when I added a new employee. The application is always going to come back to me when someone tries to log in, and if I have someone new, then I'm just going to say yes. And so the Just in Time rule is anytime someone authenticates and it's the first time the application has seen it, construct that new user in the application. 

So a lot of applications use this JIT style. The downside with JIT is it's not full lifecycle. So when we say full lifecycle, remember, you know, we have birth, right? A new employee came into the system. We have, you know, mutation. So mutation is, like, the employee with a third arm, the employee has a change in privileges, a change in rights, that sort of thing. 

And then we have death, which isn't really that bleak. The employee just moved on to a bigger and better job somewhere else. We need to take them out of the system. The unfortunate thing about Just in Time is Just in Time just handles this, whereas SCIM handles all of this. Now, why did I take a detour into provisioning before I talk about scale-down for us? 

The answer is actually pretty simple, because you kind of need to understand this to talk about how do you try out Beyond Identity in a fairly low-risk way and really just identify, you know, maybe just one app or just a couple of users or a couple of users with a couple of apps, how do I really limit the population that's going to try this out so we can, you know, not just get a technical understanding of what's going on but get an operational understanding of what's going on. 

Well, the Beyond Identity service integrates... Actually, let's use a different color, just for some contrast. Here, we support all these protocols, but if you use OIDC, you're just better off. It's a more modern protocol. We will also integrate here using SCIM. Turns out, not everyone in this list, shame, shame, implements SCIM properly. 

So we also have some custom API hooks for those naughty vendors as well. But the reason for all of this, so when you turn these up and you start provisioning users in your directory, we'll actually learn about them. Now, how do we actually limit things? It turns out, in almost all of these systems, and the method differs, but the capability is roughly the same, you can actually choose by user, you can choose by group, you can choose by application, or really kind of any combination of these things, a subset of the population to send over to Beyond Identity for authentication, right? 

And so this is really kind of a configuration of the IDP. So for instance, in Okta, this integration right here, this is called delegated identity provider, and Okta, generally, there's a couple of different... 

You know, as with most products, you can accomplish one task in a couple of different paths, but in Okta, you can create a routing rule that basically says, "I want you to switch this user to Beyond Identity when they try and log in if this field is set." Now Okta's directory has fairly extensive arbitrary attributes that you can add, right? And so, if there's an attribute in there that says BI, it will effectively get routed to BI. 

And you can control how that gets set. We can also control how that gets set if you have us configured in "only when these things get provisions should that user get moved over into Beyond Identity." So this is a really easy way of, essentially, just carving out a small subset of the population to experience the product and get some sort of operational legs and functional legs. 

So next, we're going to talk about the other side of scale, right? Like, clearly, if I have a hard time servicing 20 users, we shouldn't be talking. So scale-up is the more interesting part, right? How do we try and ensure low latency? Because latency directly contributes to the happiness of this group over here. 

And if you're like most people, you care about their happiness, right, because, you know, unfortunately, security folks, we've kind of got the reputation of ruining people's fun times. If we can get them into their apps faster and sooner without them having to actually worry about passwords, without them having a risk of ATO or phish, a man in the middle, we're actually going to give them a better experience. 

We're actually going to simultaneously improve our security posture while actually making users a bit happy. So that's kind of a good thing. So next, we're going to talk about scale-up. How do we do that? Compress latency, ensure high availability, and handle performance rates across, you know, many, many, many large enterprises.