which role plays open policy agent in the new authorization world centered around microservices ?

1. Public
Version 0.9
beta
OPA in the API
management world
-- Luca Ferrari

2. VP of myself
Luca Ferrari
Started from REST expanding to the rest (of the
modern technologies)
2

3. Agenda
Intro
AuthZ basics
AuthZ models
OPA
Demo
Q&A
3

4. Authentication
&
Authorization
4

5. AuthN and AuthZ
AuthN: “please show me your ID or Passport”
AuthZ: “please scan your boarding pass on
the bar code reader”
5

6. Authorization
model
6

7. Models
There are several models out there, we will be summarizing the following ones:
ACL DAC MAC RBAC ABAC
AuthZ has been there since the beginning of computer systems, for example the first
implementation of ACLs was in the filesystem of Multics in 1965
7

8. ACL
An Access-Control List is a list of permissions associated with a system resource.
An ACL specifies which users or system are granted access to objects, as well as what
operations are allowed on given objects.
Each entry in a typical ACL specifies a subject and an operation.
It specifies individual users or groups.
In real world: Filesystems
8

9. ACL in practice
Subject Object Action
Alice Report Create
Bob Report Read
9

10. DAC
Discretionary Access Control is a way to restrict access to objects based on the
identity of subjects and/or groups to which they belong. The controls are discretionary in
the sense that a subject is capable of passing that permission (perhaps indirectly) on to
any other subject (unless restrained by mandatory access control).
Two implementations:
● Through ownership
● Through capabilities
10

11. DAC in practice
Subject Object Action
Alice Report Create
Alice Subjects Grant
grant
Subject Object Action
Bob Report Create
11

12. MAC
Mandatory access control is a way to control where the operating system or database
constrains the ability of a subject to access or perform an action on an object or target.
Whenever a subject attempts to access an object, an authorization rule enforced by the
OS examines these security attributes and decides if the access can take place. Any
operation by any subject on any object is tested against the set of authorization rules
(aka policy) to determine if the operation is allowed.
With mandatory access control, this security policy is centrally controlled by a security
policy administrator; users do not have the ability to override the policy in contrast to
discretionary access control (DAC).
In real world: SELINUX
12

13. MAC in practice
Subject Object Action
Alice Report Create
Subject Object Action
Report Alice Be created
grant
13

14. RBAC
Role-Based Access Control is a way to restrict system access to authorized users with
policies defined around roles and privileges. The components of RBAC such as
role-permissions, user-role and role-role relationships make it simple to perform user
assignments across a wide organization with 1000s of users.
There are 3 elements to RBAC:
1. Role assignment
2. Role authorization: A subject's active role must be authorized for the subject.
3. Permission authorization: A subject can exercise a permission only if the permission
is authorized for the subject's active role.
In the real world: IDP
14

15. RBAC in practice
Subject Role
Alice Creator
Name Action Object
Create report Create Report
Update Report
Read Report
Manage report Approve Report
Read Report
grant
Name Permission
Creator Create report
Permissions Role

16. ABAC
Attribute-Based Access Control is defined as a system where access rights are
granted to users through the use of policies which combine attributes together. The
policies can use any type of attributes (user attributes, resource attributes, object,
environment attributes etc.).
This model supports Boolean logic, in which rules contain "IF, THEN" statements about
who is making the request, the resource, and the action.
Attribute-based access control is also known as Policy-Based Access Control (PBAC)
or Claims-Based Access Control (CBAC) or IAM in AWS
16

17. ABAC
The Policy Enforcement Point inspects the request and generates an authorization
request from it which it sends to the PDP.
The Policy Decision Point evaluates incoming requests against policies it has been
configured with. The PDP returns a Permit / Deny decision. The PDP may also use PIPs
to retrieve missing metadata
The Policy Information Point bridges the PDP to external sources of attributes e.g. LDAP
or databases.
17

18. ABAC in practice
18
Policies
Subject:
Name: Alice
Department: Marketing
Action:
Type: Update
Object:
Type: Report
Mode: Draft
Department: Marketing
Context:
Location: London
Time: between 9am and 6pm GMT

