Enabling Fine Grained Authorization for Microservices with Standards

Thanks everyone, and happy Friday afternoon at EIC. Yeah, it's very hard to be an identity enthusiast and not also be a standards enthusiast.

Okay, so I'm gonna talk a little bit more on the topic of fine grant authorization for microservices and what we're doing around standards to both secure them and to enable fine grant authorization in this area. I think with the, so I think in the next 20 minutes or so, I'm gonna spend a little bit time talking about microservices and how, just how complex this area is and what kind of challenges arise from them.

And then we'll talk a little bit at the opportunity or take a look at the opportunity, some of the foundational standards, some of the working groups that's being formed, some of the opportunities for people in this room to come and help and contribute, both in helping the working groups, understanding the problems and the challenges, but also in validating the solutions that the working groups are coming up with. And hopefully there is questions, and hopefully there is time for quick q and a.

Okay, so first let's look at the world of microservices. So one of the really interesting things that when you get into this space is that you realize how we draw the world can be very misleading, right? So often we draw a picture of the world like this, and if you look at that, you would be convinced that Greenland is slightly bigger than Africa. But in reality, if you draw, if you look at it, it really isn't. It's about the size of the Democratic Republic of Congo, right? A country in Africa. Yet when we draw pictures of services and systems, we often draw them something like this.

This is a very typical sort of OAuth configuration. There is a resource owner, AKA human being. There's a client, a resource server that you wanna access in an authorization server, right? And there's the little that you do between these participants and that picture is a simplified model, but it can mislead us just like that other big map can mislead us because those boxes are not monoliths. There are many, many services, right? That resource server that we drew, it's made up of many services microservice.

One calls, microservice, two calls microservice up to N, but it doesn't end there, right? Because those lines that we draw, they're not straight and the boxes, they're dynamic, right? They're coming and going, we're spinning them up and down all the time.

Oh, and of course, right? There's not just one resource server because these systems are complicated, right? They're talking to other resource servers over there in a different trust domain, or maybe in the same trust domain, right?

Like, remember that picture we drew? You can see how easy it is to make, to draw wrong conclusions.

However, one more thing, they don't run in the same environments these days, right? It's very common for us to go and build a system and for maybe for scale purposes, maybe for economic reasons, maybe just for practical purposes, right? Resiliency. We want to deploy microservice in multiple environments so that we have uptime, we can negotiate on the price of the compute, or we need resiliency, or there's very specific regional or even compliance requirements that we need to meet. And so those boxes are not running in the same place either, right?

So what we really have are the sort of highly, highly distributed type systems. And so the boxes that we drew and that OAuth world, although a useful model, is an oversimplification that has led us to ignore all these other microservices. And each of those microservices needs some level of identity and some level of authorization. And this is the big blind spot that we have today. And it's from a standards perspective even, right? The OAuth protocol does not take into account this kind of, it doesn't make provision for this level of complexity.

So, but this is also the fine grand authorization opportunity, right? So if we look at that picture, if you, if we go, we'll go back to it, but if you look at that picture, each of these lines presents an opportunity to intervene, right? It's an opportunity to secure each of those workloads, and we should do it judici judiciously. I think that's the word I'm looking for. And so let's talk a little bit more about what can we do to secure our environments that really look like this, not that simple three box model that we started with. So first off, right?

The old saying, manage what you can measure, authorize what you can identify, right? So first of all, in these kinds of architectures, every microservice must have an identity, right? And we need to standardize ways to provision those identities, how they get formatted and how we manage the lifecycle around them. There has to be an authorization policy attached to each of these identities or each of these workloads. And then finally, right?

Every authorization policy needs to be able to combine the workload identity, the user identity, and the context of the transaction in which it is taking place, right? If we can do that, we can deploy least privilege architectures, zero trust architectures. But those are the things that we need to do, and those are the things that we need standards for as well. So let's talk a little bit about the points of control. Where can we, where do we need to intervene? Like we just drew all these new lines and boxes that we never had before. So our points of control, right?

Is first, let's look inside the trust domain, right? Things that happen between microservices. So every time there is a call microservice to microservice, right before you hit that load balancer internally, right? That's a point of control. So we need to think about a set of things there. How will we secure those? How will we secure those identities, those credentials, how do we bind them to the transaction? And how do we make sure that the right user context and the right workload context and transaction context continues to propagate?

