1 of 14

Omri Gazitt

Co-founder, Aserto & AuthZEN

OpenID AuthZEN:�0 to interop in 6 months

2 of 14

Motivation: why authorization is critical

Majority of cyber attacks exploit identities
Most attacks are successful because of over-permissioned users
Turns even a single identity compromise into a potential catastrophe
The #1 issue on OWASP’s Top 10 (2021) is A01:2021-Broken Access Control

94% of apps were tested for some form of broken access control.

The #1, 3, 5 issues on OWASP’s Top 10 API security risks (2023) are all related to broken authorization

Broken Object-Level Authorization, Broken Object Property-Level Authorization, Broken Function-Level Authorization

3 of 14

Motivation: why standards are needed

Authorization is hard to manage in today’s organizations

Authorization is siloed

Too many places to manage authorization
Each application “does its own thing”
There are clear gaps between silos

SaaS and cloud complicate matters

No standardized widely-adopted way for AuthZ components to communicate

NIST ABAC, NGAC and XACML have not achieved significant adoption
SaaS, COTS, and cloud services cannot talk to external AuthZ systems

4 of 14

Terminology

5 of 14

AuthZEN WG Scope and Objectives

Increase interoperability between existing standards and approaches to authorization

Policy-based e.g. ALFA, Cedar, OPA (Rego), Topaz, and IDQL
Zanzibar/Graph-inspired systems such as OpenFGA, Topaz, SpiceDB, SGNL
NGAC-inspired systems e.g. 3Edges

Standardize interoperable communication patterns between major authZ components

PAP, PDP, PEP, and PIP
See NIST ABAC’s architecture (NIST SP 800-162)

Establish and promote the use of Externalized AuthZ as an architectural principle
Relate runtime authorization to existing AuthN standards

6 of 14

Deliverables and Specifications

Description of standard authorization patterns, use cases, communications patterns, and integration patterns (in progress)

An API to communicate authorization requests and decisions between Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs) which may be implemented by different parties (in progress, interop scenario defined)

An API to communicate authorization policy and data from PAP to PDPs which may implemented by different parties (not started)

7 of 14

April 2024 Update

Prior Art Document

Deep dive into XACML, ALFA, Cedar, Topaz, and OAuth
Comments welcome here: https://hackmd.io/@oidf-wg-authzen/prior-art-pep-pdp

PEP-PDP API draft

https://openid.github.io/authzen/

AuthZEN Interop Scenarios

https://hackmd.io/@oidf-wg-authzen/InteropScenarios: focused on a simple “Todo” app
Interop website: https://authzen-interop.net | Sample payload Postman collection
4 implementations are already conformant: Aserto (Topaz), Cerbos, Kogito, SGNL
At least 3 more implementations are in the works: Axiomatics (XACML REST/JSON), Permit.io, OPA

Next steps

AuthZEN Panels at Identiverse 2024 and EIC 2024
Interop events at both Identiverse 2024 and EIC 2024

8 of 14

Initial interop scenario

9 of 14

Components

10 of 14

Interoperable implementations

11 of 14

Todo App demo

12 of 14

Lessons

Don’t try to boil the ocean 🡺 focus on PEP <-> PDP scenario
Start with a good first draft of the spec (Thanks Atul T!)
Create the simplest scenario first

A single request/response
No boxcarring
No usage of search APIs

Write the request/response payload spec, allow it to guide the API spec
Set an aggressive deadline (Identiverse – May 2024)
Get a few implementations built, to catalyze engagement/momentum

13 of 14

What’s next?

Evaluations API: box-carring multiple requests together
Resource Search API: find all the resources that a subject can access
Subject Search API: find all the subjects that can access a resource

Create additional interop scenarios
Add more implementations (especially ReBAC systems)
Work with relying parties to externalize authorization