Bridging Traditional IGA with Cloud Native Authorization

Hi. So I'm Magnus, I'm a principal engineer at Saleo And I'm Nandi. I'm a senior identity and access management engineer in Saleo. So breaking from the financial industry, although to crack a joke, we actually are fully licensed bank, but we will not be talking about that one. So the context of today's talk is about workforce identity, not anything related to our like millions of customers.

And the specific focus is in-house applications, not commercial of the shelf software that we integrate, but really software that we develop, as you can see from our titles, we come essentially from let's say, machine room level problems, where you care about API protection, protecting the applications on a lower level, but there's a different world since this is the IGA track, where essentially you care about all the other things that were already mentioned, like how you assign roles, how you get access, how you like certify how you do sod violations.

And essentially this talk is about how to bridge these worlds, but with a specific focus on how to do this at scale, when you come from large engineering organization. It's okay. Okay. Yeah. So some numbers to show you the scale we operate Atando we have 200 plus plus engineering teams containing 2000 plus software engineers, and we are managing 4,000 plus in-house applications. Yep. There's a saying, if you have so many engineers, every problem looks like an engineering problem. And with 2000 software engineers, of course, authorization looked like a software engineering problem.

So challenge engineers of course solve it. The problem starts when each team started solving this problem in their own way. So as the central corporate IM team, it was a little bit challenging for us. And it was also getting out of hand of the engineers as well in the scale. So getting security right is hard and getting it right through 200 engineering teams is even harder. So that's why we started thinking about a solution where this authorization and auditing can be governed from a central location.

So, Yeah. Yeah. So we designed a solution where engineers still have the authority about the in-house application concepts, but when they define the concept, this concept will be transformed into requestable permissions in our central idea solution. And the next thing is internal users can actually come to this central location and request access to these permissions.

And upon approval, of course the access provisioning will again be automated and available in the application level to be executed by the policies and in this solution, how access is requested granted or audited E audited is none of the business for the engineers or application owners. So, and the last but not least the main quality we want in any cylinder solution is the scalability to cater for our seasonal peaks.

Of course, like cyber week where cellular infrastructure is in complete stress. When there are like higher frequency of orders, our services, service communications happening among thousands of applications, it could actually add up to 1 million access decisions per second.

So yeah, this is the motivation for our whole solution. Also, if you wonder why we have 1 million decisions per second in workforce identity, the reason is that for us service to service, communication is part of that whole solution, which means anytime in order place, traverses the microservices and essentially every like single step is an access decision in itself, which might be very simple, but that's the reason why we have these numbers. They obviously don't come just from employees. So our journey, like this is the only slide about a journey.

So like a while ago we essentially went on a shopping spree and looked at the market to replace essentially a huge landscape of in-house build software for am with something that actually comes from the market. And it was very funny because we actually tried to find a solution or like advice for the specific problem of like bringing like thousands of in-house applications to an IGA system and make it manageable.

And it was interesting because on the IGA side, they were always trying to go to yeah, but then you have active directory, you have groups and then which commercial system you're actually integrating with. And when we explained, no, we have like thousands of those and they don't, or like they, they shouldn't really care about implementing these things themselves. They essentially pointed to.

Yeah, well we saw this maybe, but it's customer specific, like, which is just, we don't know, coming to the other side of policy engine vendors. It was also interesting because they were pretty much closer to where we were coming from, but they hadn't ever seen the actual integration to the request side of things or the compliance side of things. So they could explain how to do policies, decisions and all that.

But like when you ask them and press them hardware, all that information is coming from that these policies need, they were like, yeah, it's customer specific and well, you need to implement it. And well, in essence, we don't know. And why is that? That is not because those vendors are just too small, stupid or whatever. It's just because it's essentially two worlds that I mentioned in the beginning that rarely interact closely on the left side. This is what we already heard, like from the journey.

This is really the world of like, that is more compliance, driven, most cases, but it's also user driven where users actually would go to request access, approve access, review, access, and so on. So this is really also a bit biased towards commercial software or big in-house like software wire, right? That is closer to essentially where are coming from, which is engineering, where it's more about how is the application actually protected? Where is the request actually ending up? And how do I teach application-specific concepts, also integrations with security operations.

There's also something that you would do rather on the policy engine side. And there's a slight bias towards in-house applications because it's incredibly hard to protect commercial applications with something in front that hasn't been designed by that product team. I won't bore everybody. So I would just go over this because we will mention this a few times afterwards. So there's also like a link to read like a goodness document about this. So there's essentially full main concepts in policy engines in general, or attributes based access control, which is the policy decision point.

That's essentially a software component that does nothing, but come to a decision. Yes, no, or structured, if a specific request is actually allowed to pass it, doesn't enforce. It just makes the decision and also records the decision for review or for like, like say monitoring tech patterns. There's a enforcement point, which is the actual thing that denies request. Typically this is an API gateway in modern setups, but can be something else as well.

The third point is the policy administration point, which is what you would normally think about as the policy tool, which is where you go to edit policies to make impact assessment and these kind of things where essentially interact with the actual policy system and the most important thing, which essentially bridges like least in our view, IGA to our world is essentially the policy information point, which is essentially the static data that you need to actually formulate meaningful policies, very common to have like organizational structures, but can also have like roles, like very deep technical roles, permissions resources.