And then the other one is when we cross trust domains, right? Suddenly you're dealing with a different authorization environment, different authorization server, may not even be your own, may not be one that you even trust particularly, right? Might be a supplier, right? Or another partner that you have to do business with, but you may not trust them completely, right? So you have to think about what to do with that. So that's the opportunity, right? There's the trust domain that we need to cross. So let's talk a little bit about what we can do with standards.

The good news is there, there is already quite a lot of standards available. I spoke about this last year here at EIC. A lot of them is being done in places like the I-E-T-F-O-O scheme. And some of it is actually not standards, but open source projects, things like the secure production identifier framework for everyone. spfi work that is being done in the cloud Native Compute Foundation. Something that I would definitely, you know, if you are interested in this space and you don't know about spfi, I would strongly recommend, look it up, spfi.io.

So the good news, we are getting to stand on the shoulders of giants, some of them at this conference, but we also need to go and do some work to fill the gaps. So which are the gaps we need to fill? First off, proper propagating context, we need to be able to tell or figure out right when this call goes all the way to that very last microservice crossing a trust domain. We still need to know who authorized the original request. We probably wanna know which services were in the call chain. And we also wanna know what is the transaction context?

How much money is involved, what was the request originally, time of day, things like that. We also need to be able to do this across trust boundaries. We don't really have good ways to do that in the current, within the current set of set of OAuth specs, for example. And then the other thing that we need to think about is credential theft mitigation, right? How do we detect, how do we prevent and detect theft? How do we detect replay? And how do we avoid forgery? Because a lot of these systems today still works or relies on unconstrained or barrier tokens, right?

So this is one of those opportunities that we have to fix and we have to fix it now because we wanna fix it before this explosion of workload identities hits us and the standards aren't in place. So what are we doing about this? So the first thing that is happening is this idea of transaction tokens that George, who's in the audience did an excellent presentation on on Thursday I, or Tuesday, was it? George?

Wednesday, Wednesday. So I would definitely recommend if go watch the recording for, for more details on transaction tokens. This is a new standard. And basically what this does, and I'll sort of wave my hands on it, essentially, you know, when a client presents an access token to the front end to one of these microservices, it calls to the transaction token service and exchanges that for a transaction token, this transaction token can then contain additional information about the transaction.

But importantly, it is not an access token, it's token we're, we are also thinking about how, what, what a central constraining it look like, but at least you cannot reenter on the front door, right? You lift that token, you're pretty constrained about what you can do with it. And it's also constrained in terms of its lifetime. So it's one step in this direction, you know, gives us a little bit of advantages in terms of performance, you know, can prove 0, 0, 0 trust posture. It also allows you to do down scoping, right?

So when you do that exchange, you may have very broad access, very broad scope, but the transaction token service may actually, that transaction token itself has reduced scope. And when you make your authorization decision, that fine-grained authorization decision, you can actually scope that down quite a bit. Also gives you traceability of this transaction. So really important in terms of things like audit and anomaly detection.

And again, I couldn't possibly do a justice, I would invite you to go watch George's presentation. The next gap, oh, and by the way, I, I always forget to add this. If you're brave, please scan the QR code or go to the IETF. This is work that is actually being developed in the OAuth working group right now. The draft has been in development for maybe about a year. It was officially adopted last November, and we would love your input and feedback on this, right? So now it's a great time to get engaged and bring your expertise as well.

So please check out the draft IETF participation is free for anyone. If you can send an email, you can contribute and we'd love to hear from you. The next one is around crossing trust boundaries. So remember this, this, this connection here from microservice in up to that, across this trust boundary. We need to be able to cross that and still retain some of that information, right? That we have in the transaction token, et cetera.

And so to do this, the approach that we're taking here is we require that microservice to contact its authorization server, obtain an access grant, which then gets presented to the authorization server in another trust domain. In return, you get back an access token that you can use over here in with resource server two and trust domain two.

And, and basically it's sort of a, a combination of two existing IETF RFCs that we're bringing together, but being very specific and prescriptive about how they should be used. And so basically this gives you a form of, let's call it cross domain authorization and cross domain identity, preserving cross domain identity. One of the great benefits that we love about this is it allows us to leverage existing infrastructure, right? These are existing protocols that are already implemented.

