Fine-Grained Policies RBAC with OpenFGA

Slide 1

Slide 1 text

© Okta and/or its afﬁliates. All rights reserved. © Okta and/or its afﬁliates. All rights reserved. Fine Grained Policies RBAC with OpenFGA José Carlos Chávez Security Software Engineer @ Okta Open Source Summit Europe September 16th, 2024 - Vienna @jcchavezs

Slide 2

Slide 2 text

© Okta and/or its afﬁliates. All rights reserved. © Okta and/or its afﬁliates. All rights reserved. Fine Grained Policies RBAC are back with OpenFGA José Carlos Chávez Security Software Engineer @ Okta Open Source Summit Europe September 16th, 2024 - Vienna @jcchavezs

Slide 3

Slide 3 text

© Okta and/or its afﬁliates. All rights reserved. José Carlos Chávez Security Software Engineer - Okta ● Open Source enthusiast for 10+ years ● OWASP Coraza WAF co-leader, OpenFGA contributor ● Loving father of 2 ● Mathematician in quarantine @jcchavezs

Slide 4

Slide 4 text

© Okta and/or its afﬁliates. All rights reserved. Access control [...] determines who is allowed to access certain data, apps, and resources—and in what circumstances. What is access control? - Security 101, Microsoft @jcchavezs

Slide 5

Slide 5 text

© Okta and/or its affiliates. All rights reserved. Various mechanisms State of art ● Discretionary access control (DAC): every object has an owner, and owners grant access to users at their discretion. ● Mandatory access control (MAC): users are granted access in the form of a clearance. A central authority regulates access rights and organizes them into security levels. ● Role-based access control (RBAC): access rights are granted based on defined business functions (role), rather than individuals’ identity. ● Attribute-based access control (ABAC): access is granted flexibly based on a combination of attributes and environmental conditions. @jcchavezs

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© Okta and/or its affiliates. All rights reserved. Mechanism problem State of art meets reality ● Discretionary access control (DAC): every object has an owner, and owners grant access to users at their discretion. Case by case and hence not scalable. ● Mandatory access control (MAC): users are granted access in the form of a clearance. A central authority regulates access rights and organizes them into security levels. Works on static and rigid environments. ● Role-based access control (RBAC): access rights are granted based on defined business functions (role), rather than individuals’ identity. Easy to understand and author policies rightly but hard to scale (e.g. role explosion). ● Attribute-based access control (ABAC): access is granted flexibly based on a combination of attributes and environmental conditions. It is hard to understand and author policies rightly (e.g. permissions overlap) but easy to scale and model. @jcchavezs

Slide 11

Slide 11 text

© Okta and/or its afﬁliates. All rights reserved. Protocols and implementation challenges Shift left done wrong ● Each service does its own authorization. ● Coarse-grained roles baked into apps e.g. access to /documents vs /documents/:id. ● Authorization “spaghetti code” on each service e.g. is_admin function or if user_id == 1 {...}. ● OAuth2 scopes in lieu of permissions. ● Missing or inconsistent authorization/audit logs. @jcchavezs

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© Okta and/or its affiliates. All rights reserved. Mechanism solution ReBAC to the rescue ● Provides high flexibility and it is designed to express complex policies. ● Defines permissions based on relationships between entities e.g. user, team, blob, cluster, etc. ● Dynamic and context-aware, environmental conditions can be expressed in policies e.g. time and location. @jcchavezs Alice Bob Eng HR Company resumes contracts HR docs contract _alice member member parent owner parent parent parent viewer contract _bob parent parent

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© Okta and/or its afﬁliates. All rights reserved. Inspired by Google Zanzibar Used in Google Drive, Google Cloud, Youtube, etc. Flexible enough to model any application domain. OpenFGA Relationship Based Access Control (ReBAC) An evolution of Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC). Build to Scale Can scale to millions of globally distributed users and billions of resources. People Friendly Enable user collaboration and ﬁne grained access control in your applications using developer friendly APIs and people friendly readable models. @jcchavezs

Slide 16

Slide 16 text

© Okta and/or its affiliates. All rights reserved. Cloud Native Authorization requirements ● Support a consistent model that address fine grained access requirements. ● Policies should be a first class citizen and not an application’s detail. ● Authorization checks should be a local call embracing real-time access decisions. ● Policies and subject/resource/relations data should be centrally managed. ● Decision/Audit logs should be aggregated and stored centrally. ● Access decisions must be easy to audit and explain. @jcchavezs

Slide 17

Slide 17 text

© Okta and/or its afﬁliates. All rights reserved. Opinionated solution Shift left done right ● Models follow reality, not the other way around. ● Decoupling the policies from the application code and use a standard DSL enables central management in a SDLC fashion e.g. gitops like. ● The transparency of the SDLC provides audit trails on policy changes. ● A central source of truth for policies guarantees consistency and conformance validation across the system. ● Enforcement is now possible beyond the application layer (e.g. network layer) which is crucial towards zero trust model. @jcchavezs

Slide 18

Slide 18 text

© Okta and/or its afﬁliates. All rights reserved. if you can model it you can enforce it Unlimited possibilities ● Secure access: ■ user to API (endpoint, method, host, etc) ■ user to user ■ user to resource ■ service to service, namespace to namespace, namespace to cluster, tier to tier, environment to environment, cluster to cluster, cloud to cloud, etc ● Easy integration: SDK, Ingress gateway, sidecar, etc. ● Auditability and forensic analysis by inspecting audit logs and access decisions ● Observability and controllability by processing logs and taking actions. @jcchavezs

Slide 19

Slide 19 text

© Okta and/or its affiliates. All rights reserved. Conclusions ● ReBAC is a natural fit for the class of cloud-native applications whose design is based on microservices due to its flexibility and also because it empowers any stakeholder of the system to understand and contribute to policies. ● Being able to understand an access decision in a human readable way is crucial to understand access leaks, unsecure points and forensic research. ● Performance is a key in access decisions as making decisions in the critical path could have huge impact in latency. @jcchavezs

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© Okta and/or its afﬁliates. All rights reserved. Questions? © Okta and/or its afﬁliates. All rights reserved. You can also reach me at ● josecarlos.chavez@okta.com ● https://www.linkedin.com/in/jcchavezs/ ● https://twitter.com/jcchavezs @jcchavezs

Slide 22

Slide 22 text

© Okta and/or its afﬁliates. All rights reserved. Recommended readings Zanzibar: Google’s Consistent, Global Authorization System - Ruoming Pang et al, Google Announcing OpenFGA - Auth0’s Open Source Fine Grained Authorization System - Andrés Aguiar, Okta OPA, Cedar, OpenFGA: Why are Policy Languages Trending Right Now? - Daniel Bass, Permit.io @jcchavezs

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© Okta and/or its afﬁliates. All rights reserved. OpenFGA vs OPA In case someone wonders… OPA ● Logic-based language, higher learning curve as it is designed for devs. ● Lack of administrative tooling to align policies with business requirements. ● Difﬁculties on keeping track of which policies exist and which rules they contain. @jcchavezs