10D/ PBAC 102: Architecting Authorization to Protect Your Data

PBAC 102: Architecting Authorization to Protect Your Data

Wednesday 10D

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:

See yesterday:

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

Security letters

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

Real time

(EG: no one can scan through principles to find a principle that gets the token)

AuthZ Design 4

Attribute Design

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.