 Hello everyone, my name is Omri Gazeet. I'm the co-founder and CEO of Asurdo and I'm excited to spend the next 20 minutes with you talking about modern authorization. So let's talk about the state of affairs in identity and access. In the identity world things are pretty good. We've largely solved the problem of single sign-on for SaaS applications. No one remembers days anymore where users had different user IDs and passwords for each SaaS application because now we have single sign-on systems and so anytime you add a user to your single sign-on system they have access to applications and every time you add a new application if it speaks the right protocols OAuth2 and OpenID Connect and SAML and JWT then those users are able to go log in automatically. Not so for access control. Access control is a total mess. It's what I call an n times m problem because every time you add a new user or add a new application you have to manage the cross product of basically granting permissions to these applications to all these new users. It is a completely terrible state of affairs and I would argue it's the number one issue that we face in the industry in the identity and access management industry. Now it's not all bad news. Authorization is finally finding its moment in the sun and the good news is that the large technology companies that typically are the leaders in the space have spent a lot of time and attention on their own internal authorization systems and have been kind enough to share all of their lessons and so now we get to learn about all the best practices of authorization. Google wrote a paper called Zanzibar about their internal system so they didn't do it about their system called AuthZ and so on and so forth and so we can basically look at all these new patterns and learn a lot about how to solve this problem once and for all. But there's also bad news. It used to be that the technology landscape in authorization was simple you had RBAC as a model, LDAP as a protocol and now you basically have a complete cacophony of acronyms and technologies and models and protocols and enforcement points and implementations and it's very difficult to make heads or tails of this landscape. Not to mention a whole bunch of vendors. It used to be back when I was at Microsoft. We had 90% share of the directory market and the rest of the LDAP vendors had their other 10% and now we have an explosion of vendors each with their own approach to authorization and so even though I've stated up front that authorization is the number one problem that identity and access teams face today, they're all frozen because there's just so much noise in the market both on the technology side and the vendor side and so in this talk we are going to try to simplify all of that and create a framework for how to evaluate both technology and vendors. So let's break it down. Let's start first with the technology landscape and then we'll turn our attention to the vendors. Modern authorization really boils down to five patterns. If you read about all of the different papers that I put in the notes before, they all do like all these five things in a modern way and so I'll first go through all the anti-patterns, how we do them today and then talk about the best practices that we need to evolve to. The first one is of course each service or application does its own authorization and we know why that's bad, end times and problem. The modern way of doing things is building a purpose-built authorization service that you can extend across a bunch of your different services and applications. Now of course the large technology vendors can afford to build their own custom one and the rest of us need to go build on top of open source or maybe buy a technology solution. The second anti-pattern is to use the old practice of coarse-grained rolls and so you either have over provisioning of permissions or you have roll explosion and the modern antidote to that is to practice some form of fine-grained access control and there are a few different patterns for that. A-back, re-back, we'll cover those next but the important thing to remember is that you really want to adhere to the principle of least privilege so that you only grant the smallest number of permissions to a user to be able to do their job. The third anti-pattern is basically baking authorization logic as if or switch statements in each one of these services or applications we call that authorization spaghetti code and the modern practice is to extract the authorization logic out of the application and store and version it separately in its own document in its own policy thereby enabling a practice we call separation of duties where the application developers focus on the application logic and then security engineers focus on storing and versioning and maintaining the authorization policy. The fourth anti-pattern is treating scopes that are baked into access tokens as if they were permissions that's bad for a number of different reasons much the largest being of course that these access tokens survive for hours or days and by virtue immediately are essentially outdated versions of what a user can do and the modern antidote to that is to make a real-time call to an authorization system with a user context the permission and the resource context and find out whether this user has access or permission to this resource just in time and lastly today most applications if they even have decision logs do it very inconsistently the modern practice is to standardize and centralize every decision that every application makes into your locking systems for forensics and compliance. So let's focus on these three middle ones that I bolded here fine grained policy-based real-time which are the most important characteristics of modern authorization first let's start with fine grained authorization we now see two ecosystems emerging in the cloud native landscape the first one is based on the open policy agent project I like to call this camp the policy as code camp they're focused on abac attribute-based access control as a model and there's a lot to like about opa first it's a cncf graduated project cncf is the closest thing we have to a standards body in the cloud native community there's a single open source implementation it's a general purpose flexible engine and it's tailor made for policy-based access management it is the successor to example many people say exact moles dead if it's not dead it's dying and opa is going to replace it there are some indices though the language even though it's not angle bracket-based it is still a difficult language to learn it has a high learning curve the language called rego it derives from data log you basically have no opinions that opa brings with it and so you're left to design your authorization model from scratch which is very powerful but it's like building an assembler and lastly opa has a policy plane but it does not have a data plane so the problem of bringing data to the engine is an exercise left to the user on the other side of the fence you have the zanzibar ecosystem so this is a set of patterns and vendors that have really kind of emerged as a call to action from the zanzibar paper and I call this the policy is data camp they believe in an opinionated model called the relationship based access control model and it's almost the polar opposite of opa where opa has no opinion zanzibar has zanzibar has a very specific opinion on how to structure authorization really as a relationship graph between subjects whether users or groups and objects there are things like organizations departments folders and files and so on so if you've ever used google docs and you've granted somebody viewer access on a document or editor access on a folder or comment or or owner you've now essentially kind of used the the the zanzibar model now there are some drawbacks as well there isn't one open source implementation google didn't open source anything they didn't even create a specification they created a technical report and so a number of vendors at least half a dozen of them have created their own interpretation of the zanzibar paper and open source those so there are many different open source implementations there's not a common schema or a data language and it is hard not impossible but hard to go outside of the reback model if you want to use attributes and there's now emerging a third camp which is the let's take the best of both worlds topaz from asserto is an open source project that attempts to do exactly that which is take the best of opa and zanzibar and marry them together into a single open source implementation and there are others that are starting to look at that approach as well next let's talk about policy-based access management and as a reminder this is the practice of lifting the access control logic out of the application and storing and versioning it as its own policies code are effect and so here i show a an example of a policy written in rego that is the surface syntax for opa or topaz it doesn't have to be that it could be a zanzibar manifest but the idea is that you're lifting out all these rules and storing them separately and thereby the application becomes a lot easier to build and maintain here i'm showing a nojs application that has a route handler that just has a single middleware here called check out c that will automatically call the authorizer with the user context and the resource context and the permission and find out whether or not this user has access to this resource and succeed or fail the operation based on the results of that and so of course the benefits are that you can treat the authorization policy just like you can any other code every change to the policy is logged and maintained as part of a change log and the policy can be evolved by the security team independently of the application code and the third pattern here that i want to get into is real-time access checks some people call that dynamic or just in time or real-time uh these all mean the same thing which is the application should call the authorizer right before it grants access to a protected resource as opposed to relying on stale scopes in baked into access tokens um authorization if you're doing it in the critical path of every application request really has to be a local operation it has to be a hundred percent available to the application and it has to be done in milliseconds so the only option that you have is really deploying the authorizer right next to your application and you want to compute the decisions based on data that's local to the authorizer that said you want to compute decisions based on fresh data and that's where this really becomes a distributed systems problem you want to maintain and manage all of the artifacts used for authorization in a central manner so for example users uh the uh the system record for users is an identity provider you want those imported into the control plane and then distributed to all of the authorizers that are hooked into that control plane so that anytime you add a new user you automatically have that data available in the local authorizer likewise policies should be stored in version and source control but then anytime you have a change you want a policy as code workflow to build and then distribute that policy to all the edge authorizers and finally you want to be able to gather all the decision logs from the edge and manage them centrally in your logging systems great so we talked through all of the technology landscape and now let's break down the vendors in the space along a number of different dimensions that we think are useful now i'm not an analyst i i may play one on tv uh but i will put that analyst on for the next couple minutes but first a disclaimer um i this really represents the best effort research that we've done in asserto to best characterize where all these vendors lie on top of these dimensions if we've gotten any wrong please let us know and we will of course fix it and make it right um also it's important to note there's no right or wrong here it's just a good starting place if you're trying to evaluate which vendors essentially do things your way and match up to your requirements so let's jump in the first axis that we want to talk about is it centric versus dev centric and this is not to say that you know only it your only developers are involved but in the it centric world it brings the solution to solve a problem for the entire organization in the top-down fashion they still need developers to implement it most often and in the developer centric world engineering teams bring the solution in to address requirements for a particular application or a set of applications they still need organizational buy-in uh from all their different constituencies but the it centric uh you know vendors in the space include all the folks here on the left that really focus on solving the problem for an entire organization whereas the developer centric solutions and here i'm actually carving it out further into three different personas we have mortes and elvises and imstines i use this taxonomy from microsoft it was uh what we used to represent three different types of developers that roughly map to visual basic developers c sharp developers and c plus bus developers so uh on the mort scale uh is permit they focus on low code or no code authorization they try not to expose the authorization policy itself as code uh the middle column is a set of vendors that really try to make it easy but also uh make a flexible solution that exposes the authorization policy and allows you to think about it as code and then on the right side we have um einstein level vendors that really uh offer you technology that's very powerful very flexible but you really have to be a power user in order to uh use it effectively and i've put styra in the middle here because even though they're a top-down type of solution and that often is sold uh at the organizational level they also have an open source project opa of course that brings them in oftentimes in a bottom-up way the second dimension i want to talk about is authorization model and so um all the way on the left we have what i call the r-back plus model which is really multi-tenant r-back permit again uh owing to simplicity once you uh basically optimizes for that type of model uh and while you can add attribute based access control it's they orient to you towards a simple r-back model the next column is a set of vendors that focus on the a-back model attribute based access control service is one of those cloud entities started with opa uh and so they are an a-back vendor plain id started with exactly so of course they are an a-back model and then styra of course invented opa and so they also adhere to an a-back model the third column here is vendors that focus on the re-back or graph oriented model the first four of these set out to build implementations of the zanzibar paper so they're very re-back zanzibar centric um and the other two signal and veza are really they don't talk about re-back or zanzibar but their internal data model is a graph-oriented structure so i put them in that column and then lastly there are set of vendors that think about uh trying to merge some of these models together asserto and scaled access started from opa but then added powerful graph oriented capabilities that are based on the zanzibar paper and then also actually started before zanzibar was published but they also have a flexible hybrid model and then the last axis i want to talk about uh there are at least 10 of them but we only have time for three is uh proprietary versus open source the licensing model on the left hand side you have a set of vendors that may use open source in their offerings but ultimately they don't open source their own engine and then on the right side you have a set of vendors that are really open core they've open sourced the core engine uh and then built commercial solutions on top and then i put permit someone in the middle because they are built on top of opa and they have open source portions of their solutions specifically the control plane but their core authorizer is not open source so i kind of position them in the middle so we've gone through all of these different axes all the ones that we've had time to do so now let's position asserto on on top of this technology landscape and uh what we actually focus on so we strongly believe in fine-grained policy-based real-time access control uh we want for fine-grained we want to support all these different access control types our back a back and re-back so we've created a model that stretches across all of them uh we've we believe in policy-based access management uh policy is expressed as a combination of rego as well as a zanzibar manifest and we have a distributed systems approach to authorization where authorization is done in real time locally but is managed by a distributed control plane and of course uh we offer uh compliance and forensics through centralized decision logs and on top of that we are a very developer-centric solution so authorization can be added with a single line of code it integrates easily with identity providers and source code repos and logging systems and finally we strongly believe in an open core model so asserto is based on the topaz open source project and is built around the cloud native ecosystem and that is it folks if you're interested in getting more of this content please drop us a line we're planning on expanding the vendor map a little bit and so if you're interested let us know and send us an email we're gonna add us add you to our mailing list so that we can send you the research as it becomes available thanks so much for listening and i hope you enjoyed this