Cloud-native authorization standards

Summary

Omary Gazit, CEO of Certo, delves into fine-grained authorization, contrasting it with authentication. He highlights the lack of standards in authorization, leading to security vulnerabilities, and emphasizes the need for centralized, fine-grained access control. Gazit discusses the evolution from coarse-grained roles to attribute and relationship-based models, advocating for policy-based access management. He introduces tools like Open Policy Agent and Topaz, promoting real-time, local authorization integrated with centralized policy management. Gazit concludes with the 'Five Laws of Authorization' for building robust systems, offering open-source projects and Certo's commercial solutions for streamlined implementation.

Takeaways

• 😀 Omary Gazit, the co-founder and CEO of Certo, has over three decades of experience in software development, with a focus on cloud platforms, identity, and access.
• 🔐 Authentication and authorization are distinct processes; authentication verifies identity, while authorization determines what an authenticated user can do within an application.
• 🛠 The authentication ecosystem is mature with established standards like SAML and OAuth, whereas authorization lacks such standards and often results in inconsistent implementations.
• 🚨 Broken access control is a significant security issue, ranking top on the OWASP Top 10 list, with 94% of tested applications having vulnerabilities.
• 📈 Modern best practices for authorization include centralizing it through purpose-built services, implementing fine-grained access control, and separating authorization logic from application code.
• 🔗 Relationship-based access control (RBAC) and attribute-based access control (ABAC) are evolving models that provide more nuanced permission settings compared to traditional access control lists (ACLs).
• 📝 Policy-based access management involves externalizing authorization logic into a domain-specific language, allowing for better management and versioning of access control policies.
• 🌐 Real-time access control is crucial for performance and availability, necessitating a local call to an authorization service for every access request.
• 🔄 The 'Five Laws of Authorization' include being fine-grained, policy-based, real-time, centrally managed, and having aggregated decision logs for compliance and forensics.
• 💡 Certo offers commercial solutions for authorization, and Gazit encourages exploring open-source projects like OPA and Topaz for building robust authorization systems.

Q & A

What is the main difference between authentication and authorization?

Authentication is about proving that you are who you say you are, often using methods like emails, passwords, biometrics, or two-factor authentication. Authorization, on the other hand, is about determining what a logged-in user is allowed to do within an application, specifically whether a user has certain permissions on a particular resource.

Why is fine-grained authorization important?

Fine-grained authorization is crucial for security because it adheres to the principle of least privilege, limiting user permissions to the minimum necessary for their tasks. This minimizes the damage potential from compromised identities and helps maintain a secure and consistent authorization surface area across applications.

What is the significance of the OAuth and OpenID Connect standards in authentication?

OAuth and OpenID Connect are significant standards in authentication because they provide a mature ecosystem for implementing single sign-on and access delegation. They have been around for almost 20 years, with OpenID Connect being around for about nine years, and they are widely used to enable login without the need for developers to write their own authentication code.

What are the common issues with current authorization implementations?

Current authorization implementations often suffer from a lack of consistency, leading to security vulnerabilities, such as broken access control, which is the number one issue on the OWASP Top 10 list. Additionally, the lack of standards results in each microservice implementing permissions differently, creating a complex and hard-to-manage authorization landscape.

What is the role of centralization in authorization?

Centralization in authorization involves creating a single, consistent implementation that can be used across all microservices, reducing the risk of security vulnerabilities and making it easier to manage and reason about the authorization surface area of an application.

How does the principle of least privilege relate to authorization?

The principle of least privilege in authorization means giving users only the permissions they need to perform their tasks, and no more. This minimizes the potential damage from a compromised identity and is a key reason for implementing fine-grained access control.

What is the difference between 'authorization spaghetti code' and extracting authorization logic?

Authorization spaghetti code refers to the practice of having numerous if and switch statements scattered throughout microservices, making it difficult to manage and reason about. Extracting authorization logic involves separating this logic from the application code and storing it in a centralized manner, which aligns with the security principle of separation of duties.

Why is real-time access control important in authorization?

Real-time access control is important because it allows for dynamic decision-making based on the most current data, which is crucial for security. It enables permissions to be checked right before granting access to a protected resource, ensuring that the decision is based on up-to-date information.

What are the 'Five Laws of Authorization' mentioned in the script?

