Yeah, good morning. Is it still good morning?
No, good day. Hello from my side. I will talk about when services need access, and I just want to jump right away into the topic.
So, if I look around in this audience here, probably most of you already started some time ago in the area of identity and access management, and that time you have done authentication authorization for applications, which probably has a two or three-layer model, like a frontend, a backend, and a database layer. You had a service account in place, and they had some static credential, and maybe some rule-based access controls in place.
I wanted to now discuss what has changed, and the reality probably is that you're already facing applications which are more like service meshes, and you have enterprise's API in place, and you're asking yourself, okay, how to secure them now? What happens if I have a chain of service calls and cannot predict what the API graph actually looks like? I want to talk a little bit about the technology behind that, but then talking about the organizational challenges behind this.
So, let's get into that. So, this is hopefully something which looks a little bit familiar to you.
So, think of Alice, which is a customer service agent here, and she wants to access the customer relation information for customers of her team, and is for this accessing the customer relationship management application, which then probably sends some service requests or API calls into the backend. So, most of you probably know they hit probably an API gateway here, they open the case service, and then go to the customer data service trying to receive some documents, which then finally ends into some database, still into some database where the data resides.
My question to you is now, where do you think is your authentication and authorization done at the API gateway? Probably most of you will answer that the entitlement is checked here. And my question is then, why is it not checked here, here, and here, and who is deciding about that question?
So, what I then frequently see or think what happens is two modes of failure, from my point of view. So, either there is a service account in place for each of the services which you have seen there, completely ignoring the user from the beginning.
So, Alice connected to the API gateway, and the authentication was checked there. She's allowed to access the customer relation management service, but no of the services later will ever check again who the user actually was. They simply have a service account, and they try to get the data they requested to get. The second failure mode which I see is blind trust or forwarding the access token. And then I hope that most of you know OAuth, at least the basics.
Alice will probably come with an OAuth token and forward this OAuth token to the services, and they then will simply use the same token to get all the access for the later chain of that. And that is blind trust in forwarding this information.
Those, from my point of view, is wrong and should not be the way it is implemented. Two separate problems do collapse because of the use of this kind of service accounts here, and that is that no longer the workload identity and the user entitlement context is separated from each other. They collapse into the service account here, and that is causing a major problem. And we need to understand that we have on the one hand side the user entitlement context, which is Alice and her tokens and the permissions and authorizations she is carrying along.
And then there is the workload identity, which is each of the services which you have seen in the chain there. And collapsing these two together into one service account is then later causing all kinds of governance compliance issues because you are not carrying both of these contexts all the way to the database there. Let's make that a little bit more concrete. So still again the same use case. Alice starts here, and Alice has a certain entitlement, may view customer records for accounts assigned to her team.
She will then hack the API gateway here where we still have a valid token and the constraint is still happened. What I have then seen a lot of times is that because some of the developers do not know better, they then use the case service here and the safecurses has then still a service account, maybe an API token, some static credentials, some information they are using to further call other services or even directly accessing the database. And in that moment, the user context here is the constraints are lost and then the service context actually is what is taking over here.
And in the end, I don't know if you have seen that in your company, is that the database request is actually returning all the records from the customer relation management system here, ignoring that we wanted to have only those for the team from Alice. And sometimes then developers recognize that there are filters in place, again filtering, while then still all the data has been fetched from the database here because the user context was lost at the API gateway.
Now, the thing is we actually want to delegate, right? We want to delegate the user context and we also want to delegate the access through this service change. And before we can actually do that, we need to establish the workflow identity.
No, the workload identity, sorry, in that case. And I mean, we could do something like an IP address or a network location, but we all know that this will not hold. And I think the correct answer is then that we need a cryptographic workload identifier and the most common technology to implement that is SPIFFI, open source implementation, to cryptographically identify those workload identities. I don't want to go into further detail of SPIFFI here. We can have our own talk about that, I think.
And yeah, I think it's not necessary to understand all the details to follow the further ideas I'm pinning out here. So we have then two options probably to solve the problem. So on the one hand, keep the context, have the workload identity in place there, and establish what I would say a cryptographic delegation chain. So most of you may have heard of ORS 2.0 token exchange. That is something which a lot of companies implement to exactly achieve that.
So that means still Alice starts with her own token here and forwards this token to the API gateway, but then the very first service exchanges this token to its own token to then call service B. And with that, two important things happen. One is that there is a cryptographic delegation chain. So in the access token is stored that Alice has initiated this chain, that service A was called.
And there is usually then also a reduction in the scope and in the audience so that the access token which is used here cannot be used for any of the services, but just for the call from service A to service B, which is important to reduce the blast radius once such a token gets claimed from an attacker, for example. So what you gain is you get a cryptographic proof of the delegation path, you have the audience binding, and you have a structural containment of lateral movement in that. With everything, there is also a cost to that.
So putting an authorization server here at top is something which puts the authorization server in the hot path of everything, which can cause latency issues, especially with the huge rising number of workload identities you may see here. And then we'll also talk about agentic AI in a couple of minutes.
I mean, if we're talking a service mesh, we may talk about 1,000 services in your company, maybe a bit more. If we then at some time talk about agents, we probably have this like 10,000. And then 10,000 agents try to do token exchange with an authorization server, you definitely run into latency issues. So then I discussed a second problem, and that is beside the delegation chain, we also wanted to have the user context alive, and we wanted to do authorization decisions.
And the good idea to actually do that is something which is then based on attributes-based access control or policy-based access control. And then to simply take the identity context from Alice through the service change, and then each and every service to check the policy here. And what then happens is that Alice forwards her ID token here to the API gateway and also to the other ones here, and there are then local policies for each of the services deciding whether this access is authorized or not.
What you gain is then the fine-grained resource level authorization at every hop, and the authorization server is out of the hot pass with that. You may have seen that because that is true in the SP800, it's quite common reference architecture in that area. It also costs you something. You're losing the cryptographic delegation chain. It's no longer here. As you don't do the token exchange, this delegation changes away, and there is a lateral movement risk included back here.
And that is why I have one kind of reference architecture which I want to introduce to you which I think is a good compromise probably to solve those problems. So that means we establish four layers in the end to manage the authorization and to keep everything under control. So the first is the ID token layer on top.
So the ID token actually hops from each service to each service, and then we establish the muted DLS, that is this biffy thing going on between each of the services, and we have then a policy decision point for each of them, maybe also a central policy server, something like an OPA, for example, doing the authorization decision here. And what you then also gain, and that is important, is some audit here. So you have a very clear audit at every hop here. Who is the service identity? What was the user? What was the policy decision? And what was then the outcome of this decision?
And you have log statements about that. So you have the user context, you have the service identity, and you have the service admission.
So now, if that is a good reference architecture, why a lot of companies are still in this failure mode one or two. So either they use a service account, or they simply forward the access token. And before I answer that, I want to do some on, there's one layer which adds complexity to you and even more pressure to get this actually done here. And that is the agentic AI discussion we are all facing here. So in the model I'm discussing here, I'm all the time assuming that we have a human user here at the beginning. But what if this human user is actually asking an agent to do the work for her?
Then things change. And I don't want to go into all the details because I think we have discussed this on this conference really a lot. But if an agent is here, then we have additional challenges which are not solved by the model I'm introducing here. You have this implicit scope expansion. So just because Alice said, I want the CRM records of my team, she doesn't know what kind of authorizations and what kind of access the agent then will actually initiate in the back end. She never authorized that.
And that means then also there's an undefined delegation boundary because the intention of the user is different to what then the agent is actually doing. There is no defined connection between that. And in the end, you have a content auditability gap. So if an auditor comes to you and then asks, okay, who authorized the access of that agent to the database? You probably have not a good answer for that. But with that, I want to then now come to why a lot of companies, in my opinion, still infer him with one or two. And I think the reason behind that is not technical.
And there is an organizational reason behind that. And there are three structural problems I see in that area.
So first, EIM usually arrives way too late in the development life cycle. So what I have seen a lot of times is that services are defined, enterprise APIs are defined, and identity access management only comes to the table when the latest audit or compliance check before something goes to production happens. And then suddenly they recognize, we have an issue here because we are not compliant with our security policies here, or we are actually facing real authorization issues because during tests they find out, okay, I can see customer relation records which I'm not allowed to see here.
The second is nobody owns the full API graph. So even if you understand, oh, I have to write some policies, most developers will come back to you and tell you, I have no idea who will call my service, and I also cannot predict what service I'm willing to call because that depends on the kind of request I'm receiving here. And that really is a problem. And in the end, then, the third structural problem is that there is no ownership for the policies in your organization. So even if you decide to have policy-based access control, who then writes those policies?
And we'll go a little bit more into detail. I need to speed up. So what does that mean in practice? So in practice, that means every service published must be declared what the user contact is, what they expect to receive, and we need to make the authorization context part of every API contract we are creating. I'm even thinking about, okay, make that part of your Swagger file, for example. It's quite technical, but you can try to do that. Scopes and security definitions are already there. Maybe you want to have even more detail in there.
And then this declaration is reviewed and approved by the design sprint, not at go live. So way earlier. And what you then achieve is that you have the authorization moving from the audit concern to a design constraint, actually. And services teams are then accountable for the authorization contract before they actually build the service themselves. They think about access controls at the beginning. I think then EIM is a defined early intervention point in the development lifecycle then. So rather than doing this at the end, you start doing that at the beginning.
So there was one other problem I was talking about, and that is you cannot map the graph in advance. And my advice is then to try it in an iterative mode. So the goal is not to complete the policy in one day. The goal is to start permissive but locked. And that is why I said it is so important to have this locking layer there. So start with policies which are quite open, which are not too restrictive, to avoid that you actually restrict requests in production system which are allowed.
I mean, that is then would cause a problem, and you would then immediately switch off your policy checks completely because you want to keep your production system up and running. With the locking then, the graph actually emerged. Within the locks files, you can then start understanding, okay, who is calling my services and try to bring that down. Two minutes, shall we, right? Okay. And then you can tighten that deliberately.
So you can then start to actually reduce the scope and define more restrictive policies to make sure that you follow this privilege principle while you are already following zero trust because you have established identities based on SPIFFI and SPIRE. Separate the token schema, so the identity token, the deletion of the identity attributes from the policy. So the YAM team is responsible for the set of attributes for the claims of the identity, and the service team is then actually responsible for writing the policies.
They know the business, they know the business logic in their services and can write the policies, and the YAM team knows, okay, what kind of identity information is available from the identities using our services. With that, let me wrap up. So first is authorization context should become part of every API contract you are actually doing here. I already explained that. The second one is rather than checking EIM at the order and compliance time when things go to production, do this at the very beginning at design time. Third thing is then the policy ownership follows the service ownership.
So first, they need to define the policy and the service teams own those policies, and then fourth, the observability goes before completeness. Don't try to write a complete perfect policy. Start with something simpler. Make sure that you have log statements, that you have governance about what is going on. And with that, my final statement is I think the two exist. The standards are quite mature. The problem is the room, and by this, I mean the room where the EIM team actually is. For microservices, I would say all the tools and standards are pretty mature.
For agentic services, the story is a little bit different, and that's the next level, and I think that is also why it is quite important that you already serve or that you try to solve this service mesh topic and get your homework done here. So final question for myself would then be, how many of you have the EIM team really represented at API design time in reviews today?
With that, thank you very much.
