Un-Complicate Authorization Maintenance

So hello everyone. It's nice to see lots of familiar faces from last week in Vegas. Hope you're all kind of over the jet lag a bit. Still struggling but we'll get there. So I'm gonna start off with a story of what my nightmare used to be. So I approached authorization from a kind a practitioner level. I've worked in a role where I had to both design, implement and, and sort of iterate on authorization systems.

And imagine this, you are either someone building software applications for your end customers or maybe you're an internal team and you're onboarding new, new products, your authorization and to your platform. Maybe you've acquired a company building, onboarding a new business unit. So my endless nightmare was when I'd used to get that email.

You know, the sales team is super excited. They've rung the bell, they've signed this massive new deal and on lands my desk is this whole new set of requirements around access controls. Earlier sort of stage systems. You might have a just a few custom roles inside of your app and you might have a viewer, an editor, a publisher, this sort of typical getting started type roles.

But if you're lucky enough to start signing these bigger deals or start onboarding kind of other teams or other departments or other companies, you then end up with this scenario, which I, I kind of faced a couple of times when we worked with one of the big airlines in the Middle East, one of the big office supply retailers in the us They come to you as kind of the company they've or vendor they're buying software from and they go, cool, we wanna onboard our, our our users. We have 50,000 of them and I turn around and say, can you fit them into these three roles?

And obviously the answer is not, you're gonna have to go and replicate their organizational structure to some degree so you can lock down and control permissions inside of whatever application you're building by geo, by department. And of course every customer you may have is gonna have different requirements around that. So it was always a bit of a nightmare and a bit of headache.

So by, just by way of introductions, I'm one of the co-founders of Sebos. My background is, like I said as a practitioner, started at Microsoft but then worked predominantly in B2B SaaS applications for the last 10 years. I'm an engineer at heart but ended up in the dark side of product management more recently but also and now very much focused in this authorization space with the ERUs open source project. So the question to kind of answer is how much time is wasted in your organization's maintaining authorization?

And that the, the aspects you can look through that are kind of varied depending on your role, what you do, what your end requirements are, what kind of users you have, what kind of systems you need to integrate with. So thankfully we are lucky enough to have users across a variety of industries and verticals and size, you know, in Germany. So VW gets to talk about Cooper and Coal actually use as well. And sees are some common themes and learnings from kind of the users I've we we have and sort of the thousands of discussions we've had also to date.

So for those of you here for David's talk around kind of externalized author ratio authorization, funny enough, that's where we're gonna go. But let's also take a stock at kind of what is reality for a lot of systems today, which is the kind of the traditional approach to authorization. And we are looking at an application implementation right now, but this is kind of one use case that you can apply to different environments. So traditionally your authorization logic is tightly coupled with your application or your service code.

It might be something you've written in house, might something you've outsourced, might something you bought in. But generally this logic is hardcoded and written in in once with no clear owner of what's going on. You know you've got that team together, maybe they've implemented the logic based on the requirements at that moment in time. Then that team sort of gets disbanded and works back on kind of feature processes and those sort of things. When those requirements need to change, you need to update that logic.

Things get quite tricky to manage or you need to go and find the people that can actually go and look at this particular code base to update how this logic works. Your policy is kind of now hard coded so it's very fragmented and there's lack of centralized management. So if you look at a kind of a typical stack for a more modern architecture today, you have like your incline application that might have some logic around like showing and hiding menu buttons and things in the app. You might have an API gateway which maybe is doing some path based authorization or checking tokens.

You have your IDP in there, which actually holds the identity obviously a big topic of all the other talks today. You actually have the service that the person's trying to request. You're gonna have some hard code logic in there and terms of what route and what actions are allowed. And then you might have some downstream sort of microservices even at the database level. You now have things like row level security inside of database systems. You might be hitting some third party cloud API, it's gonna have its own authorization logic in it as well.