The 'Five Laws of Authorization' include: 1) Be fine-grained and flexible, 2) Be policy-based, 3) Ensure real-time local authorization, 4) Centrally manage policies and data, and 5) Aggregate and centralize decision logs for compliance and forensics.

How does the Topaz project relate to the concepts discussed in the script?

The Topaz project is an open-source solution that combines the decision engine from the Open Policy Agent (OPA) with a Zanzibar-like directory model. It aims to offer a fast, flexible, and easy-to-use authorization system that supports various access control models and is designed to be used in any cloud environment.

Outlines

00:00

😀 Introduction to Fine-Grained Authorization

Omary Gazit, the co-founder and CEO of Certo, introduces himself and his background in software development, particularly in cloud platforms and identity access. He highlights his experience with Microsoft's Azure Access Control service and his involvement in open-source projects like OpenStack and Kubernetes. Gazit differentiates between authentication and authorization, explaining that while authentication is about verifying identity, authorization is about defining what a user can do within an application. He points out the lack of standards in authorization and the resulting security issues, such as broken access control being the number one vulnerability in applications. He emphasizes the need for a centralized and consistent approach to authorization, contrasting it with the mature ecosystem for authentication.

05:01

🔐 Modern Authorization Best Practices

Gazit discusses the shift towards centralized authorization services, replacing the old pattern of each service handling its own authorization. He advocates for fine-grained access control, adhering to the principle of least privilege to limit the blast radius of a compromised identity. He criticizes the old practice of authorization spaghetti code and promotes extracting authorization logic out of applications for better separation of duties. Gazit also argues against baking scopes into access tokens, favoring real-time access checks for greater flexibility and security. Lastly, he stresses the importance of comprehensive monitoring and audit trails for compliance and forensics in the event of a breach.

10:02

📚 Evolution of Access Control Models

This section takes a historical view of access control models, starting from access control lists in Unix and Linux, moving to role-based access control with LDAP and Active Directory, and then to attribute-based access control which considers various attributes for decision-making. Gazit then introduces relationship-based access control, popularized by Google's Zanzibar system, which models access control rules as relationships between subjects and objects. He also discusses the emergence of two ecosystems for fine-grained authorization: policy-as-code with Open Policy Agent and policy-as-data with various RBAC implementations.

15:05

🛠️ Policy-Based Access Management

Gazit explains the concept of policy-based access management, which involves lifting access control logic out of application code and expressing it in a domain-specific language. He uses Rego, the policy language for Open Policy Agent, to illustrate how policies can be written and managed separately from application code. This approach allows for easier evolution of access control policies and separation of concerns between application developers and security teams. He also mentions the use of middleware to simplify the integration of authorization checks in applications.

20:06

⏲️ Real-Time Access Control and Distributed Systems

The speaker emphasizes that authorization is a distributed systems problem, requiring fast and local decision-making while maintaining centralized management of policies and data. He argues against hosted services for authorization due to the critical nature of authorization decisions in the request path of applications. Gazit outlines the need for a control plane to manage policies, data, and decision logs, suggesting the use of technologies like Open Policy Agent and Topaz for building such systems. He concludes with the 'Five Laws of Authorization' that organizations should consider when building an authorization system, including being fine-grained, policy-based, real-time, centrally manageable, and having aggregated decision logs.

25:06

📢 Closing Remarks and Resources

In conclusion, Gazit provides resources for those interested in learning more about authorization, including the Topaz project and the Open Policy Containers project. He invites the audience to engage with him on social media, join the Certo Slack community, and explore the Topaz GitHub repository. He also mentions that Certo offers commercial solutions for organizations that prefer not to build their own authorization systems from open-source projects.

Keywords

💡Authentication

Authentication is the process of verifying the identity of a user or system. In the context of the video, it is described as proving that you are who you say you are, traditionally done through methods like passwords, but now also including more sophisticated methods like biometrics and two-factor authentication. The video emphasizes that while authentication is a mature field with established standards like SAML and OpenID Connect, authorization remains a more complex issue.

💡Authorization

Authorization refers to the set of rules and practices that determine who is allowed to perform certain actions or access specific resources within a system. The video discusses the importance of fine-grained authorization, which is about defining specific permissions for users on particular resources, as opposed to broader roles or groups. It is highlighted as a more challenging problem compared to authentication, with less standardization and more room for inconsistency across different applications and services.

💡Fine-grained Authorization