We can preserve that authorization context, we can preserve transaction context when we combine it with transaction tokens, it's auditable monitoring. And then we can still manage to use all of this information that gets preserved across trust domains today to do fine-grained access control. So that is the second gap also actively under development.

Again, if you're, if you're brave scan the QR code and this the same applies, right? So this is a, a, a draft that is currently under development. One of the open decisions or one of the open discussions that is active right now is about how we central constrain when we cross trust domains, right? So that we can, we don't, and what does that mean, right? And I think there's some interesting proposals on the table right now. Definitely would invite folks to start reviewing and, and give feedback from an implementation perspective as well. So third thing, mitigating credential theft.

Okay, so what's the thing that we're worried about? It's like, well we have transaction tokens. So when you steal, like stealing the access token becomes harder because it's not propagating through the system anymore. But a threat actor can still obtain from microservice one a identity or a credential and then replay that to other services or other microservices. And so you still have this risk and yes, they can be short-lived and so on, but what can we do to detect a new replay of these credentials so that we know that we're looking at a a replay type scenario?

What can we do to make it forgery resistant so that somebody cannot just go and make up or create these credentials for themselves or start minting the themselves? And then finally, right, how do we tie in the context of credential presentation, right? So transaction session and request specific. How do we do that for this? This is one of the problems that the newly formed whimsy workload identity and multi-service environment working group in the IETF is tackling right now. So we have a design team who is trying to figure out how we solve this problem as well as a set of other problems.

We're in the process of developing an architecture specifically for this as well as token exchange in this context, the workload to workload security, that is the problem that I was just pointing to. The most urgent piece of work in my view. We also need to figure out local token issuance, right? One of the things that we need to think about is how do we do local ticket token issuance in a secure way? Because these systems are gonna be disconnected. If anybody saw Justin Richard's Federation Bubbles discussion, these or environments cannot be assumed to always be connected, right?

They're gonna operate in disconnected fashions. We need to think about that and develop standards that we can all rally around. We also have a draft around best practices that is currently adopted.

And again, I would love to invite folks to come and participate in this new working group. It was formed in Brisbane in or just prior to the Brisbane meeting in, in March at the IETF. And as you can see already, we have a full, we have a lot of work, we have a strong community, but of course more people with more perspectives, it's gonna help us solve the right, pick, the right problems to solve and solve them in the right way.

So with that, I wanna thank everybody and I think we've got a minute or so for questions if there is any, Again, there were no questions in the chat, but there is a room, other questions towards Peter regarding what he just presented. And I think this, there are many different aspects and it's really well thought out to consider all the different dimensions of where communication can take place. There's quite a problem statement that you have here. So questions in the room. We steal the time from Martin, which is not too Oh, excellent.

Yeah, that's great. You did mention Wim C and Spiffy before that. What's the distinction? What's different problem?

So, so Spiffy is a, defines a set of mechanisms to provision identities for these individual workload identities. We want to leverage that and build on top of that. There is open source implementations in the cloud Native compute foundation. So anybody here can go and download the Spire implementation, deploy that, define identities and use them. The the gap that we see at the Spfi community would agree is that credentials that are issued are bearer tokens, JWTs. And those bearer tokens are subject to this problem that I described around token theft and token replay.

And so we are working with Evan Gilman and Daniel Feldman and other people who are leaders in the cloud Native Compute Foundation, PFI project. They're participate, they're actively participating in the design committees and in drafting some of these documents so that we can standardize the protection mechanisms that they can then implement in Spfi. So that is the connection between whimsy and spfi, right? We we're standing on the shoulders of giants and we're filling the gaps. That's what we're doing. Quick question, quick answer, then we end over. Thank you.

What is your advice for those who need to do this today or yesterday better? Depends on your environment. If you are running in a Kubernetes environment, I would start looking at Spfi. There are also several commercial implementations of this available. I would start there and see what is available. Is there a fit? If you're looking at new build, for sure. Right? I think getting that first layer of identity and then start building on top of that with the new capabilities as they come out.

But I, that would be where I would start, for sure. Thanks again, Peter, for delivering two great presentations.

Thank you, Peter. Thank you. Thanks for the opportunity.