That's the typical stuff you will find in there Coming back to the title of the presentation, because we claimed this had something to do with cloud native. We are fully in the cloud. So we have shut down our last data center last year, meaning we actually need something that runs at our scale and doesn't just like produce a single point of failure for the entire company.

So we essentially started rolling out policy agent, which is essentially a very engineering, friendly policy decision point that we can use in our infrastructure to actually start integrating what we are talking about advanced natively on Kubernetes, which is very much what we, we do day to day. It's massively distributed doesn't hold states. You can run it as close to the applications as you want. So you don't have to have a central offering that is also bound to fail.

And on the commercial side, we essentially decided to go with styro, which is the policy administration point, which is essentially the use interface, which we use to get data and policies to policy agent. And that is also the point where we essentially integrate our IGA tool. There's one key thing in this, it works an arbitrary adjacent structures, meaning there is no inherent notion of what an entitlement is, what the resources you can essentially store any kind of data. And then you can formulate any kind of policy, as you might imagine.

That is not very useful for AGA because you want to speak in different terms. So what we essentially started doing is to actually put an adaptation layer in between like the like free world of like doing anything arbitrarily to where we're actually coming from, where you're actually talking about accounts, users, entitlements, and so on, and essentially formulate a canonical structure on the right side in Sarah, where we can actually write this information. So from the perspective of the IGA tool, everything looks like any other target system.

So it can talk in terms of accounts, permissions, signing, access revocation of access reconciliation, all that kind of is emulated. And then just stored in specific places inside sterile, where we can then formulate policies to actually enforce it. So one of the case studies we did, like one of the applications we picked as like early adopters for this, it's a very typical application we have for in-house things. We call it awesome analytics it's of course like a fake name. The name is different eternally. So this tool essentially has two things.

It has like a single page application for users, but it also has like a rest API as pretty much all our applications have. And what this team actually just wants to do is it wants to protect specific aspects of the application in a way that they don't have to think about it. So what we are essentially doing is we are using the rest API.

This application already has, and essentially moving all the resources that are relevant for access into star, open policy agent and exposing them in our IGA tool so that when users actually go to the IGA tool, they can formulate what they want in terms of what they see. So they say, I want to look at awesome analytics. I want to have access to that dashboard. Then it gets approved and they have access. Yep.

So moving a little bit towards the technical side of the solution in this complete solution, there are two main parts of data flow, which happens in the background enabling all of this possible. So the first data flow is actually how in-house application concepts would end up in the, the IGA product as requestable permissions. So this starts when a, an engineer boards, their application, they publish a set of rules and configurations into a so rules, let's call them policies and the concrete contents information, which is required by Schneider to create a, a system for this application.

So policies will contain actual authorization policies for the application, and also it'll contain the rules. Schneider would need to convert application concepts into actual requestable permissions. We have developed adaptation layer, which I call blue. So with this glue, Tyra has the possibility to pull the information from the repository and create a system representing this particular application. So it'll actually get the policies, pull the policies as it is, and creates sty policies. And it will, in addition, it'll create a data source.

So this data source is in Jason format and it'll put the application concepts, converting them to let's call them entitlements. So as you said, as you see in the previous slide, there was information about dashboard entitlements, like campaign sales, fashion store sales, such. So strata will create such entitlement information and put them in the data source, which is adjacent format, and then comes our IGA product, which actually can pull the information from St data source towards the IGA side.

And there's another adaptation layer, which can actually convert the Jason into the entities, a two by the IGA. For example, if there's a campaign, a Jason object inside a St, the adaptation layer actually converts it to an entitlement.

So it, the entitlement would be created automatically in IGA. And the last part of the data flow is actually when an engineer or when an app in house user actually comes into IGA, they can see these permissions and actually request whatever they want.

And yeah, after if they get the permission approved, that part, that that information will again be pushed to sty site. So the sty data source, which already has the information about entitlements will now be populated with the information that actually this particular user got access to this particular permission. So that is the first flow. And yeah, and the second part of data flow is actually the one make the policy enforcement possible. So it start again from the last step of the last, last side, where a user gets permission approved.

So when a user gets permission approved, it goes to Schneider. And there's another one component, very important in this enforcement part, which is power open policy agent running locally to the application. When I say locally, it's very locally. Most of the times, it just runs in the same pod as the application in Kubernetes environment. So the data flow within IGAs and OPPA happens in the background again.

So once a user gets approval, the information will be already populated to Tyra and locally running open policy agents actually have the capability to pull this information related to their application from St. So the same information about policies and policy data will be replicated in local OPPA as well. So now OPPA has information about policies and information about the, who has access to work from the case study. If you remember, John had access to campaign a sales. So this information is available locally in Nopa.

So enforcement happens when a user already like user goes to the IGA and get their access approved. Then they try to access the application. And there's an API gateway in the middle, which is actually acting as the enforcement point. It'll call open the local open and ask whether this user has access to this particular resource or not. SOPA has all the information locally to get, take this decision. So it'll return the decision.

And after the decision is made, of course, gateway will either forward the request to the application or the user might get a phone or three, depending on whether or not they have permission. So this is actually the whole flow.

So yeah, if you want to take something like automation and sales service was the key for the whole solution.