Fine-grained authorization is the concept of defining very specific access controls for users, often down to the level of individual actions or resources. The video speaker is excited about this concept because it allows for greater security and flexibility. It contrasts with coarse-grained roles that might give too much access, which is a problem the video aims to address by advocating for more precise control mechanisms.

💡OAuth

OAuth is an open standard for access delegation, commonly used as a way for users to grant websites or applications access to their information on other websites without exposing their password. The video mentions OAuth as one of the developer services that have made implementing login mechanisms easier, indicating a shift away from custom login implementations towards standardized services.

💡Role-Based Access Control (RBAC)

RBAC is a method of restricting system access to authorized users. It is based on the roles within an organization, and the video discusses how it has evolved from simple group-based access to more complex models. The video contrasts RBAC with Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC), highlighting the move towards more granular and flexible access control models.

💡Attribute-Based Access Control (ABAC)

ABAC is an access control method where access rights are granted to users through the use of policies which take into account the attributes of the user, the resource, and the environment. The video explains how ABAC allows for more nuanced access control decisions based on various attributes, rather than just roles, which can lead to more secure and flexible systems.

💡Relationship-Based Access Control (ReBAC)

ReBAC is an access control model that focuses on the relationships between users (subjects) and resources (objects). The video discusses how ReBAC can provide a more intuitive way to manage permissions, especially in systems with complex relationships like Google Docs, where permissions are not just about roles but also about how users are connected to each other and to resources.

💡Policy as Code

Policy as Code is the practice of managing system policies through code repositories, version control, and software development practices. The video advocates for this approach for authorization policies, suggesting that it allows for better management, auditability, and consistency across different parts of an application or organization.

💡Open Policy Agent (OPA)

OPA is an open-source project that provides a general-purpose policy engine that can enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more. The video mentions OPA as a flagbearer for the 'policy as code' camp, highlighting its role in the ecosystem of fine-grained authorization tools and its flexibility in handling different types of policies.

💡Zanzibar

Zanzibar is Google's system for access control across a variety of their services. The video references Zanzibar as an inspiration for other tech companies to build centralized authorization services, indicating a trend towards more规模化 and consistent authorization mechanisms across different services and applications.

Highlights

Introduction to the concept of fine-grained authorization and its growing importance.

Background of the speaker, Omary Gazit, including his experience with Microsoft and open-source projects.

The distinction between authentication and authorization, with a focus on the maturity of authentication processes.

The current state of authorization, highlighting the lack of standards and the prevalence of inconsistent implementations.

The security risks associated with poor authorization practices, including the top spot of broken access control in the OWASP Top 10.

The benefits of centralizing authorization and the trend among tech organizations to build centralized authorization services.

The evolution from coarse-grained roles to fine-grained access control, adhering to the principle of least privilege.

The shift from authorization spaghetti code to extracting authorization logic and separating concerns.

The drawbacks of baked-in access token scopes and the move towards real-time access checks.

The importance of comprehensive monitoring and decision logging for compliance and forensics.

The rise of purpose-built authorization services and the influence of Google's Zanzibar system.

A comparison of different authorization models, including RBAC, ABAC, and the emerging ReBAC models.

The policy-as-code movement and its benefits for managing access control policies.

The implementation of real-time access control as a local call for performance and availability.

The Five Laws of Authorization as a framework for building an organization-wide authorization system.

Practical advice on adopting authorization solutions, including the use of open-source projects like OPA and Topaz.

The offerings of Certo, the company behind Topaz, in providing commercial solutions for authorization.

Transcripts

hello my name is omary gazit I'm the

co-founder and CEO of Certo an

authorization company and I'm very

excited to spend the next 30 or so

minutes with you talking about fine

grained authorization and why

everybody's so excited about

it first a little bit about myself I've

spent well over three decades building

software for developers um the last 15

years of which uh we're really focused

on on cloud platforms uh in identity and

access in particular I love doing

startups this is my third startup uh and

when I'm not start uping I'm skiing I

was super fortunate to have worked on

some really cool projects uh over my

career uh I was one of the co-founders

of the net project at Microsoft uh as

well as the Azure project where I was uh

I worked on Azure Access Control service

that became Azure active directory uh

and then the last 10 years I spent a lot

of time in the open source Source base

uh working on things like openstack and

specifically I am an openstack Cloud

Foundry where I was a board member U

puppet in

kubernetes so let's start by talking

