apidays Helsinki & North 2023 - API authorization with Open Policy Agent, Anders Eknert, Styra

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/

Transcript

1. Distributed Authorization with Open Policy Agent API Days, Helsinki, 2023 Anders Eknert
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
4. Problem: How do we do authorization in distributed APIs?
5. Answer: It’s complicated
6. The evolution of identity
7. From monolith Authentication Authorization Data Access Business logic Orchestration Data Access Data Access Business logic Business logic User interface
8. To microservices Authentication Authorization Data Access Business logic Orchestration Data Access Data Access Business logic Business logic User interface
9. To microservices Authentication Authorization Data Access Business logic Orchestration Data Access Data Access Business logic Business logic User interface
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
25. Great, now do authorization
26. The evolution of access control
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
28. So, where should we do authorization?
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
31. Great, we’re back where we started
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
35. 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
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.
38. Policy decision model Service OPA Policy (Rego) Data (JSON) Request Policy Decision Policy Query Input can be ANY JSON value Output can be ANY JSON value Request Policy Decision Linux PAM
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
44. Distributed authorization solved!
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!
46. Questions?
47. Thank you!