19. XACML
24

20. XACML
The "eXtensible Access Control Markup Language" defines a declarative fine-grained,
attribute-based access control policy language, an architecture, and a processing model
describing how to evaluate access requests according to the rules defined in policies.
This was thought to promote interoperability between different implementations by
multiple vendors.
XACML can be considered:
● ABAC
● PBAC
● RBAC
25

21. XACML
26

22. Access control in
microservices
27

23. New challenges
● Authentication and authorization needs to be handled in each microservice
● Microservices should follow the principle of single responsibility. A microservice only
handles its own business logic.
● Authentication and authorization in the microservices architecture involves
scenarios that are more complex, involving users accessing microservice
applications, third-party applications accessing microservice applications, and
multiple microservice applications accessing each other.
28

24. OPA
30

25. In brief
Open Policy Agent main characteristics:
● open source
● general-purpose policy engine
● high-level declarative language (Rego) that lets you specify policy as code
● REST APIs to offload policy decision-making
● decoupling policy decision-making from policy enforcement
● Being able to receive and reply with arbitrary structured data (e.g., JSON)
31

26. In brief
32

27. Rego
Rego queries are assertions on data stored in OPA. These queries can be used to define
policies that enumerate instances of data that violate the expected state of the system.
Using Rego for defining policy is easy to read and write.
Rego is declarative so policy authors can focus on what queries should return rather than
how queries should be executed. These queries are simpler and more concise than the
equivalent in an imperative language.
https://play.openpolicyagent.org/
33

28. XACML
Open Policy Agent is similar to XACML in that it provides a policy decision point,
externalized authorization, and a policy language (REGO).
It specializes in infrastructure authorization (e.g. for Kubernetes, Istio...) rather than
general-purpose, API-centric, or data-centric which XACML addresses.
34

29. Integrating OPA
2 main interfaces:
1. Evaluation: OPA’s interface for querying for policy decisions.
2. Management: OPA’s interface for deploying policies, understanding status,
uploading logs, and so on. Distributing policy, retrieving status, and storing logs in
the same way across all OPAs provides a unified management plane for policy
across many different software systems.
35

30. Policies evaluation
OPA supports different ways to evaluate policies:
● REST API returns decisions as JSON over HTTP.
● The Go API (GoDoc) returns decisions as simple Go types (bool, string,
map[string]interface{}, etc.)
● WebAssembly compiles Rego policies into WASM instructions so they can be
embedded and evaluated by any WebAssembly runtime
● The SDK provides high-level APIs for obtaining the output of query evaluation as
simple Go types (bool, string, map[string]interface{}, etc.)
36

31. OPA and / or
API Management
37

32. Brothers in arms
OPA is the perfect companion of an API Management especially in the new microservice
/ lightweight oriented new world.
While XACML was standardized and has been adopted by some vendors, it was
considered heavyweight and more difficult to define in terms of policies (XML horror,
reminds you of anything you REST aficionados?)
On the base of this vision and of a more modular approach to API Management, several
projects have been initiated, including https://github.com/kuadrant/authorino
38

33. Demo
39

34. Setup
A simple HTTP web server that accepts any HTTP GET request that you issue and
echoes the OPA decision back as text.
Our policy is:
● People can see their own salaries (GET /finance/salary/{user} is permitted for
{user})
● A manager can see their direct reports' salaries (GET /finance/salary/{user} is
permitted for {user}’s manager)
40

35. Components
41
OPA
REST
Microservice
Bundle
OPA can periodically download bundles of
policy and data from remote HTTP servers.
The policies and data are loaded on the fly
without requiring a restart of OPA
Authorize ?
Sync
policies
Alice
request

36. Steps
❏ Executing a request as Alice
❏ Executing a request as Bob
❏ Executing a request as Betty
42

37. Loading … PLEASE WAIT
Demo time
43

38. What just happened
✓ Executing a request as Alice
✓ Executing a request as Bob
✓ Executing a request as Betty
44

39. Comments
45

40. Thank you.
46