about the differences between

authentication and authorization some

people talk about them as being the same

thing off but they really are two

distinct processes authentication is

really about proving that you are who

you say you are so in the old days we

used to do it using emails and passwords

and these days is we have password list

and Biometrics and magic links and two

Factor but ultimately it's the same

process and the ecosystem at this point

is pretty mature we've had standards in

the space for almost 20 years now saml

is the OG The Original Gangster of um

single sign on standards uh and open ID

connect has been around for about nine

years oo 2 a little bit longer than that

and we also have some fairly mature

developer services right so you can use

OCTA or ozero or Azure active directory

or Cognito uh to be able to implement

login without having to write it

yourself in fact no one writes login

anymore everybody uses a developer

service so this is mostly a solved

problem for

developers authorization not so much now

authorization is once you're logged in

what can you do in the context of this

application and specifically do you as a

user have this particular permission on

this particular resource

now there are not any real standards in

the space as of yet certainly there are

patterns like rback and aback which

we'll talk about later um and there's

also no implementations at scale at

least of developer Services right every

framework every language has uh a set of

libraries uh every framework has a set

of libraries that help you build uh

authorization but really every one of

these implementations is fairly

inconsistent that creates a lot of

problems the first first one is bad

security uh and the case in point is

that number one on the oosp top 10 list

of application security issues is broken

access control so they've tested uh a

whole bunch of applications and like a

whopping 94% of the applications that

they tested have had some sort of broken

Access Control vulnerability so this is

a huge problem um uh in terms of

security Now not to mention the fact

that if every micro service implements

permissions differently you have a a

budg of inconsistency in the application

and it's really hard to reason about the

authorization surface area of your

application not to mention the

opportunity cost imagine that you had to

go build login uh by yourself or text

messaging or uh payments or things like

that that's just a whole bunch of wasted

effort um and that is unfortunately

still the state-of-the-art with

authorization every application

essentially rolls their own

now things are not all bad it turns out

that a lot of Technology organizations

in the last couple of years have been

looking at authorization as something

that they need to centralize and they've

been been giving it to their platform

Services teams or Central Services teams

to go build a single consistent

implementation and they're writing about

it so a lot of Technology organizations

have written papers or blog posts or

have given talks about how they do

authorization and if you look at um all

the different patterns uh that they've

written about they're really five that

bubble up to the surface and we contrast

those here with some of the old school

or anti patterns the first one is that

each service does its own authorization

this one's kind of obvious right in the

modern best practice is that these

technology companies are basically

empowering their censal services teams

to go build a purpose-built

authorization service that all the other

microservices can actually go rely on

the second uh anti pattern is to use

coar grained rolls that are baked into

the applications and the modern best

practice is to uh replace that with fine

grain to access control really adhering

to the principle of lease privilege what

that principle means is you want to

basically give as much permission to the

user as they need to be able to do their

job but no more than that and the reason

why is because if you have a compromised

identity you want to limit the blast

radius of what that user can do and so

it just makes sense to lock down

permissions as much as possible and that

really is the the impetus for fine grain

access

control the third one is that you know

you find in the you know kind of old

school way of doing things authorization

built as a bunch of if and switch

statements in each of the microservices

so authorization spaghetti code is what

we call it and the best practice is to

extract the authorization logic out of

the micros service out of the

application and store inversion it

separately really achieving a separation

of concerns that enables in turn uh

another important security principle

called separation of Duties so you have

the application developers worrying

about the application code then you have

people who really reason about the

authorization surface area able to go

look at all the authorization policy Al

together and figure out uh whether that

authorization policy makes

sense the fourth anti- pattern is

creating uh Scopes that are baked into

access token as

permissions and the modern best practice

is to make a realtime call to an

authorization service right before you

want to Grant access to a protected

resource a realtime access checks why is

uh relying on Scopes baked in Access

tokens bad well you know for a number of

reasons first of all um they basically

have a lifetime so as soon as you mint

that access token it's good for two

hours or two days for for as long as

that access token is good for and so if

you want to actually take away

permissions uh that's not quite possible

without token revocation which which is

a really complicated thing uh if you're

making a real-time access check right

before you grant access to a protected

resource you don't need to rely on

essentially kind of uh stale tokens the

other thing that uh these tokens don't

really give you uh the ability to do is

find grained access control so let's say

that you wanted to Grant somebody the

