roles assigned to users implicit set of permissions coarse-grained control at & uniform single tenant / no hierarchy no per-resource control no "What can this user see?" across large number of objects
on attributes of the principal, resource & request (role = engineer AND region = EU) good if stateless (everything is provided in request), needs explicit attribute lookups otherwise rules involve comparisons (<,>,=,not,in, ) policies versioned / policies as con g/code, not data . . fi common engines: OPA, Cedar, AWS IAM
authorization relation between user and resource (direct or concentric) stored relationship tuples (policy is data) one tuple per resource / per share similar to / kind-of ACLs based on Zanzibar paper from Google common engines: OpenFGA, SpiceDB, Ory Keto
policies expressed in a DSL • Relationship engines (all in the Zanzibar tradition) store • Decisions are (mostly) attribute driven (claims, • Decisions depend on relationships that change at write against input data passed on each request. The engine is stateless; you supply the data. resource, metadata, request context, …). • All the data needed for the decision is in hand at request time (claims in token, elds on the resource, …), so the engine doesn't need to fetch anything to answer. relationship tuples in a database and answer queries against a stored graph. The engine is the database. time (group membership, document sharing, folder hierarchy, multi-tenant ownership). • The data behind the decision is too large or too dynamic to ship on every request (millions of memberships, deeply nested hierarchies) so the engine needs to own the store. • You need reverse queries: "list every resource this user can read" which inherently require a stored graph. • Permissions are per-resource and per-user, not just per- fi attribute.
authorization system used by Google Drive, YouTube, Calendar, Cloud, and most other Google products. It is the source of the design pattern relationship engines (OpenFGA, SpiceDB, Ory Keto, …) implement. A globally distributed database of relationship tuples that answers two questions in milliseconds at Google scale: 1. "Is user U related to object O via relation R?" (check) 2. "What objects of type T is user U related to via relation R?" (reverse index / list-objects) Two ideas make it work: 1. A typed schema de ning types and the relations between them. 2. A tuple store indexed for both forward and reverse queries, with a consistency mechanism (Zookies) fi that lets clients tie permission checks to the version of the data they read.
additional system to maintain (run, observe, patch, backup, …) application does not (need to) know the decision path (developers can focus on business logic) additional latency (for each request) caching vs. freshness same logic in all applications & services (if it changes, it changes everywhere at the same time) each engine has its own api
the OAuth2/OIDC/SAML of authZ" by: 1. Increase interoperability between existing standards and approaches to authorization 2. De ne and formalize interoperable communication patterns between major authZ components (P*P) 3. Establish and promote the use of externalized authZ as the preferred fi pattern.
2. Can user view record #123? 3. Evaluate Policies Manage Policies PAP PDP 6. View Record #123 5. Permit, user can view record #123 4. Retrieve additional attributes & information PIP
Authorization API enables Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs) to communicate authorization requests and decisions to each other without requiring knowledge of each other's inner workings. The Authorization API is served by the PDP and is called by the PEP. The Authorization API includes evaluation endpoints, which provide speci c access decisions, and search endpoints fi for discovering permissible subjects, resources, or actions.