We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A platform team at a mid-size fintech ran 40 . Authorization checks were embedded in application code. Some services used middleware. Others checked inside handlers. A few pushed the logic into database queries. When compliance required a new rule ("users in the EU cannot access data classified as US-only"), engineers had to find and update authorization logic in every service. Three teams implemented it differently. Two services were missed entirely, discovered only during an audit six months later.
Policy-based access control externalizes authorization into a dedicated engine. Instead of if (user.role === 'admin') scattered through application code, services send authorization queries to a policy decision point. The PDP evaluates declarative policies and returns allow or deny. Change the policy in one place, and every service enforces it on the next request.
Netflix runs Open Policy Agent (OPA) across hundreds of microservices. Spotify uses OPA to enforce data access policies in their data platform. Styra (the company behind OPA) reports adoption at over 150 million policy decisions per second across their customer base.
The XACML standard defines four components that every policy engine implements, whether or not it uses XACML's XML format:
| Component | Role | Real-World Implementation |
|---|---|---|
| PDP (Policy Decision Point) | Evaluates policies against request data | OPA sidecar, Cedar evaluator, Google Zanzibar |
| PEP (Policy Enforcement Point) | Intercepts requests and calls the PDP | , Envoy proxy, application middleware |
| PAP (Policy Administration Point) | Where policies are authored and stored | Git repository, Styra DAS, admin UI |
| PIP (Policy Information Point) | Provides additional attribute data for decisions | LDAP directory, HR system, resource metadata DB |
OPA (Open Policy Agent) is the most widely adopted open-source engine. Policies are written in Rego, a declarative language designed for expressing access control rules:
allow {
input.method == "GET"
input.path == ["api", "reports"]
input.user.department == input.resource.department
time.now_ns() >= time.parse_rfc3339_ns(input.user.shift_start)
}
AWS Cedar is Amazon's purpose-built authorization language. It powers Amazon Verified Permissions and is designed for fine-grained authorization at scale. Cedar policies are more readable than Rego for common RBAC/ABAC patterns.
Google Zanzibar is the relationship-based system behind Google Drive, YouTube, and Maps. It answers "can user X do action Y on resource Z?" by traversing a graph of relationships. SpiceDB and Ory Keto are open-source implementations.