Yeah, thank you. So yeah, 20 minutes is very short. I'll try to talk fast makeup for the time. A little bit here. Oh, I have a clicker here. Okay. So yeah, I come to you from the layer seven department in, at Brocom layer sevens, an API gateway were coming on our 20th year anniversary in July and already back then, it was all about API security, API access control. Right. And we didn't call them APIs back then, but that's what ended up becoming. And so API security, I like to think that identity security and API security are BFFs. They don't wear the same hat, but they hang out together at the same skateboard park. They, they drink their coffee together. Right? So if you look at the, the most important reference in API security, the OS API security, top 10, you see that throughout that list, it's peppered with identity concepts like authorization and authentication.
If you look at the standards that are known toge today as identity standards, I, I remember when OA was coming out, you know, layer seven was one of the first implementers of that and the other ones were identity companies. So there's a lot of stuff in common between there's a lot of overlap between identity security and API security. So if you think of a, a user experience timeline, right, you will switch between touchpoints on the identity infrastructure, right? The authentication, the SSO, like was being mentioned in the previous panel. And, and then you, you get a token and then you switch to the runtime API. And the thing is that when you're touching the identity infrastructure, there tends to be an expectation that there's a pause or a redirection, right? We think of that as friction, but very often that's an expectation, right? I don't want a, a really high value transaction to happen without some sort of check of my face ID or something like that.
So even the process of putting your phone in front of your face for a face ID that that could last for like a whole second, and that's an eternity for the infrastructure. Whereas when you're touching the runtime API, the, the, the it's kind of switched around, right? The, the, the user tends to wait for the application. You want to remove all the friction. You have to go fast, you need to get the data or call a function and things like that. But unfortunately, what happens is that because of zero trust, there's a need for doing continuous authentication, right? And, and tokens are great, but because tokens are bare tokens nowadays, that's often not by itself sufficient. So there's an expectation of continuous authentication, continuous authorization, continuous risk evaluation in some use cases.
So what are these API runtime policies that we're talking about here? I figured that, you know, there's, a lot of people are very familiar with identity security concepts, but this is the kind of stuff that we do in the layer seven gateway, right? We will validate a token. Hopefully it's a Jo. We don't need to call back the identity service, right? You might want to validate that the session is, is revoked or not. You might do course entitlement checks even sometimes fine grain authorization checks, things like you need to have this particular scope to do an ACB post on this resource. Or, you know, people have crazy requirements in some case, right? You need to go inside the structured payload and adjacent and fetch a value. And you need to match that somewhere. Maybe in a, in, in, in, in a claim that's in a Jo or something like that.
And then we do a lot of other stuff like rate limiting in quotas and, and a lot of threat, you know, cyber security related stuff, like input sanitization, a lot of integration, things like that. But for each of these types of runtime policies, you have an enforcement point, right? That could be an Ingres like our layer seven gateway could be ay, car, an agent, or very often the endpoint is responsible for doing that. Unfortunately, but the decision of these policies is either part of the enforcement or it's delegated to an external entity, right? So in the Prius panel, we're talking about, it's great with SSO, cuz you can centralize your authorization and stuff like that. So that that's when you delegate the decision, right? So this is what I mean between delegated versus local decision. An API request comes in your runtime policy enforcement is going to ask someone else, Hey, is this allowed or not gets a response back and enforces that decision. And this is leading, leading to a lean enforcement point and it greatly simplifies your architecture. And this is where I'm going to contradict the title of my presentation. Number of times here. It's great, right? It's it's you don't need to have a policy engine all over your architecture where API calls are coming in. So it's, it's a great simplification vacation. Whereas local decisions all happen within that same enforcement point that that's easy to understand.
So why aren't centralized decisions always better, right? Simple is better in my opinion. But in some cases that unfortunately does not scale because it creates a potential DEC bottleneck at your decision point. And so for some of our customers in some use cases that is just not possible.
So I like to think that it's not all or nothing. I like to think about the distance to decision a factor, right? So on one of the one end of the spank shop, you have something really simple where you're delegated on the other end of the spectrum. You have something that's completely efficient, it's all within the enforcement. But you know, there's, there's a bit of a spectrum here. You're if, if, if you have something that's all local, your distance decision is zero. But if you consult a side car, maybe it's greater in zero, but still not very big. Maybe inside your, your Kubernetes plaster, you have a component that's responsible inside that Kubernetes cluster for making a decision for you. Again, maybe that distance to decision values, again, a little bit greater, all the way to this decision as a service that you might be describing to where the distance decision is potentially very large.
So let's, and this is like probably the slide where I contradict the tile the most, right. I feel really strongly that simple as good. And I think that we need as a community to be mindful of the next generation of, of, of, of architects that going to inherit what we're building today. And we're building some unfortunately really complicated stuff. So I am very mindful of always avoiding unnecessary engineering. So imagine the situation where you've gotta runtime, API tokens come in, they're jots. You don't need to call to the, the, the SSO to get to know whether or not it's valid, but what about token revocation? Right? So start by asking yourself, can you, can I reduce my access token lifespan enough to the point where I can actually avoid revocation, right? You should definitely ask yourself that question, cuz if you can avoid revocation altogether, then your architectures greatly simplify.
So you're good to go. But if that's not the case because of your use case, the situation that you're in then go to the next step is remote checking token, every call a bottleneck, right? Some people might have just a few hundred API calls a second in their system and that's actually something that you can deal with. So if that's good and it doesn't affect your latency, go for it. Don't worry about it. But if it's not the case and again, some of our customers are, are, are in extreme situations that they definitely cannot do that. Then maybe ask yourself, can I selectively check revocation? You know, maybe only for the high value transactions that re you know, in some case that might only represent 5% of your, of your API traffic, in which case, again, you have avoided a situation where you have a bottleneck caused by the revocation check.
Unfortunately, that's not good enough for some people. Then you need to ask yourself, how do I propagate my token revocation information nearer to the enforcement point to reduce that distance decision and, and avoid that scaling issue. So here's what it looks like. You know, here's what we've done for some of our customers. So you've got your identity layer that should be responsible for handling the token revocation. That's an event, right? You can publish that, that event. And on the run time, you can have, you know, a smart ingress that's responsible for subscribing to that token revocation information. And remember those, that information for X minutes, X being the lifespan of your tokens in your system. You know, if your, if your ingress doesn't have that capability, maybe you have a dedicated component that's responsible for storing that in a cluster wide cash, right in your Kubernetes cluster, maybe like a Redis or something like that.
There's applicable standards to this pattern that were mentioned this week. Really cool stuff like Cape, but I'm gonna say something really bold at an identity conference. You don't necessarily need a standard for that. And what I mean by that is that by the way, Cape is, is way more than about this, this use case, right? But people have been applying to standard before the applying this pattern story before these standards existed. So don't let the unavailability of that, that, that standard to stop you from doing that. Obviously the standards is making it easier because it, it produces more interop, right? You, you may not be in control of both sides of the equation. You might be in a Federation use case five minutes, holy cow. Okay. And by the way, I've got a number of public GitHub repos that are illustrating the patterns that I'm talking about here. So here's one on that.
So token revocations, not really an authorization policy, right? It's it's, or it's a very special case of it because it's very binary. Is it revoked or not? If it is, then it's not allowed. That's kind of like the implied policy, but for actual authorization, what do you actually need? Right? You need the applicable policy based on the context. So you need to know about the policies you need, the ability to apply them at the runtime. Very often that means a policy engine and different types of rules will have varying thresholds of overengineering right? Different types of rules at runtime may involve different components in your architecture. Some may be completely local decisions, but some might have a, a, a centralized decision. And that's okay. So propagating information near the enforcement to reduce your D two D in this case is, is becoming policy as code, right?
You want to bake into the runtime infrastructure, the information that you need to make those decisions at runtime and the next frontier and what I call authorization governance. And by the way, I think it's really cool the work that Starra is doing in this case, but the, if you push this even further, I think what we need is global policies that are translated into effective policies across a heterogeneous architecture, right? You've you define an authorization policy and maybe it gets translated into OPA over here gets translated into, I don't know, exact mail over there, and of course in layer seven policies somewhere else. So, so that is basically the utopic next frontier for authorization governance.
So policy propagation, here's an example where you propagate policy from design time to run time in, in a cloud native example, using the Kubernetes operator. So you've got your policy governance system, Ty style, for example, where you are creating a new policy or new rule, or maybe you're, you're adjusting an existing rule, and you have your approval process in order to take this through its life cycle. And eventually it becomes truth. So you apply this to a source of truth. And at the run time, you would have the Kubernetes operator that would monitor that, that source of truth, detect to change and redeploy nodes, like our layer seven gateway with the new policy bundle. That's applicable based on that, again, there's a public GitHub repo that illustrates that if you wanna take a look how that works for us hybrid enforcement, here's another pattern that we see more and more where you've got an ingress that's configured for multiple authorization checks. Some of them are using our, you know, our specialized API runtime policy framework. But as part of that, you may also be consulting an open server to get, you know, a decision. So you can combine these things into, you know, overall API runtime policies. And again, here's a kit Harpo, if you want to dive deeper into that.
So how else can I scale authorization other than creating that complexity that requires me to, you know, have this distributed capability across all my API runtime notes. I think that advance based architecture are, you know, a great way to avoid that complexity. So imagine your, your, you know, your, your typical textbook eCommerce scenario for an event based architecture, you've got a new order event. That's, that's published, you've got a couple microservices, a reserve and inventory and fulfill order microservice of both subscribe to this event. This fulfilled order takes some time, right? But eventually gets fulfilled. There's an order filled event that's published and you've got a delivery microservice that's consuming that. Well, imagine introducing a, a, a fraud risk detection microservice that also consumes that new order event. And then if it, if something is detected during the course of the fulfillment of the order, it publishes a cancel order event, which also gets consumed by the fulfilled order, which short circuits that fulfillment, which avoids that delivery to happen. So whenever you can have a, an authorization rule, that's not real time, but it's still effective at doing its job. That is a, a really a clean way of, of, of scaling your architecture. So just in time, authorization, eventual blocking is another way to look at this, right? You're looking at crunching numbers for stuff over time, and then you are blocking eventually, which is better than never blocking.
So here is my Lifelight or as seen other speakers referred to as takeaways, centralizing authorization can really help simplify your architecture. And you should do that if you can, to contradict my title, but it doesn't scale in some cases, unfortunately. So you should enable your various clouds to enforce their own authorization decision, right? You can still centrally design those rules and you can centrally govern the them, but you, you need to enable your various clouds to enforce them by themselves. You need to balance performance and over-engineering, and you look, you please look for opportunities to decouple authorization checks.
