KuppingerCole's Advisory stands out due to our regular communication with vendors and key clients, providing us with in-depth insight into the issues and knowledge required to address real-world challenges.
Compare solution offerings and follow predefined best practices or adapt them to the individual requirements of your company.
Meet our team of analysts and advisors who are highly skilled and experienced professionals dedicated to helping you make informed decisions and achieve your goals.
Meet our business team committed to helping you achieve success. We understand that running a business can be challenging, but with the right team in your corner, anything is possible.
The Common Ground movement of the Dutch municipalities is developing innovative solutions for greater interoperability. An important part of this is the data landscape, where functionality is accessed through microservice API’s. In the analysis of this architecture, one aspect is barely touched upon: The Access Control aspect in API’s is not appropriately co-developed.
The Municipality of The Hague has performed a Proof Of Architecture (the POA) to demonstrate that it is possible to unlock an existing API in which access is not explicitly modeled, or that still uses traditional Role Based Access Control methods internally, restricting interoperability across contexts.
The POA is done in an effective and efficient way through innovative 'zero trust architecture' concepts, such as Policy Based Access Control. Security and privacy are thus demonstrably realized in accordance with legal requirements. The POA proves that it is technically feasible to add input-filtering of access requests to ignore the restricting RBAC method and thereby open doors for municipalities for interoperability in an autonomous and secure way.
During the presentation the working principles of API access from a perspective of Identity & Access Management are explained, but also how these principles can be applied in practice in an existing application landscape.
The presentation will be a joint presentation between the lead architect of the City of The Hague, Jan Verbeek, and access strategist André Koot.
The Common Ground movement of the Dutch municipalities is developing innovative solutions for greater interoperability. An important part of this is the data landscape, where functionality is accessed through microservice API’s. In the analysis of this architecture, one aspect is barely touched upon: The Access Control aspect in API’s is not appropriately co-developed.
The Municipality of The Hague has performed a Proof Of Architecture (the POA) to demonstrate that it is possible to unlock an existing API in which access is not explicitly modeled, or that still uses traditional Role Based Access Control methods internally, restricting interoperability across contexts.
The POA is done in an effective and efficient way through innovative 'zero trust architecture' concepts, such as Policy Based Access Control. Security and privacy are thus demonstrably realized in accordance with legal requirements. The POA proves that it is technically feasible to add input-filtering of access requests to ignore the restricting RBAC method and thereby open doors for municipalities for interoperability in an autonomous and secure way.
During the presentation the working principles of API access from a perspective of Identity & Access Management are explained, but also how these principles can be applied in practice in an existing application landscape.
The presentation will be a joint presentation between the lead architect of the City of The Hague, Jan Verbeek, and access strategist André Koot.
Good afternoon, all my name's. I'm working for Sonic B Consultancy Company and this presentation was meant to be a duo presentation. The person named First John Baker was the architect of City of municipal de, but from last week he joins another company so he couldn't present at this case for this, sorry for that. So you have to do it with me. I'm the only one. The second SQS will be that the P, the slides are not similar to each other. They're all different slides. I picked them for effectiveness, not for beauty. So sorry for that as well. And let me skip this one first.
That's just a commercial slides. That's us. Let's just dive into access control on the first light. This is the first light is a typical model of robot based access control and robot based control. I'll update later is at the end of it lifecycle. I predicted the end of rrb back 15 years ago. I lost that bet, but I'm still convinced that our robot based control is not the effect, most effective way to manage authorizations. It's effective from user friendliness perspective, but not from a governance perspective. I'll show that later on. This typical model of access control robots.
Access control, we've got people, employees, we've got the business role role in the business being working works in the organization and right, right end we see objects, data documents, tables and and databases, whatever. And you can see that in several applications we get an application rule A application, bay B, giving access to specific types of authorizations. And while I didn't show this slide, but if you see some issues, for instance, ISLY one and two are gone and three catch role A as well. We see that there's a typical issue of segregation duty.
They're conflicting authorizations because the fact that didn't manage that at the same time. So we have some traditional big issues in robust exit control and we've got some, this is an advantage. We have some, some business role giving access to an application role. And from that application gaining, getting access to resources, whatever it can be. So we can see who has what authorizations.
And if we, we can also have governance back. We can of course see what accounts have access to these authorizations. So if you've got an entitlement, we can just walk back the tree and see what accounts are connected to those authorizations. That's nice, that's easy, that's clear. But it's not everything we need to know because we've got some issues like for instance, who doesn't love those nested groups in AD or in SAP or whatever. It's a structural issue and we cannot fix that easily.
And it means that even though we have robot access control, we still have no clue who has authorization because you have to clear up all those nestings. Second issue context, robust access control means you've got authorizations based on your role in organization, but we are lacking the concept of context. So I may be a police officer, meaning access to the police registration, but only during my shift hours outside the context, I don't, I shouldn't have access. Same for there. There are multiple examples of the context component missing in rback.
It's not in the RRB documentation, it's there's no philosophy about context. So we need that dynamic access, the dynamic component s o d case of duties as show picture before we can defines od. But it's not, not naturally. If we are looking at robot control, there's some other fundamental things missing. For instance, the the process management world of of defining s od rules that's lacking. And a rule S od rule is not a role. There's a fundamental difference. So we need to, to take care of that. It's not in rbk. And then roles are aesthetic.
If I'm at a customer and they say, well, we built some roles, I applaud them because that's a big achievement. If you manage to build roles and if you have a role, congratulations, never change it because it's very difficult to change rules. It comes a lot of governance, headaches. If you manage, if you have roles, you don't, don't manage those. So that means that roles are static. And in these days when we move to clouds, to virtualization environments, to to APIs, we need dynamic. And that's not in our back. Arrb back is static. So we have some big issues in arrb back.
We need to move ahead and this is where there this picture came from. You knows this picture, seen this picture from aromatics I picture from 10, 12 years ago. And this is the lifecycle of access control as defined by aromatics. First we see the unique application codes. There's a monolithic application, you log in the application, you get your authorization, you have to change the password and based on your role in the application, you get access to the application. So in every application that we use, when you have the same authorization model built in, so there's a lot of maintenance.
So in the next phase we say, well, if I have to log into an application, another application, let's reuse that log per process. So we got the LDF connections so I don't have to log into sap, can just log into Windows and get access to sap. The rest of authorization manuals still in sap, still the roll and the transactions, everything's still in sap but at least I don't have to log into sap. So we can reuse the authentication and single part reuse score, an architecture principle that helps a lot. Next phase. And I was puzzle by that a long time ago.
We see if we now get your application, get it behind an API gateway, then we can distribute the application, clean, reuse the access from different domains, different networks make it easy to get access to the application. We still have the authorization in place, but at least we got the signal on part and we have the distribution part. And the last last phase of this model is we move to microservices. And that means that if we build microservices, we can also lift out the authorization parts. We can lift out all governance from the application.
So the microservice in effect in this model is security wise, a very stupid component is just a very stupid component. As long as you come down through these layers, you are, you get access based on the policies built in this authorization engine. So you have to pass the authorization engine to get access to microservices. And microservices can be stupid. There's no security in the service, no authorization in the service. If you can see the service, it's yours. You can use it. This is in fact a concept behind Sierra Trust.
Of course, this is the concept of Sierra Trust. You have to pass these layers and if you pass layers then you get access. But there's, there's some issues at this end because the third table, third column, you see the API gateway means that we have an application and someone built an API on top of the application to move it behind an API gateway. And this is where the well, where the, where the trouble starts. We have a few customers and one of them is Stitch. And we saw that they were building APIs to make it possible, to distribute applications to make it accessible from other domains.
And they built an API and they never thought about access. They built an api, moved it in the network and now we have an API and have access application, but they're still all legacy access control in the application. So we try to migrate to modern architecture. But legacy authorization model is still in the application, still rules and profiles in the application, access control, access to applications was missing in migrating to APIs. We got another example for that.
Sorry, I have to push this again. So at this moment we try to get all our customers to move from platforms to protocols. Platforms are locked in instruments, so we try to move them to protocols to get the functionality out in without your platforms without looking. So this is all about migration to protocols like odc, saml or to make it possible to do this. So when we, for last year we, we did a project for the Alliance of Dutch municipalities and we came up with a simple, well ugly looking reference architecture. And I'll show how this works.
We got at, right and we have these APIs and this and the lines of municipalities came up with a number of APIs and like I mentioned before, without thinking about security, without thinking about access. So we have the, these APIs and now how we get access to the APIs. So we have these APIs and we decided to draw this picture. We have a person, an actor with a client trying to get access to the api. First you get at the API gateway, we use KG for that. For the perfect concept, KG needs to know the identity. So KG steps out to the identity provider if there's no identity there.
So we can step out to the authentication part for the identity provider. Next step will be validation by the Polish engine. We use OPA for that. And in the policy engine, yeah, we have this legacy of robot exit control. The application still are back. So we need to validate the roles of the person. If you're using API access, there's no role in in attributes unless you add it. But the APIs are silly. The APIs are built without defining roles or authorizations. So we needed to add to, to validate the authorization of the user of actor. So we built a table, a policy table.
This person may have this role, this role gives this authorizations and we call that a policy information point. And if you're compliant with policy, then you get access to the application. So functionally, there's no change between the mon way of working and the, and the modern way of working using APIs. This is how the migration works. This is a typical application. Normally you would log in username, password, you got a user, you got an account. Account is met to a role. Role gives access to authorizations. This is typical how your application works, how it normally works.
Now we decided to move it behind an api. There are different ways of working and with, if you can see at this moment, the first phase, oh, sorry, the first phase, what they did in these applications is we skip the login part and we move the account to the protocol that's getting access to the application. So using a ID provider and the provider gives you account to log in a name to the of the person to the application. And the application just listens, looks up the role of the person and based on the authorization gives access. It's single.
In this application we building now, we took out the role because we can do it in information point and we added the account and the roll to the application and meaning get access to the application to the location function. Title two, This is the stick, the access control stack that we built. I'll skip this, but this is the same picture. We decided to use authentication, we identity provider authorization via policy engine opa. And we transformed the input in an API gateway. I'll give this later on. The issue iSelect the the con, the context of the identity.
If you are using this, this transition, the context that we need is missing in this case, this case, it's a case management tool. It's a civil servant working for a citizen request. And if you just lose, use this case, if I would log into the application, I'm gonna sit civil, civil servant. I'm attached to a lot of data. I get everything back, all the output is all data that I'm entitled to. But the context of the single case I'm working on is left. There's lacking. So meaning I got too much output. So what we did do was we added an input filter.
Input filter gave with the context that was relevant. So if I'm working for customer 1, 2, 3, 4, I added that as a context to the access request, added that to the access request. And meaning that we have input filtering instead of output filtering. So instead of getting all data back, I got just one record back. How many time is left? Nothing.
Kind of, kind of nothing. So if for those interested, we have some pictures here and I've got some code if you'd like to see some code.
The, the architect's not here so we cannot explain it. But at least this is how we build this lookup code. And how we did do the, did the input filtering, this is input filtering that we added in the policy of OP A. So this is the way how we added the context based access control to a non-contact based access control environment. Any questions? Lots of questions. I hope not for today. Thank you Andre, for the very nice presentation.