right to read a document if you put a

read document scope in an access token

well you know the calling application

can go look at that scope and say okay

uh the user can read a document but

which document all the documents are you

going to go create a scope for every

document that the user has access to at

login time you know clearly it's just

not a scalable practice

and then lastly um most applications

sadly barely even have a trace of the

you know the the folks who have logged

into them much less any kind of fine

grained audit trail of what users have

done in the application and the modern

best practice is to have comprehensive

monitoring basically uh record the

decision log for each decision that the

application made and be able to

centralize that for compliance and

forensics again you know a breach is not

a matter of if it's a matter of when at

this point in time and so once you

detect that something happened you

really want to know why it happened you

want to have the forensics uh to figure

out how the application uh did the

authorization what you know the

application authorized the user to do uh

and of course it's also very important

for compliance uh you need to be able to

prove that users were only able to do

what they were allowed to do within the

scope of the

application

great so let's dive into each one of

these the first one I want to dive into

is these uh this idea of purpose-built

uh authorization service it seems like

it's the new hotness everywhere we look

uh there's some tech company that's

writing a paper about it so it started

out about three years ago with Google uh

writing about their Zanzibar system

Zanzibar is basically their uh

distributed system for uh access control

for a wide variety of Google services

Google Docs Google Drive Google Calendar

uh uh cloud and so on and so forth and

um it's a large scale Planet scale

service and one of the things that

they've done is they've created

essentially this new model uh that they

coined the term relationship based

access control for and we'll talk about

that uh in a couple slides um into it

built one that's based on a different

set of principles more of a uh attribute

based model hedi from Airbnb was

inspired by Zanzibar in fact uh the AR

architect for hedi was one of the folks

on the Zanzibar team from Carta was also

inspired by the Zanzibar paper Netflix

is again more of an aback model so we

have different types of implementations

but all these folks are basically

building uh these centralized services

and so that you know every one of their

application teams doesn't have to

reinvent that

wheel the next principle is fine grained

access control and so let's go down a

trip down memory lane here and talk

about how that's evolved over the years

so back in the 80s and 90s we had uh

Unix systems and later on Linux systems

uh and NT and those relied on access

control lists basically the type of

question that you answered with an

access control list was does Alice have

read access to this file a file system

had read write and execute bits uh for

users and groups and other and that was

basically the as fine grained and access

control model model as you could get uh

with Linux

systems now in the '90s and 2000s we saw

uh this new idea called the directory

ldap uh and later on active directory

basically uh ushered in this idea of

role-based access control so roles were

typically implemented as groups so you

for example had a group in ldap or

active directory that you put users in

and that would correspond to a role in a

business application and you can answer

questions like is Bob in the sales admin

role by seeing whether Bob was in that

group you had this idea of nested groups

and you know life was kind of simple but

pretty clunky and very much coarse

grained the problem there was that you

had this group explosion where uh in

Microsoft I remember we had uh let's

call it you know 50,000 users uh at at

one time in 250,000 groups uh so it was

impossible to reason about what

permissions uh users actually

had in the 2000s and 2010s we had this

new idea called attribute based access

control and the idea there was that you

basically computed Access Control

decisions based on attributes either on

the user or on the resource or even

environmental attributes so you could

answer questions like is mallerie have

access if mallerie is in the sales

department and the document is in the

sales folder and it's currently working

hours um so you could write a policy

that evaluated all those attributes and

gave you a yes or no answer the you know

the original system that implemented

this uh was known as exactl uh that's

kind of like the Original Gangster of uh

the ABAC systems and of course uh you

know now in the last five years we've

had successors to that and I'll talk

about that in the next slide and lastly

uh we have relationship based access

control like I said before it actually

predates the Google's ends of our paper

but Google uh really repop poize that

model uh and the idea is that you

basically have relationships defined

between subjects and objects so so for

example uh a subject like Eve is a user

and she can be in a group uh and that

group can have say view access on a

folder and there can be documents inside

that folder and so we can answer

questions uh like does Eve have read

access to this document uh by chasing

the edges that link uh between that

subject Eve and the object uh the that

particular document and see whether

those edges carry the read permission

so after the history lesson uh let's uh

fast forward to the present over the

last 5 years we've seen two different

ecosystems emerge around fine gr

authorization the first one I call the

policy is code Camp uh and the flag

bearer for that is the open policy agent

