 OK, so I think we could start. And if other people join, I hope they will not miss the fun part of the story. So I have a confession. I'm addicted to elite statuses. This is a partial list of the statuses that I hold. And one of the most valuable statuses for me is Hertz President's Circle. And the reason for that is selection airports in the US. You can rent a compact car and then get whatever you want from a lot. And if you have luck, so you can get a nice Porsche or whatever it is. The way to get President's Circle is do 15 rentals a year or spend $3,000. I am in the US for five times a year. So you probably ask yourself, how did you get the President's Circle? And the answer is broken access control. There is a way to get the status. So if you have a Amix Platinum card, there is a promotion of Enterprise Currentall that you can sign up and get their elite status. And then there is a website for freaks like me called statusmatch.com that tell you which companies match status to which one. And then I saw that they match to Hertz. And I match my status to Hertz. But I don't have Amix Platinum. Because Enterprise is not validating the Amix number that you enter. So you can enter whatever Amix number you want at Enterprise website and get the status. Right. And broken access control is actually everywhere. If you look at the top 10 OWASP vulnerable list, you can see that from the beginning day of 2003, broken authentication was there. And then the broken authentication became broken access control because we kind of got control on how authentication works. So the authentication wall today in application, even it used federated identity. So when I'm logged in to my organization resources, I'm using my Google identity. And yet I can't get there. Because with the world of cloud and services, there is a lot of authentication services that let you securely authenticate. And then the broken access control now is on the authorization part, the step after authentication. And this is why if you speak with every startup founder or developer that start, develop a new product, they will tell you, we will do RBAC later. This is a center that I heard from a lot of friends and colleagues in the industry. We will do RBAC. RBAC is role-based access control. And the reason for that is they prefer to stay in the comfort zone of authentication. Because it's easy to know that the user is who declares who is, right? I can use password, which is not that safe, but I can use it. I can use biometrics. I can use MFA. I have a very easy way to verify who the user is. And this is the comfort zone of auth. But when I need to know what a user can do or cannot in the application, it certainly became complex. And we can see it from this sentence. So people say, we will add RBAC later. Why RBAC? Why later? Why couldn't you now just create something that will let you know what your users can or cannot do in your application? And the stories always start the same. The ticket with this title is a generic ticket. You can find it in many, many ticket system, no matter what ticket system it is. The title is always something like add RBAC to application. And I can tell you, it always ends the same, right? And today, I'm here to try to make you better. And you probably ask yourself, why you? Why you will tell me how to do authorization better? So short about myself, my name is Gabriel. Now I am the director of DevRel of Permit.io. Permit is a startup that does authentication in application level. We have a cloud service that provides developers a very easy way with single lines of code to implement the rich permission models into their application. But I actually already surviving authorization for eight years. I started work at Cisco in 2015 on a product called Identi Service Engine. This is actually a server that let network user authorize themselves to the network. So authorization is everywhere around us, right? So we authorize itself at physical doors. We authorize itself at the computer, right? I can do or cannot do something in my laptop. We authorize the self and networks. And we authorize the self at the application. And I made all the journey. I work after at Palo Alto Network in a SOC operations, security operations, control rooms operations. And then most of the incidents was about access control and then people asking how could I automate the process that make sure people authorize and getting to where they should get and not getting to reasons that they shouldn't get into. And now I'm working with Permit. So I know a bit about authorization. And I want to tell you a story about Jesse. Jesse is the most generic developer around here. And he's just a junior developer and he got this ticket, right? Please, Jesse, our back to our application. And Jesse is very enthusiastic to clean code and he'd create like a framework in their generic application, but look this way. Look like this, right? So here we can see a middleware. Middleware is the function where every endpoint will pass by. And for every endpoint, the developer should add authorization with the word admin or whatever role is it. The middleware is pretty simple, right? Took for Jesse less than a sprint to get RBAC working in the system. Everyone was happy, but then and your requirement came. Okay, and then Jesse need to support multiple roles. Not only one role for endpoint, there are endpoints that need to get access to admin and another role to it. That's a small fix, right? So another two day in the next sprint and he just bring a better RBAC framework to the team. But then another feature came, right? The PM like love to get features and then they asked them to authorize people, authorize the user, but their attribute GDPR GDPR came to the place and then some of the endpoint is accessible or not accessible for user who are based in US, in the EU, right? And then Jesse take the middleware, think a bit more and then implement something that's similar to what we see on the screen. It check if the arguments is role or the argument is attribute and their value and this is how he authorized user. Okay, and then another feature came because this is how things looks like in software. Now Jesse got required to support also inspection into resources. So not all documents makes the same, right? There are documents that belong to someone but there are other documents that belong to someone else and with the traditional middleware it became really hard to support it because the middleware is always inspecting on the users themselves but Jesse is actually creative. So what he does, he create like a new service and now even got promoted because he developed the RBAC layer of the product and this service knows how to detect the attributes in the endpoint and allow or not allow the application user getting into resources. But as you can see it's problematic, right? We can see that the code is not clean anymore. Everything is mixed around. It's hard to test. It's hard to detect where access control is broken. And the first mistake that Jesse does is implement RBAC to application. The way we need to think about authorization is not RBAC anymore. RBAC is something of the past. We need to think of enforced permissions in applications because permission is much more than RBAC. Every permission statements start with three principles. User, action and the resource. See user can be just a username but that could be a huge set of attributes, right? Our users today, for me, user in my application, I have them data on Stripe to know which paid tier they are. I have the data on my CRM. I have the data on my database and my database is distributed, is decentralized. The data about user and about resources is decentralized today. We cannot think of the traditional implementation details of role and resource. We need to think on the principle of what we want to check and this is actually the three principles we want to check. And then the check itself looks like this. Does a user is allowed to perform an action on a resource or does a man can allow to eat a banana? And again, a user could be a huge set of resources for many, many systems. And to know how to do better, let's take a look on how permissions model looks like. So there are four known permissions model in the application level. ACL, RBAC, ABAC, and REBAC. And we will look at each one of them in details. ACL, I call it end-of-life model. It's driven from IT authorization. It was in firewall, so I want to configure which user at access to the network. And it's like holding a huge list that's titled with the resource and then who is the user can get to it. The problem with ACL is that is completely not scalable because you cannot manage relationship between resources and principles. And second, you're probably really hard to scale into actions, right? So if you want to do different actions, you need different lists. And in my perspective, it's not useful for application. The other one is the default, is RBAC, World-Based Access Control. We are assigning roles to users, right? And then we are deciding to which resources they have access for which particular operations. This is very easy to use and it's also very easy to audit. So if you want, for example, know why authorization decision happened, it's very easy to implement a code, to check which role was to the user and why he got this decision. The most advanced one compared to RBAC is ABAC, Attribute-Based Access Control. So we understand that user has attributes, could be a very deep tree of attributes and the resources attributes. And we want to correlate condition between attribute resources and the action between and decide stuff, right? So it's really small here, it's hard to look here, but we can see here that we decide that Joe can drive a car because he has a driving license and he owned that car, right? So ABAC is the most comprehensive permission model, but it's hard to implement it. The reason it's hard to implement is, first, you need to orchestrate. Second, you need to streamline. You don't want to do like a mess like we saw that Jesse does in the code that lot of if statement. We need to find a way to implement ABAC better and we'll talk about it later. The other one is very common in consumer application, consider RBAC, Relationship-Based Access Control. So for example, if I'm now a Twitter, I can see my tweets, I can see tweets of people that I am following and I can see tweets of people that are public, right? And it's all based on relationship. When you need to be at scale, this is actually the only one that work because if you, for example, need to travel a slot of attribute per users, it's hard to traverse. So in the RBAC, we are kind of storing the relationship between users and resources and get the best decision we can get. Well, let's back to Jesse because you now understand that he needs ABAC, but then he implements something as we can see here and then a bug came. A user get access to somewhere he shouldn't get access to. And Jesse just tried to debug it and then he find this code and he find a very smart developer, decide that the framework is not enough for him and he decided to create, mix the policy inside the code. And this is actually the second problem in home-brewed authorization. You should separate the policy from the code because you need one way to track your policy config. You need one way to track the audit log. I want to know why a user get now a decision. So we need to find a way to centralize the policies in decentralized system. And this is another problem when you develop it yourself because it's hard to be decentralized without spending tons of hours of developers work on it. And also Jesse have now a new stack because the DevOps need their own authorization because they are now deploying automatically setups and some of the setups has access for particular tenants and other setups has access for different tenants. And also the front end developer want to show and hide some features for different developer because there are, for example, similar paid tiers in the application. And there is the database guide that need their data to have that separation for user can access to it. And it just so and so forth a new service could be in a language that Jesse don't know. So we need to find a way also that it will be easy in the modern world that we are all developing application in a very different stack how to implement better authorization in our applications. And also it has another skill set because now the authorization service is lacking performance and then you need like user management screen. So you need to develop where I configured all these policy screens. You also need an operation, et cetera, et cetera. And also it's got like kind of headache because they got compliance need and then you need to create a lot of reports around what a user does. And also they need to create a policy posture which is important for a particular set of authorization decisions. So looking at that problem, we are looking now for application level authorization system that has these five principles or best practices. First, it should be agnostic to the permission model. We want authorization system that will be agnostic if we do RBAC or ABAC or REBAC. We want it to work with everything as much as it can. And we also want to separate the policy from code because we want the decision itself being very generic. And we want to support the whole stack. We don't want that if, for example, now we have a service in Rust or Python, we need to develop the whole solution again. And we need it to be performance aware, right? Because if, for example, we have API endpoint, we cannot stack the response because we need to get now a policy decision. So a policy decision need to made in like sub 10 milliseconds, okay? And we want also the policy management to be unified, okay? And this is where we're trying to look today, how to build a better authorization systems for our applications. And the first thing is looking on contracts. So to create better relationship, we need to create contracts, right? And this is the way it work in software. If you look on the most popular software, they are popular because they define very well how do you write software? We look on the popularity of software, of programming languages for the last year. So personally, I really love GoLang because I feel it define the contract that they have with the software. It doesn't have thousand of ways to do stuff. I mean, it has, you potentially can, but when you look at the code, you understand how you could look like. And in a policy world, what we want to do with contract is having programming languages for policy. So today we are going to talk about three contracts for policy. The first one is Open Policy Agent, which is now the most popular one that you may know. And then we are talking about a new language that AWS released as open source just yesterday called Cedar. And then we will also talk about Google Zanzibar. Google Zanzibar is actually like a protocol, it's not an implementation, but we will also show an implementation of Google Zanzibar and how it work. So let's dive into the contract of Open Policy Agent. Here we can see a declaration of policy as code. It's pretty complex and I explain soon why, but what you can see here is like, the first one is like importing, et cetera. And then we say the default is allow false. Okay, we declaring that no one should access anywhere. And then we are declaring a user is admin, which is like if admin is in the user role. And then we can also see the role themselves and then give a grant if a user include a particular role. And we can see a pretty complex A-buck on the left side of the screen, right? This language called Rigo, this is actually the language that Open Policy Agent use. Open Policy Agent is around from 2016, I guess, and it's very mature in the cloud native world. But Open Policy Agent also has cons. The first one, in my opinion, is also it's big bra. Rigo is a complex language. It's not easy to archive stuff and it's designed for to be the multi-purpose as it can. And as well, you can see that a lot of people use Rigo for admissions. What is admissions? Like which service can access work? Where are we deploying our services? When you get to do application authorization with Rigo, it got hard. And the worst thing about getting hard with Rigo is writing an efficient Rigo because now you're writing software. And when you write software, you get bug. And bug mean latent performance. And then it's very easy for developer that we meet that they say we started to write Rigo but we don't have a way to analyze it against our application because it's so multi-purpose. So we don't understand how to create better application level authorization with Rigo. Yet it is very popular. I mean, I'm living the OPA landscape for the last, again, eight years and I can understand why people like it. One of the benefit of being that all is the ecosystem. So you have plug-in for everything in Rigo. So you want to control access on databases. You want to control access on Kubernetes. You want to control access in GraphQL, whatever it is you already have a plug-in that you can plug-in play. Yet it's hard to maintain and hard to get authorization decision on applications with it. AWS Cedar, and for me, this is one of the exciting announcement in the last year, is the first policy language that designed for application needs. So what AWS came and said, we saw that in the yam area, in the cloud declaration area, people are using policy as declaration and we believe that application developer should declare policy too, right? Should write policy in contract. And if you look here and you remember the principles of application level authorization, you can see that every authorization sentence start with the principles. So first is the principle, they probably the user, and then you have the action and the resource. And then you declare very easy, how do you identify the permission that you want to give now? So for example, here we can see only permit sentences, but we statement, but we can also have like deny statement which do the opposite. And we can have forbid statement which is like a DEF CON policy. No one can do anything even if they are permit. And in my opinion, the way that AWS come and say, we believe that application developer should start declare policy instead of just coding in imperative in the code is a start of a new era, a new era where applications get much better access control because policies manage right. Okay, and then we can talk about Google Zanzibar. Zanzibar is a paper created by Google that describe an efficient way to manage graph-based authorization. So remember Reebok relationship-based access control, Google has billions of users. Billions of tenants and billions of relationships, right. So for example, if I'm looking in my organizational Google Apps user, I want to get access to everything related to my company, everything related to my team and everything related to me. And if Google want to give a really fast decision why I should go for example to all the documents that are related to my main organization, they need to store this graph somewhere. So Zanzibar is also a contract definition but also a database definition. One of the most famous implementation that I particularly like, there are a couple of other implementation of Zanzibar but in my personal opinion, there is a project called OpenFGA. And the reason why I like OpenFGA is first it has a language. It's not that easy language, it has a very complex schema to declare the relationship in other hand. But in one hand, but in the other end, after you're declaring it and deploy the databases, the graph databases of OpenFGA, you can have a very nice decentralized Reeback relationship-based access control decision-making. But there is also a problem with OpenFGA. First, it's very hard to implement RBAC and ABAC and particularly in business application. The best permission models are RBAC and ABAC because traditionally this is what developers know and also the usual workflow in business application is do role-based and attribute-based. But it has also reverse indices support. So as I mentioned, I can look in my parent of my parent of my parent and find a relationship for my user to the resource. So this is a huge benefit. It's backed by Octa. And another problem in my opinion is that it's stateful. You need a database. Indeed, databases grow very easy. So if you just start and you have a lot of users, you need to deploy more and more and more instances of this graph DB and this graph DB should be decentralized. We always like to, we have like internal jug that Google can allow themselves to do Zanzibar because they hold the internet. But for anyone which is not cloud provider, there is no reason to do Zanzibar. It's not that true because sometimes you really need in a relationship-based access control but important to know. So now we understand three types of contracts which are popularized today. Let's go to the next step, right? Architecture, how should look authorization system for application level looks like today. So this is the building blocks of a modern authorization system. Actually, it's not that new, right? When we develop network authorization, we use the same building blocks. The first one, and I'll go from apps there, is the policy enforcement point. Policy enforcement point is everywhere now in your application when you want to enforce policy, right? You have like API endpoint, you have even a screen and there is a place that you want to get one question. Is this user allowed to continue or not? This is the enforcement point and one of the most we'll get after to each one to the list of each one, what they can and what cannot do but for me the most important part of the enforcement point is shouldn't know what the policy is. Enforcement should know what is the decision, know why it's get, know what the decision is and this is the only way to keep the enforcement point clean and let the authorization system to scale. The second is the decision point. This is actually like decision engine, get a request with the three principles, user action and resource and return a decision, allowed or not allowed. Sometime you will want to have like non binary answer like a string or something but usually for most of the purpose of application level authorization is true or false. Then you have policy retrieval point. Since we are writing our policy as code, we need to get this code from somewhere, right? And we also have the policy enforcement information point. So when you get policy decision, the decision got a limited set of user attributes. For example, if we using JWT, JSON web token to authorize a user, we get a very limited set of user fields but we need to know more about this user, right? We need to know which page they are, we need to know where they live, we need to know if maybe fraud detection, whatever it is, we need to have more and more sources to know stuff about our user and resources. This is what is the policy information point and to connect all these pieces together, we need also policy administration point. Policy administration point is the point that make sure that all these three pieces got together, the policy engine, the decision maker, the information point and the retrieval point. As we said, policy enforcement point and I'll say it again and again should be a very clean abstract way, right? To check policies. In Reback specifically, we will want also to have a list endpoint, an endpoint that we send the user and get the list of the resources and the reason is because Reback is actually stateful, we can hold in the graph DB a traverse of what this user can get to. Decision point, so if you're familiar already with, let's say policy, with Open Policy Agent or CIDR, is actually the agent itself. That's a piece of very efficient software that know to maybe cache data or just look at the policy configuration and get a decision for you, okay? And we want it to be in low latency, we always wanted to leave inside our application or not application code, but inside the deployment or something because we don't want the latency where we go to get the decision. Then we have the retrieval point, usually Git repository. The reason that we are like to use Git is all the GitOps methodologies that we see is the way to make sure that we always as the most reliable policy configuration in our policy engine. And then we have the policy information point. So in my opinion, in a modern world of authorization, we don't want one point because one point cost us cost deployment, cost maintenance, cost cloud code, right? So policy information point today is more abstract way or declaration way to declare where I need to data to get fetched into policy decision point. And the policy administration point is again the one that connect all the three pieces together and potentially it also has like the operation part of the PDPs. So for example, we have like PDP for each application. We want the administration point to make sure it auto scale them and that they are always keep updated with the data of the policy and the decision point itself. And we want to do open source. This is an example of architecture of open source modern authorization system. So first, we have like, we'll start from up there, right? An application decision getting being. And then we have like APL code. So the enforcement point is usually just one API called to the decision point. Decision point is a CDER engine and we also in permitile develop an open source project called CDER agent, which let you deploy it as a container, auto scale it and also has a nice memcached component inside that help you to catch your data. For the application, for the administration level, there is a tool called OPAL, open policy administration layer, also created by us and maintained by us. And open policy administration layer, it's actually a server client architecture where the server that you can see on the left side is make sure that it always synced in a GitOps flow from the Git repository where you hold the policies and it also deployed together with a client. The client has two main component. The first one is the data fetcher. Data fetcher is like, we already got contribution for a lot kind of data fetcher, like data fetcher from past grass, data fetcher from stripe, data fetcher for whatever you need data on your user. And the other part is policy agent themselves, right? The PDP. In this way you get with only, so OPAL is actually deployed as containers, so you only need to declare your configuration for OPAL. So when you run OPAL, you tell them where the policy sits, what is the Git repository. You tell them where and what one to deploy from the policy decision point. And which one? In this architecture we see that we're deploying, we can deploy either Cedar or Open Policy Agent and we also trying to develop support in more policy engines. You can configure the data fetchers. It's just like environment variable. And then the application itself has a very nice generic API to OPAL. So the thing today, you have like different protocols when you do authorization call from Open Policy Agent or from Cedar, you need to do different API call, which mean dirt your application code with a different code. So OPAL is also exposed like an API layer on top of all the policy engines and let you give you a very easy way to make the calls to the policy engines themselves. Then we also need to understand the policy enforcement points, right? So we describe like we have like backend APIs that just call another API and ask for a decision. And we also have like in persistent layer we can see a lot of DB plugins that came into place and you can just plug and play. So you plug this plugin of the enforcement point and they know how to make all the connection with the authorization part that you need to get decision based on. And the admissions, this is a very mature landscape. You have like the admission control of Kubernetes. You have like the Terraform provider or also whatever cloud provider that you're using to deploy your deployments. You usually have how to make sure that everything is right from authorization. What about front end, right? So we mentioned front end developer wants to to get a better authorization decision. There is a protocol called CASL and it actually define how could you actually download policy configuration and then in a declaration inside your application code made only the enforcement part, right? So it also has supporting react and view and Angular and for almost every modern language. You use CASL, you do the API request whatever you want to the policy decision point or to your backend and use it for like more feature toggling, et cetera. Another tool that worth to mention is up toggles. This is another open source that we are maintaining. Up toggles is actually synced between feature toggling products like LaunchDarkly and policy configuration. So you can like connect it into your you can connect it into your open policy agent deployment and make sure that you always synced with the data there to what you show and what you not show to our user. We're probably late of time and I want to left time for questions. So I skip the demo. It's not that interesting and we have a booth you can come to see it here. So thank you. And we always love to get stars on Gita that your way to support open source and I really appreciate it. Questions? So you're saying Rego is to can be too complex. Mm-hmm. As track back complexity, you also mentioned the Google and do this complex. Yeah. How are you extracting that complexity? So this is not actually the open source part. This is our product, commercial product part. So we are like a auto generator code that actually generate from our permission model UI generate a policy code with, right? So if for example, you are advanced user that you already write some Rego code and you want to start to use permit IO as your authorization for application, we are giving you like best practices how to write your Rego code and then we can represent your Rego code in our UI in our product. So we have like auto generation of policy code from UI configuration. It is the main commercial product because all the opal and the way we are orchestrating policy engines this is open source. Yeah. So that's actually a great question. I'm speaking about policy as code for two years now, right? And usually I use Rego because that the fact of the language that everyone use and for every talk I got this question. Don't you think Rego is just cost too much cost too much to maintain cost too much to write with? And that's correct. And the reason for that is we Rego is not built for again for application level security. It's built for more admission, more multi-purpose. And then you have the people because the people that declaring Terraform, that's fine. They're also declaring Rego. This is in my personal view, this is why I'm so enthusiastic of Cedar because Cedar is simple to application developer. It think on the same way that application developer think. Zanzibar on the other end, it required skill and Google not try to lie on us. I mean, even open FGA, they say don't start with it if we need just a small application. It will cost you. Sometimes you need it, but again, I think it's better that you have like a chaos of authorization small portion everywhere, right? So it's a thing of balancing between you know, you want your software posture, you want software secure, and you want in the other end to the not have it cost. In general in software, what I believe when speaking about the cost of developing, so that's correct that we are developing much more software today, but we also bring much more functionality, right? Because if you look 10 years back, yes, we wrote much less good. We had much less developer, but we not develop that much software. And when we're looking about cost, and me as a company, right, I'm a software company, I'm selling software to developers, I don't want them to pay me more like I don't want to mention names of some observability companies. I want them to pay me more to deliver more software. I want them to be more efficient, right? And I believe the balance between the time you waste for detecting access control and the cost that a broken access control could cost and understanding of another kind of language, right? Because it's not a real language. It's declarative, it's not imperative. The balance is right, right? So JWT is actually has claims somewhere you need to do the checks against that claims, right? And there is two ways to do it. The first one is imperative code in your application, the do if statement, if this claim to something right, even if you have a nice, like we saw a nice decorator framework, at the end, there is an if statement to check something. And if some of the claims are not fit for your decision, a developer will come and write this hell if statement, right? And it's no matter the way you verify who the user are and the way you are sending the user representation to the authorization engine, you still want to separate the policy from code, right? So for example, when we're speaking about check, right? So most of Pyramid IO users, they are sending the JWT, right? The same JWT and our opal know how to parse it and get the particular attribute from it. And JWT also has some more problems. So JWT has a limit, character limit, right? And you cannot just put all your data in one JWT and sometimes the data is just from other system and then you need to connect a lot of system each other just for the JWT to be huge and hold more claims, right? So JWT is great for, let's say, federated identification, right? So for example, we are letting you set up your JWT case, right, the way you verify JWT and then you can send us your JWT without verifying it and we will verify it for you, right? So JWT is here and it's must stay here, including their claims. But again, if you want to be in authorization, the scale, there is a JWT is very limited. Generally speaking, yes. So when speaking of rule engine, I believe like engines that have streak for something, right? And they are not built usually for application level, right? They're built more for IT level of stuff and stuff like that. And we are speaking more about applications of developers that need to embed it. In my opinion, using external service for authorization is simpler than try to adopt the rule engine style in Torio application development. But again, I mean, there are solutions for everything. The way that we build authorization, that five step, right? Enforcement, decision, administration, retrieval and information is keep each of them clean and able to scale and also separate the concern between configuration, between data plane, between enforcement, et cetera. So we are also the maintainers of fast API, WebSocket, PubSub library. Yeah, so you can choose between TRPC or WebSocket, PubSub. Thank you.