1. ®
POLICY-ENABLING YOUR SERVICES
USING ELASTIC DYNAMIC AUTHORIZATION
TO CONTROL ACCESS TO YOUR APIS,
MICROSERVICES, AND DATA.
GERRY GEBEL & DAVID BROSSARD

2. ®
API Growth

3. ®
A brief history of APIs
Enterprise Service Bus
CORBA
COM/DCOM
XML, WS-*, SOAP
XML Gateways
(Datapower…)
REST
API Gateways (Apigee…)
API Management
OAuth
gRPC
Service meshes (Istio)
Orchestration (Kubernetes)
Micro-gateways (42crunch,
Ambassador…)
Enterprise
Application
Integration
Service
Oriented
Architecture
API
Micro
services

4. ®
Authorization for APIs
Enterprise
Application
Integration
Service
Oriented
Architecture
API
Micro
services
Home-grown Home-grown
SAML
XACML
Home-grown
SAML
XACML
OAuth 2.0
Home-grown
SAML
XACML
OAuth 2.0
Framework-specific*
*CanCan, Laravel, Keycloak, Claims-based…
Framework-specific*
ALFA
OPA

5. ®
Comparing Authorization Approaches
Home-
grown
SAML OAuth 2.0 XACML ALFA OPA
Description Code inside the
applications
Open standard for
exchanging
authentication and
authorization data
between parties
OAuth 2.0 is the
industry-standard
protocol for
authorization.
Open standard
which defines a
declarative fine-
grained, attribute-
based access
control policy
language
Open lightweight
policy-based
standard for
attribute-based
access control
open source,
general-purpose
policy engine that
enables unified,
context-aware
policy enforcement
Policy-
based
No No No Yes Yes Yes
RBAC Yes Yes Yes Yes Yes Yes
ABAC Possibly No No Yes Yes Yes
Reusable No Yes Yes Yes Yes Yes
Applicable
to multiple
layers
No No No Yes Yes No

6. ®
what OAuth 2.0 is to SAML
ALFA is to XACML…

7. ®
The problem with tokens?
Token bloat, role-based, no relationship, opaque

8. ®
Token bloat
We create too many assertions / scopes that end up being stored inside the
identity token thus bloating it

9. ®
Frankenscope
When scopes blow up

10. ®
Identity-centric
All about roles and permissions – no room
for relationships or additional attributes

11. ®
The solution?
Policy Enablement

12. ®
The Ten Commandments of Authorization
1. Authorization shall be declarative  policy-based
2. Authorization shall be dynamic  runtime decision-making
3. Authorization shall use identity, action, & resource attributes
4. Authorization shall be decoupled from the application & data
5. Authorization shall be able to use relationships
6. Authorization shall be business-driven  all in it together
7. Authorization shall be transparent  easy to edit & audit
8. Authorization shall be scalable  protect one, protect all
9. Authorization shall be technology agnostic  APIs, data, & more
10. Authorization shall be future-proof  don’t make assumptions
about tomorrow

13. ®
Authorization for APIs & Data
Interceptor
Interceptor
Transactional authorization Data-centric authorization
Policy (ALFA)

14. ®
ALFA – the Abbreviated Language for
Authorization
• OASIS Draft Standard (2015)
• Lightweight JSON-like syntax for declarative attribute-based
policies
• Compatible with XACML & many other policy-based
architectures
• Fits into the CI/CD development cycle
• Authorization-as-ALFA-code

15. ®
Choose the right enforcement
• APIs & Microservices
• API gateways
• Micro-gateways
• Enforce on the way in… and out
• Data stores
• SQL proxies
• Elasticsearch filters
• Other? OData?

16. ®
Choose the right decision engine
• Central authorization engine, sidecar, or distributed
• Central control pane
• Stateless authorization engine  you can scale horizontally

17. ®
Demo
Authorization Applied to an API

18. ®
A demo
• This demo uses Apigee API Gateway
• The gateway calls out to an Axiomatics Cloud Policy Decision Point
• In the demo we authorize on the way in… and out
• Dan wants to view record 131
• Owner and status is redacted
• The original record

19. ®
Demo Policy (ALFA)
/*R1 - A manager can view any records */
rule manager{
target clause user.role == "manager"
clause action_id == "GET" or action_id == "view"
permit
}
/*R2 - An employee can view a record in their own department */
rule employeeView{
target clause user.role == "employee"
clause action_id == "view" or action_id == "GET"
condition record.department == user.department
permit
}

20. ®
Demo Policy – Masking
/*R2.1 - An client can view a record in their own department with
obligation to mask owner and status*/
rule clientView{
target clause user.role == "client"
clause action_id == "view" or action_id == "GET"
condition record.department == user.department
permit
on permit{
obligation fields {
mask_fields = "owner"
mask_fields = "status"
}
}
}

21. 21
®
Questions?
@davidjbrossard |@ggebel