project uh which basically started from

the aback uh view of the world and so

there's a lot of stuff going for it it's

a cncf graduated project it graduated

about two and a half years ago so

there's a single mature open source

implementation it's a general purpose

decision engine uh fairly flexible and

primarily used today for infrastructure

authorization scenarios like kubernetes

admission control uh and it's really

tailor made for policy based access

management and ABAC it's essentially the

successor to exagal now there are some

drawbacks as well the language is has a

high learning curve so unless you're a

prolog head you know this is a side

effect free data log derivative uh and

you have to kind of go build your

authorization model from first

principles it's really an unopinionated

language so you have to kind of design

your authorization mod model from

scratch and it's a little like you know

writing something in the sembler

language and furthermore you really

don't have much help with how to manage

data in the system Opa has an effective

policy plane but it doesn't really have

a data plane so if you want to start

with Opa you have to kind of roll that

out on your own on the other side

there's the Zanzibar model model uh I

call this the policy as data camp and

like I said before Google uh built their

uh model over an abstract model called

reback relationship based Access Control

they didn't invent it but they certainly

popularized it uh if Opa has no opinions

reback has plenty of opinions it's a

very opinionative model uh and the idea

is again like I said you're modeling

your um access control rules essentially

as data as a set of relationships

between subjects and objects and so if

your domain looks a lot like Google Docs

you have subjects like users and groups

uh and objects like uh folders and files

you can uh very much use this as an

opinionated model that you can start

from now it's a fairly immature

ecosystem there are at least half a

dozen uh competing open source

implementations uh because Google didn't

open source anything they didn't even

write a spec they built they wrote a

technical report so there are uh a bunch

of different uh open source

implementations at this point and they

don't really share uh any common schema

language or a common data language uh

and it's also hard to extend the reback

model into uh attributes although some

of these projects are starting to do

that uh they're they each do it in kind

of an inconsistent way as

well now fortunately there's a third

path uh we call this the uh don't

succumb to the tyranny of the ore a lot

of people think of these as competitive

ideas but we think of them as compliment

and so topaz is a project uh that Asser

of my company maintains but the idea

there is to take the Best of Both Worlds

you take the decision engine from Opa

and so you have a policy based Access

Control model uh that is uh supports

attributes and you take the Zanzibar

directory and you kind of put them

together in a single open source project

that's delivered as a single container

image so here I have a as a reference a

URL to Topaz uh go check it out uh the

QR code will also take you to the GitHub

repo the next principle I want to talk

about is policy-based access management

and as a reminder this is the idea of

lifting the access control logic out of

the application where it's uh expressed

as if or switch statements and instead

expressing it in its own domain specific

language uh and storing and versioning

it as code just like any application

artifact so here I have a policy written

in Rego uh which is the surface syntax

for the open policy agent this happens

to be a topaz policy uh because it has a

little bit of an Easter egg here uh that

uh basically uh makes a call to one of

the topaz built-ins uh that computes the

policy based on a relationship between a

subject the user and an object uh one of

their reports so this policy has two

allowed Clauses one of them uses

attributes so uh basically you're

allowed if the uh logged in user's

property is a Department property I

should say equals operations or you're

allowed if you're the manager of uh this

particular user and so it's important to

note that uh it's not just Opa that

adheres to this principle any Zan ofar

BAS system also equally believes that

you should extract that policy logic

don't express it as if in switch

statements inside of your application

instead store inv verion it as a domain

model but what does that get you

basically instead of having to go again

like I said write if we switch

statements to express authorization

logic you can go use a middleware so

here we have this check off Z middleware

that we've placed in the dispatch path

of uh this route Handler for this

node.js this expressjs uh route Handler

and all we have to do is just uh tell

the developer to make sure to call that

middleware that middleware makes a call

to an authorization server that computes

a decision if that decision comes back

as uh you know aess denied uh the whole

route gets uh basically returns and

access denied otherwise you dispatch to

the next Handler here what does that

give you uh it allows you to store

inversion uh that policy artifact just

like you do application code and every

policy change is part of a get change

log so every Access Control change that

you want to make in the policy is loged

just like any other

uh G change uh so that means that the

policy can evolve uh from using a

different team so a different team like

the security team can own that policy

and it's decoupled from the application

Logic the application delivery team

doesn't have to worry about uh how to

evolve that access control logic and the

security team can reason about the