So really if all the colored dots represent is you have all this logic just sprinkled across your architecture, which is a bit of a management nightmare, it's a scalability nightmare as well. It's not only from a technical perspective but also from a business process perspective. And you really have some management challenges around making sure each one of these systems can get and maintain the kind of state it needs to make the correct decision.

So when I look at kind of the sources of authorization, both from my own experience in talking to our, our customers and users, you know, it falls back down to the sort of the the standard people process and technology. So the people side of things, I'd say this is where most companies spend most of their time is really split around defining the requirements and then kind of making sure the rest of the business knows how those requirements are implemented.

So when you go sit down and start defining what your authorization requirements need to be, there's gonna be a laundry list of people that wanna have a, a say or an opinion. These are ultimately your stakeholders that need to be involved in this process. So like your product engineering teams, this is probably the most obvious. They're the ones building the system. They're the ones that are implementing the logic into the code base. But we see cases with customers.

We work with a big utility provider in the uk, one of the largest there where they have help desks, they have tens of thousands of staff answering calls and managing the accounts. And these customer support teams need certain likes of access to an account. Can they see whether someone has an active, you know, gas supply means gas supply to their house, should they be able to view certain billing information?

There's, there's requirements there around not only access but also delegated access fund. One is a sales team. So I mentioned earlier, you know, one of those big deals, they're all excited, they're likely to come to you as someone that kind of owns how your application's built and architected to say like we have some new requirements not only for onboarding kind this new customer we we just won. But the other aspect of authorization is where it kind of crosses over with entitlements.

So a, a sales team might be wanting to go and repackage how a feature or capability or a product is positioned in the market. So you now need to kind of rework your authorization logic to kind of be able to slice and dice your product offering based on what those entitlements need to be. Security team hopefully is a bit more an obvious one. Whoever kind of owns that security architect hat inside of your business is gonna have a load of requirements around access controls that needs to be put in place. End users is the next one around your actual end users.

What permissions do they know they have or think they should have and how you communicate that. And then regulatory is hopefully kind of a, an obvious one. So we work with lots of regulated businesses, you know they're going through various industry specific qualifications or certifications. Also your obvious kind of ISO 27,000 SOC two type processes. This is one that's close to my heart. Previous company I was the person that every year got dragged down to a dark room by a auditor and had to demonstrate all our security controls in one of our systems.

And it was rough I would admit at the time 'cause I'm sitting there trying to grip through logs showing look we're definitely controlling access to the system. So there's a whole bunch of requirements that come from that side of things. And then on the people side of things as well is how do you actually ensure that both internal employees but also external customers, be it actual external customers or other parts of the business, actually understand what permissions they have on the process side of things.

So you everyone, you've got your requirements, you know, what are the authoring policy authoring workflows. So how does someone that sits outside of it outside of product understand how to update and change policy logic If it's hard coding your application code and not everyone's gonna be an expert in x, Y, Z languages you're using in your stack when you do want to go and do a change, how do you actually test that change?

So how do you make sure that the updates you've done not only are doing what they should do but also haven't had any sort of second or third order degree consequences to that rollout? Change management is obviously a big piece of the process when it comes to updating. So core to your system authorization is in the blocking path essentially of every single request and every single access call that goes across your entire application architecture. So how do you version that? How do you roll out audit logs as I kinda mentioned earlier?

And how do you demonstrate not only internally to your teams so that they can check what's going on inside of the system but to externally to your regulators that you are getting the right controls and right access controls in place. We work a lot of fintechs, we have a couple of neobanks and a few different region of the world and they have to go in and get their banking license access controls are a massive part of that. How do you then prove it after the fact as well? So getting your audit logs in place without having to instrument your app manually.

Then the technology side of things, you know we are now in a very world of hybrid architectures where you have sort of legacy components running maybe in some dark closet somewhere, hopefully not under someone's desk. You might have things running in the cloud, you might have things running on edge, you might have some batch job being processed somewhere. You might have some backend system running in some other environment. So how do you make your authorization runs all over those in a consistent manner? If it's not, if it isn't hard coded.

