Spicing up Authorization - A Zanzibar inspired approach

So welcome to the next talk. It's about spicing authorization using Zanzibar or approaching inspired by Zur. My name is Ibar if I'm working for Siemens at large drives applications and holding a software chief digital software architect position. And next to me is Roland.

Hello, I'm Roland Baum. I'm co-founder of the Umbrella Associates. I'm about 20 years in IT and information security and well, I like to implement innovative IT architectures in challenging environments. So the today's talk is about the real world use case and implementing the authorization in the real application.

So our, my baby is called C Drive iq, which is a holistic application including the smartness of the products we deliver to the customers hardware products, but also includes the digital platform, which we will focus today and also incorporates the digital services. So does anybody has a Siemens IQ product at home? Hardware? What is it? Washing machine.

Okay, perfect. Coffee machine, microwave. So we are not talking about those, those are excellent products. We are talking about the world large in the large drives means you see a person there next to the machine. This is the size is say 10 plus meters, right? So we're talking about electrical motors and VSDs and also mining applications and connecting them to the, to the cloud.

So it's a, it's a typical industrial IOT use case. How do we earn money? Very simple. We actually connect the assets to the cloud. We do analytic, we do store data, we collect data.

We, we generate insights out of it automatically or not. And the most revenues given from the service package where the customer even let's say, buys in even an expert support on top of the digital solution. So there are a prediction option, or they'll say for the, well, the failure already happens, options to, to save time for the customers. And this is how we generate revenue.

Basically the, it's all about catching or let's covering the entire lifecycle, starting from the design and engineering phase through all, all the way through the manufacturing commissioning up to the operation phase, whether our physical asset is delivered to the customers, where we obviously address plant operators and, and plant managers. And obviously the service part of it where if the customer has an extended warranty or extended service contract, then it's what we call a service level two colleagues help them to really domain experts and engineers.

And it can go up to the engineering department in the factories who actually designed your asset, the motor and the drive. So therefore, I mean there is a number of human users and technical accounts who needs to be considered inside of the app platform and part of the authorization system.

So what, what is needed? Various quick requirements. We of course need a flexible access model to cover all the use cases, although it needs to be to have a simple and, you know, user-friendly configuration management. The best thing would be the domain-driven way for sure. Speed is important, although latency is important. So micro microsecond response times or let's say one digit, although low one digit microsecond response times, it needs to be integrable into both Siemens ecosystem and our, our C F IQ platform.

And basically we, we do have a micro or distributed system with microservice approach, so it needs to integrate there as well. And last but not least, transparency and auditability is of course important because customers are asking for this. So part of the solution is sensible. For those of you who are not familiar with us, I mean, it's a paper from Google, it's about fine grant access control. Google uses it themself internally for as a single authorization system covering all the use cases. They do have, they released it as a paper, as a theoretical description, right?

There is, there is no product from Google you can use, but there is a number of open source and commercial implementations to it. And we're using one of them. Basically it's about relationships, right? So it's a reback system and it's all about how to model your relationship in the, in, in the database. In this example, this is how we can, we can store the relationship top of user. Bob is an owner of the folder, ABC, whatever. And obviously you, you can define your schema.

You are defining your, your resources and your subjects and you're defining your relations and the system and, and you're defining the calculated permissions and the system, obviously in a performant way. Make sure that for your applications and for your microservices, the permissions are available. So your application doesn't need to, to handle those traversing of the, of the graph of the relationship graph. And in this example, we, we see in a folder like graph with resources connected to folders which are hierarchically building up, up to the organization level.

And because our user has a member relationship to organization, obviously it is the computed permissions, let him read all the resources in the, in the tree. And because the user has a reviewer relation to one of the folder on the second level, it is, he has a, an added permission on, on, on two of the resources. And in this example, we did an, an owner relation to the, to one of the folders. That's why. And lead permission to, to only the single resources is calculated here and then up to Roland for the issues. So you can, you can, you can have several obstacles with this approach.

So the first is that you, that make common patterns can be hard for everybody in Boston, the project, because with Reback you have to think about everything in form of relationships. So this can be challenging for people involved in the project because often you are confronted with requirements like create a new user, create a resource, but you just can't do this with reback out in the middle, in, in, in the, in, in the vacuum because it has to be expressed as part of a relationship.

So you can help yourself with this by creating a system tenant or a tenant resource you can use as root or context of your authorization system and just link the new resource to that resource. So for example, you can create a user attached to the tenant or as an owner of a resource. The same is true for, or a sim similar edge case as deleting resources because an application may not be aware of other relationships. And like in this example, when you just delete the resource, the folder resource, it may lead to a, a situation where descendant re resources are hanging loose.

So just be aware of these kind of situations and consider how to handle them properly without breaking your authorization system. The second obstacle is about searching with permissions. So keep in mind with rebeck sandbar approach, all your authorization data is separated from the application. So how do you handle a search search operations in your application when you have millions of records and you want to respect permission on those operations. So for example, doing a full text search on your database. So you have basically three different strategies to handle that case.

So for example, the the first one is that you just do your search in the, in the applications and for all the results you'll check to the Zanzibar or Reback engine if the user has to read permission on that. And the second one, well this obviously leads to many individual check requests. The second option is that you first ask your reback engine, Hey, what resources can the user see receive then and use them as part of your filter query. Like in this example, well this leads to excessive queries in your application database. It performs well with low numbers, but it has, its, its issues.