entire surface area uh authorization

surface area of the application lastly

we think of these policies as something

that you should treat just like like any

application artifact so application code

you build into an immutable image

typically a dock or container that's how

you distribute it and that's the same

thing that you should do with policies

you should build them into oci images

and sign them using something like

cosign to secure uh the software supply

chain for these artifacts in fact here I

have a reference to a project called the

open policy containers project which is

a cncf u sandbox project s is also

involved with that uh and you can build

not just topaz policies but also any

generic Opa policy into a container

image sign it with cosign and verify the

signatures and lastly I want to talk

about real time access control so this

is where I kind of go into my

infomercial about authorization actually

being a distributed systems problem and

I'll explain why I what I mean by

that you really need to do authorization

locally authorization is different than

any other developer service because if

you think about uh things like stripe or

twilio or even ozero those are hosted

services and it's fine for them to be

hosted because you basically make a call

to them and it's important that that

call complete and it's important that

they maintain you know a high SLA but

you know it doesn't really matter if it

happens in a second uh because it turns

out that it's not really in the critical

path of every application request

whereas authorization is if you're doing

it correctly uh you're basically making

a call to the authorization system right

before you grant access to a protected

resource and that can happen one or more

times for every user request so it's got

to be fast it's got to be done in around

a millisecond and it's got to be 100%

available to the calling application so

it can't really be a hosted

service but um you also want to be able

to manage all of the policies and the

data that's used for authorization in a

centralized manner so you really need to

have some kind of control plane that

allows you to manage the life cycle of

policies uh and as well as uh you know

all the all the data all the user and

group and resource data that are used

for policy decisions uh and

relationships and be able to mediate

those decision logs back to a

centralized control plan so data uh

about users comes from an identity

provider

uh data from you know the source code

for policies comes from a source code

control system and then decision logs

really want to end up in your scene tool

in your log aggregation tool so you

really need kind of this central control

plane that allows you to manage all this

stuff at

scale so as we bring this presentation

to a close I want to close with what we

call the Five Laws of authorization if

you're building an authorization system

for your entire organization you want to

have it have the following five

properties at the very least you want to

be fine grained and you want it to be

also flexible enough to support all the

different types of authorization models

so rback aback reback any combinations

of them you want to make it policy based

so you really want to make sure that you

give the opportunity to the application

developers to not have a bunch of switch

and if statements in their code and

instead allow them to extract the

authorization policy their applications

and store and version it into in it as

its own artifact that you can actually

go build into assigned image make sure

that authorization is done in real time

as a local call executing over fresh

data and yet you want to have Central

management of the policies and all the

resource data that are used in

authorization decisions and finally you

want to Aggregate centralize and

aggregate all the decision logs that

come out of these authorization requests

so that you can use those later for

compliance and forensics and if you're

building a system like this you also

want some nonfunctional requirements

like you want to make it super easy for

your developers to adopt so uh you want

to uh have a system that allows you to

do authorization uh to an external

system with a single line of code you

want to be able to have it integrate

with all of the systems you already have

so identity providers uh source code

repositories artifact Registries logging

systems and finally uh it's important

for it to be open uh so you get a lot of

ecosystem effects from betting on

kubernetes Native Technologies like open

policy agent and

topaz now this is a lot of work to do

and fortunately there are some places to

start there are open source projects

that you can start from Opa is one of

them topaz is one that I've talk talked

about as well it's the project that my

company maintains so we're very partial

about it um this is a QR code for

getting to the repo and topaz uh we'

like to say that it's fast flexible and

easy fast uh it does authorization in

under a millisecond flexible it supports

all the different U Access Control

Models All The Backs as we like to say R

back a back and reback it runs in any

cloud and finally easy it has sdks uh it

has grpc apis it has rest apis graphql

apis sdks from every language so it's

super easy for your developers uh to

incorporate no matter what language

they're

using and lastly my company ass Certo

uh basically builds commercial solutions

for authorization so if this is not

something that you want to roll out by

hand using open source uh we're happy to

provide you readymade Solutions thank

you so much for listening over the last

almost 30 minutes uh please come find me

on social I'm om G at Twitter I'm

rto.com if you have any questions or

comments uh we'd love to answer U join

our slack uh it's at aso.com slack uh

check out our repo uh that's soru ddev

toaz on GitHub and uh let us know what

you think thank you so

much