10D/ PBAC 102: Architecting Authorization to Protect Your Data
PBAC 102: Architecting Authorization to Protect Your Data
Convener: Jacob Siebach
Notes-taker(s): Judith Bush, edited by Jacob Siebach
Tags for the session - technology discussed/ideas considered:
Policy-based authorization, attributes for authorization
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Assuming a domain driven design - domain is the business area and the data in that area. The domain is the authoritative/definitive source.
Four pillars of IDP: Identification, Authentication, Access management, Authorization
Is the identity attempting to access this resource allowed to do this.
Protect the doman’s data. Rely on authorization-important attributes. Does not divulge data (like showing a drivers license to prove authorized to enter an age gated space) Super fast: part of architecture.
How to demonstrate policy compliance without divulging information.
AuthZ Design 1
Must NOT cross domain boundaries
Tight coupling Eg: to HR database (Nooooo!)
Domain that has the data should decide the attribute and not interpreted cross domain from a different attribute
AuthZ Design 2
Invoking the authorization service
Must pass subject, target, client
Must pass policy to be checked
Must allow for other data to be passed
Example: the nuclear lab is the only domain that needs to know principle took safety training, the nuclear lab should be able to provide that to authZ so authZ can make that decision.
From Swapna Radha to Everyone: (11:58 AM): is it a good idea to have a trace on authorization service? To see who accessed what and when it happened? Or, is it a security issue?
AuthZ Design 3
No tokenomics for authz
AuthZ engine lives in trusted network
Engine talks directly to service
(EG: no one can scan through principles to find a principle that gets the token)
AuthZ Design 4
Domains created the attributes
Attributes should not be confidential
Business decision, not technical
Compare birthdate to “are you old enough”? Authorization attribute may be derived from PII
AuthZ Design 5
No down-time for domains using authorization
Must be able to update policies in real-time
No redeployment for domain code
Provide authz even when domain down -- domain A depends on domain B attribute; if authZ
persists the domain B attribute domains A&B need not be tightly coupled
Challenge by Allan Foster: what about a policy that says “within a 30 days of your birthday” -- is this business logic or authorization? Is the hard stuff now business logic? Now have to couple the domain with the PII pool (the database field) .
Response: is it REALLY the case that that business system wouldn’t have access to the PII to begin with?
Jacob asserts calendaring systems aren’t so much authZ: they are business logic.
The university included a domain for identity. Then the “locker rental” team couldn’t get a list of who has rented lockers because they had to use the ID to look up. So yeah, the locker rental folks could get a self asserted name or a decoupled name, so each domain is responsible for recording the data that it needs for a given identifier. The whole organization maintains the identifiers for each person, but then each domain holds the data that correlates to that identifier for its own business purposes.
(Chuckling over whether a single source of truth is a source of perpetual employment)
Back up to authZ: Jacob asserts the business process that cares about the birthdate . The additional data from the business domain would/could then include IsWithin30DaysOfBirthDate. (But perhaps still better in the business logic to tell user the window of the action)
From Alan Karp to Everyone: Jacob described the authorization process as happening when the request is received. That approach can lead to a confused deputy vulnerability. (https://en.wikipedia.org/wiki/Confused_deputy_problem) It’s better to separate the authorization decision from the request as done by UMA.
Role explosion leads to over provisioning.
Separating access control from authorization is a solution to the Confused deputy problem
An OAuth token with a bunch of scopes is like a role with a bunch of permissions -- if the permissions/scopes are granted based on this policy engine -- it solves a broad set of issues. Alan Karp, poorly paraphrased
What is a “student” vs one domain requiring “in a degree program” whereas another domain “enrolled in X or more hours” -- different attributes
A domain that controls the definition of an attribute does not require other domains to “sign-off” on the definition. This allows an organization to have firm definitions in its policies and bypass the morass of red tape and meetings that come from trying to align attributes for different domains.