So of deployment scalability, how can you make sure authorization is being done at the point where it needs to be closest to the actual application And ultimate two hand users, state management. How do you make sure that all your various systems are got the latest information to ensure they're making decisions based on the latest and most UpToDate information, be it on a database in a graph being stored with some request context and integrations, you PDP, PEP app, these kind of concepts that you've probably seen in things like the NIST papers and such.

And how do you make sure this's fixed into your stack? So externalize authorization is the and and we're now in a world where there's thankfully a lot of vendors in this space and we're all starting to talk the same terms and phrases around how you're go and implement this. So the way I look at it is we're now at a point where your authorization logic is not being read by the requirements but you actually can now put into place technology that enables the rest of the business to do these more fine grained access controls and policy based access controls.

And ultimately technology is caught up with what the requirements really are from the business. So going back to the architecture diagram before, same services along the top, but now all the checks are being done through some sort of policy decision point. There's many great ones out there. Go and pick, pick your poison I guess. And then the beauty of this model is all your logic is now abstracted out in systems sort of policy store and you then can do your policy administration independently of your application code.

And this is kind of the most high level piece, but really this did not survive the export from Google Slides. But the key thing here is we now it centralized this administration piece. You not have to go back to your dev team. You're not gonna have to go and create a Jira ticket and say see you in three months or six months depending on how agile you are. And there's a single point where you can update all this logic and this is centralized management but what the other property this gives you is you actually gonna get distributed decisions.

So you can man central manage centrally, but you can push the distributed decisions out to where they need to be across your architecture. So some cases you may wanna do things down on the client, other cases you wanna do things on the backend, you might have some batch jobs asy work happening somewhere all coming from the same source of truth around what your policy and what your logic needs to be. So really what does this enable? Going back to our people processes, technology model from people perspective.

So defining all those requirements, ensuring internal users are up to speed on the same thing. By centralizing your policies, they are now outta your code base. They can be something that's written in plain English ish depending on how you're defining your policies. And we see across kind of our users for the first time people outside of engineering. So we have, you know, security teams, we have architects or business analysts actually be able to understand what their authorization logic is for in some cases the first time 'cause it's no longer deeply covered in the code base.

They're not having to dig through GitHub et cetera to understand what's going on. They don't need to be an expert in Java or dotnet to understand and get visibility into what's going on. 'cause ultimately it's not those developers, it's not the dev team necessarily that are defining all those requirements. It's other parts of the business. It's definitely more the business and the process side of things on the process side of things.

So policy authoring because we've now got these policies abstracted out into a component that is basically standing in isolation, it's essential source of truth ly your policy or your authorization logic because it doesn't necessarily have to be policy, it's now ultimately a static asset. And the good thing about static assets is you already almost likely gonna have inside of your organization a good change management workflow for those so much how like today we check in code and we conversion it, go through QA testing, et cetera, et cetera.

Your authorization logic can now become a static asset inside of your business as well. And you can put those exact same processes in place and governance processes in in place. So we have users now for the first time that actually have some confidence of actually being able to not only understand what their policies are doing but actually evolve and change those over time in a way that they are certain what they think is happening is actually happening. And that's very much coupled with testing.

So much like how with software you write unit tests, integration tests and such with your software app application code by external authorization, again into a standalone component you can actually test that in isolation and make sure you're covering all not only the the the good, the common cases but also the edge cases in those test suites and make sure that things are as they should be before this code goes anywhere near even your testing environment.

You know a developer workflow can be very instant feedback and then go into other environments you can make sure things are working as they should and your rollout processes that you're used to, blue green deploys, et cetera can fit this model. And then audit logs. So one of the kind of side effects or benefits or side outputs you could say of having this kind of decoupled approach, those decision points are running distributed across your stack.

