This document discusses policy-based authorization approaches for APIs and microservices. It describes the limitations of traditional token-based authorization using SAML and OAuth and proposes a policy-based approach using the ALFA language. ALFA allows declarative attribute-based policies that can consider identity, action, resource attributes and relationships to make dynamic authorization decisions. The document recommends enforcing authorization at API gateways and data sources using a centralized or distributed policy decision engine. It demonstrates how ALFA policies can be used to authorize and redact fields in API responses.
BATTLEFIELD ORM: TIPS, TACTICS AND STRATEGIES FOR CONQUERING YOUR DATABASE
POLICY-ENABLING YOUR SERVICES USING ELASTIC DYNAMIC AUTHORIZATION TO CONTROL ACCESS TO YOUR APIS, MICROSERVICES, AND DATA
1. ®
POLICY-ENABLING YOUR SERVICES
USING ELASTIC DYNAMIC AUTHORIZATION
TO CONTROL ACCESS TO YOUR APIS,
MICROSERVICES, AND DATA.
GERRY GEBEL & DAVID BROSSARD
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
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
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
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"
}
}
}