21B/ Policy-based Authorization: The Abacus
Policy-Based Authorization: The Abacus
Thursday 21B
Convener: Jacob Siebach
Notes-taker(s): Judith Bush
Tags for the session - technology discussed/ideas considered:
Policy-based authorization
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
See previous PBAC sessions.
Abacus Authorization jacob@abacusauthz.com https://abacusauthz.com
ASSUME:
Domain driven design: Domain is business driven, self controlled
Policies protect access
Consider : identities (persons, device), authN (confirm the identity), access management (manual ways to designate certain controls, not derived by alternative attributes), authZ (can the identity do the thing)
Requirements
Protect domain’s data
ONLY allow access through API and not thru direct DB access
Rely on authZ-important attributes
authZ “over 21” not birthdate
BE SUPER FAST - part of infrastructure
How does Abacus keep fast: cache attributes.
Attributes super available
No load on other DBs
Reduce network traffic
Authz when domains are online
Domains own the attributes and push the attributes to the engine. Updates get pushed.
AuthZ engine has no DB connection, just the cache of data WHICH IS NOT PII
Thus attributes used in policies without seeing the data
LOG EVERYTHING
Maintain policy history
Allows auditing and metrics
Have different points calling the engines with different endpoints
SIEM can then integrate by watching
Verify that domains are changing their attributes no other
Support system
Logging analysis can show why X had access to Y then and not now . The attributes the decision was made on, the domain that owns the attribute, and can refer X to the the domain that changed the attribute or the system that changed the policy
How long to keep logs? Depends on business purpose
Consider Registration and the mad dash for signing up for classes and the churn, but then quiet. How to make registration provisioning quickly -- and engine specifically for that domain during the surge period populated with ONLY the attributes needed for that use case. -- but since many consuming domains use the attributes from the same domains, it is more efficient for the consuming domains to all share the same engine.
XAML allows circular references so they use a simple policy sets for an action on a resource. “Self service policy” written ones and included in the sets. Has their own grammar for speed in parsing. Efficient memory management.
Business owners implement their own policies through abacus UI.
Use with access management: user has access management role PLUS active employee attribute.
So core attributes can be used across many domains. Once ONE system gets the attributes provisioned and pushed, then many policy domains can benefit. Infrastructure builds up and benefits many policy domains.
Role is about what you are allowed to do, a capability, a feature you can utilize. Separate from permissions: what objects you can work with. - Neil Thomson.
When you are sending data to the authZ engine, you want to send data that is also specify the specific resource and action. File + author can be sent, so the policy can be “author of file can do thing”. Role can be “Report author” and policy can be that authors of report can edit, others can just view.
Polices are part of a policy set, where the set is an action on the resource. Don’t couple the action to a specific endpoint, but to the abstract, so the policies can apply across different interfaces.
Policies are centralized and can be easily audited. The specific folks with manual role grants can be easily audited.
Can drive role assignment for cloud services from the policy engine. Consider providing an LDAP connector that generates the “groups” from the policy engine.
Request: Subject, target, client ID of system, other bits of data (IP address, file owner, took training)
Response: Allow/Deny
Then a separate system for support to diagnose changes in authorization.
