apidays Helsinki & North 2023
API Ecosystems - Connecting Physical and Digital
June 5 & 6, 2023
API authorization with Open Policy Agent
Anders Eknert, Developer Advocate at Styra
------
Check out our conferences at https://www.apidays.global/
Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8
Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io
Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/
3. Anders Eknert
● Developer advocate at
● Software development
● Background in identity systems
● Three years into OPA
● Cooking and food
● Football
anderseknert
anderseknert
anderseknert
anderseknert@hachyderm.io
10. The evolution of identity
Application
Data
Permissions
Users
credentials
● The application handles everything - including authentication and access control. The user
authenticates in the application, a session is established, access control performed in code,
commonly with a database serving permission data.
● In the distributed application, authentication is delegated elsewhere.
● But up until now, access control has remained pretty much the same,
in code, with a database serving permission data per request.
Monolith architecture
11. The evolution of identity
Service
Users Permissions
Service Service Service Service
Data
Service
Data
Data
credentials
credentials
credentials credentials credentials credentials
Naive monolith architecture using microservices
12. The evolution of identity
Service
Users Permissions
Service Service Service Service
Data
Service
Data
Data
credentials
credentials
credentials credentials credentials credentials
Naive monolith architecture using microservices
13. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
credentials
Slightly less naive monolith architecture using microservices
Rather than passing around credentials, we exchange them for tokens
14. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
Slightly less naive monolith architecture using microservices
Everyone wants a token!
15. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
Slightly less naive monolith architecture using microservices
So.. how are these tokens obtained?
16. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
Slightly less naive monolith architecture using microservices
17. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
OAuth2
Defines a set of flows for users (interactive flows) and clients (non-interactive) to authenticate
at the authorization server in order to obtain access tokens for use as credentials to services.
Does not detail what an access token should look like.
Despite labeled an “authorization framework” provides little in terms of authorization - rather about
delegation.
Scopes provide basic boundaries for where an access token may be used.
Commonly used for external identity providers, “social login”, etc.
18. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
19. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
20. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
21. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
22. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
23. The evolution of identity
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
token token token
token
token
token token
JSON Web Tokens (JWTs)
A JWT is a signed self-contained collection of claims, i.e. attributes claimed to be true.
Tokens are created by an issuer. Claims often (but not always) provided by the backing identity provider.
Expiry time (and other standard attributes) of JWT included in payload.
JWTs are immutable - no claim may be changed without breaking signature verification.
JWTs are everywhere - libraries for both encoding and decoding available for all languages and platforms.
24. Distributed identity, solved ☑
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens
27. Distributed Authorization?
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens Naive model — authorization logic
embedded in application code, querying
database for permissions
29. Gateway Model
Gateway
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens
Authorization performed at perimeter of
environment
● Fast!
● Single point of failure
● Insecure
● External dependency
30. Zero Trust Model
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens Authorization — just like identity — must
be verified in each service. Make no
assumptions.
● Slow
● Single point of failure
● Secure
● External dependency
● Authorization embedded in
business logic
32. Zero Trust Model
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens
How do we make it better?
● Slow
● Single point of failure
● Secure
● External dependency
● Authorization embedded in
business logic
33. Zero Trust Model
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens Remove online dependency for
permissions data, store copy in
applications
● Slow
● Single point of failure
● Secure
● External dependency
● Authorization embedded in
business logic
34. Zero Trust Model
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens Authorization still hardcoded in applications
— changes are cumbersome, coordination
between teams required, very hard to audit
● Slow
● Single point of failure
● Secure
● External dependency
● Authorization embedded in
business logic
36. ● Open source general purpose policy engine
● Unified toolset and framework for policy across the stack
● Decouples policy from application logic
● Separates policy decision from enforcement
● Policies written in declarative language Rego
● Popular use cases ranging from kubernetes admission
control, microservice authorization, infrastructure, data source
filtering, to CI/CD pipeline policies and many more.
39. Deployment model
● OPA runs as a lightweight self-contained server binary
● OPA ideally deployed as close to service as possible. This usually means running on the same host,
either as a daemon or in a sidecar deployment
● Applications communicate with the OPA server through its REST API
● Go library available for Go applications
● Envoy/Istio based applications. Wasm, Intermediate Representation (IR), more...
40. Policy authoring and Rego
● Rego — declarative high-level policy language used by OPA.
● Policy consists of any number of rules.
● Rules commonly return true/false but may return any
type available in JSON, like strings, lists and objects.
● Policy testing is easy with provided unit test framework.
● Well documented! https://www.openpolicyagent.org/docs/latest/
● Try it out! https://play.openpolicyagent.org/
41. Zero Trust Model
Service
Users
Permissions
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens Decisions delegated to OPA — unified
authorization across the stack, with policy
decoupled from application logic
● Slow
● Single point of failure
● Secure
● External dependency
● Authorization embedded in
business logic
42. Distributed authorization, solved ☑
Service
Users
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens
Permissions
Control
Plane
Policies
43. Distributed authorization, solved ☑
Service
Users
Service Service Service Service
Data
Service
Data
Data
Identity
system
Token/JWT JWT JWT
JWT
Token/JWT
JWT JWT
JSON Web Tokens
Permissions
Policies
45. Getting started
● Start small – write a few simple policies and tests.
● Browse the OPA documentation. Get a feel for the basics and the built-ins.
● Consider possible applications near to you - previous apps and libraries
you’ve worked with. Consider the informal policies it dealt with.
● Delegate policy responsibilities to OPA. Again, start small! Perhaps a single
endpoint to begin somewhere. Deploy and build experience.
● Scale up - management capabilities, logging, bundle server - Styra DAS!
● Styra Academy
● Join the OPA Slack community!