And the third strategy is to build an index in your applications database on use that index as part of the search query. So the first two options, they work well with a, with a low number of resources, but they don't perform well with large numbers. So the third option requires an additional service which uses the, the watch interface described in the Sani part paper, which is basically a subscription service.

So the, the, the indexing service can use this and gets informed about changes on relationships and can update that index. And you can see here an example how this is used. So in in the database we have an in, in our applications database, we have have an additional column which can be called perm read, which just contains the list of the users that have read permission on that resource. And on runtime you can add the user bob as part of the filter query. And this performs way better than the first two options. So these are the three options.

But well, to summarize our, our exam, our experience with Zanzibar and Rebag approach is that it's a powerful authorization model reback, it's generic and flexible enough that you can define and tailor your own authorization shima and integrate this in into your application. And this is great. And due to the graph approach, it's well suited for typical cloud environments where you can scale, scale up and you need more resources.

And well, you can expect good performance from that approach. Well, but it's not only Zi bar because, well, Zi bar is nice, but in the end it's just a database for authorization data. But in practice you can be con confronted with requirements or use cases that require an authorization policy that's beyond you can, beyond the things you can express with a, with a reback approach.

Like for example, context-based metrics where certain action is only allowed when certain conditions met, like we are in a certain timeframe frame or certain values have to match in order that the authorization requests can be fulfilled or you have different constraints and requirements that must match for an authorization decision. And this is where policy based access control comes into play. So just a few words, policy based access control or feedback is where you have a set of rules that form your policy.

And the policy decision is just created by evaluating the policy at runtime, by inputting your context data. And the open policy engine you already have heard about it's a water rating software. It's a modern and remarkable implementation of the policy based approach.

And well, it comes with a declaration of language called Rigo you can use to author your your policies. And in the end turned out that using OPA as a policy decision engine is a valuable able extension to our reback sanbar approach. And this is how it works.

So in, in our architecture, the application never interacts directly with the Reback engine, but only over the policy decision point. And to do that, we have two kinds of different policies implemented. The first handles all the reback actions like checking for permissions, looking up or even updates. The second kind of policies are used to implement domain and application specific policies. So in the end, the benefits of this approach is that we have a single point of authorization that is capable of doing everything you can do with feedback and feedback in just a single instance.

And of obviously you can, you can decouple the decision enforcement policy authoring and decision making from the application, which in the end helps to reduce the complexity in the, in the application. So here you can see a simple example of such a policy. So the first part of that policy is the reback part that interacts with the sanbar reback back backend and checks. For example, if a user has, they read permission to read a certain folder and this policy is calling a sub policy and that evaluates true if the user has actual access permission to that resource.

The second part of the policy is, for example, a context based policy which evaluates only true of the local time is between 10 and 6:00 PM And the third part of the policy is evaluating true if the prior ones evaluated true. So this is our policy and it combines two different approaches just in a single, in a single policy and it's reusable for us. So this finally assembles together in the the following big picture where you, we have our application that holds all the resources we need to protect.

We have our policy decision point which implements all the, the policies we need and which is used by the application either a sidecar or as a singer application and does all the authorization part. And of course we have some kind of central policy management engine or back plane, which is used to distribute our policies to all the instances of OPA we have and which also collects health metrics and decision locks. So we have a single instance where we can look up for decisions and our, our OPA instance are, are living.

And the second part of our authorization core is the reback service, which holds all the permission on our resources and which is used by the PDP as part of the policy querying. And last but not least, we have our permission index service, which is used for solving the search with permission problem and it uses the, the watch and look up interfaces of the sandbar or REBA engine to gather all the permissions and update those in the application. And it's also used by the policy engine to help the application in how to use that index actually.

So this finally we, we can say that Sanbar rebag approach is, is awesome, it's powerful, it's flexible, you can justify your own model, but it takes some time to get used to the concept of relational access management. And of course it's always a good thing to decouple policy decision from policy enforcing and policy authoring from the application. So you don't have to have all those if then all statements in in your application code. And together with opa we can make use, we can make use and we can make augmented use of the reback approach.

We can combine, we can combine and check for combined permissions in a single request. We can have contact based policies and we can also secure the reback engine itself and check for, for valid changes and, and updates. Yeah.

So in, in the end we can make a greater use and have a greater coverage of use cases with this kind of architecture. So finally we can say that the, the reback or feedback may not cover alone all our use cases, but together the chances are good that we can cover at least all use cases. So thanks for listening and I hope you enjoyed the chat. Thank you very much. And Roland, anyone questions? Thank you. Great presentation, good architecture. We like it with Topaz too.

One question, you had data zanzibar dot check, did you implement that as a HDP send or did you create an OPA builtin and compiled your own OPA engine? No, no, We did, we didn't exi extend the opa.

We, we are just using the standard functionalities of opa. So we are using the HTTP interface and use that to communicate with the reback and we can also implement caching for that. So if we have expensive queries where, where we expect a couple of thousand results, we can use an we, we can check cash, the results if we need to. So it's just standard interfaces.

Hi, nice presentation. Just a question, can you share what you are using as a PDP manager Currently we are, we are planning to use this Tyra Tyra dashboard for that as a management or a controlled back plane. And we actually have one more question from the online audience as well. They are basically asking how are you dealing with the least privilege access? Well this is part of the user management and on the, on the policy, but it's, it's not really implemented in, in the, in the Reback model. Hope that helps.

Okay, great. Well thank you very much. I think we have to wrap up and.