They've got the policies of essential source of truth, but now any application that's using your authorization layer to do the authorization checks are gonna go through one of those decision points. So those decision points are now the source of truth for not only the decisions but it's also the source of your audit logs. So the request comes in, I have this subject trying to do this action on this resource. It would evaluate the policies, it'll come up with a decision that might be an allow or a deny, it could be a conditional in some cases.

And before it even returns that response to the calling service, it can create an audit log. So you have this indelible sort of paper trail of at this time this subject try to do this action on this particular resource. And the decision was an allow or deny created by this particular policy, this particular policy version with these scopes, et cetera. And you get that really rich level of detail, which if you were to do it in a model where this logic was hard coded, you'd normally have to get an instrument every single part of your application to create audit logs in a standardized output.

This is just one of the side benefits of this approach. And then finally on the technology side of things, say because your decision points can be put anywhere essentially in your architecture regardless of where you're doing as checks, front end, back end edge batch, some async process somewhere, you're gonna get the consistent decision kind of regardless of where that's happening.

From a deployment of scalability point of view, depending on how you want to go and deploy your authorization logic because these decisions can now be distributed, you can run it across your architecture at the right point. So not to get into the weeds too much, but things like Kubernetes have get these great patterns around sidecars and services and such which you can put into your stack and these can be scaled up along with your application and from a scalability, from a process point of view as well.

Because that's central source, you can actually scale not only the code changes but you're also policy changes with tests along the way. State management is a fund one. So we're gonna talk about state here. We're talking about what users, groups or roles or the attributes about the resources users are trying to access. The approach you take can basically define where you want to store that personally. We take a very stateless approach to this. So you have your systems of records today, you have your, you know, in another ideal world, single source of truth, your identity.

We know in reality for bigger businesses that's not gonna be the case. But there's gonna be systems of record for different attributes about your different principles or subjects. And then the actual service or the application that users are interacting with are gonna be the source of truth for the resource they're trying to access. So you have these two data sets at some point that data's gonna come to a decision point as some sort of input and then you can make a decision.

And what that amount means is your policies don't need to necessarily worry about where the data's coming from at request time is gonna get that input either directly or from some other call. And then you're gonna make decisions based on the latest and greatest data you've got without having to necessarily synchronize things around all the time. And then integration with this pattern authorization is essentially just an API to other parts of your system. So regardless of your modern architecture, your legacy systems, maybe some archaic system somewhere hidden away.

As long as these systems can make a API call over the network or or locally inside of how it's deployed, you can get that consistent answer. And basically authorization is just just an API away through your applications and thus unbundling your application code and removing all that logic that's hard coded in. So where to start if you wanna go down this journey, always recommend start with your business requirements in sort of natural language. I did say plain English previously, but that's not really relevant 'cause we're in Germany. But start in that natural, natural language.

Really get those teams, those stakeholders on board from across the business. It's not just gonna be your product teams or security teams. There's gonna be other parts and get everyone agreement on what those policies need to be. Ultimately, authorization is a distributed data problem. There's gonna be data about your re subjects and your principles and different parts of things. So all those good processes you okay you have in place or putting in place around governance and change management are gonna only make your authorization logic more solid and more thought out going forward.

And then making sure you architect around the use cases and not choose the technology first. Really get those use cases down and sort of incrementally adopt authorization. I'm gonna make another call out to full standards as well. So serves we're one of the implementers of the first draft of the author and working group. Please just repeating David's call to come and and come with us either with your technologies or your business problems.

We, we definitely wanna make sure that we are meeting the needs from a a standard perspective for all the different use cases that you may have. And there's other projects as well, like shared signals that are worth linking into if you wanna get into this in more detail. And with that, thank you very much. Thank you Alex. Thanks very much.

Well time, quick question. Anyone, is that a question at the back or are you just waving at me?

No, I just, oh, was taking a picture. It's okay. Thanks Adam. Alright.

Yes, so.