feat(authz): defer to request auth as decision/entitlements entity

[jakedoublev]

Proposed Changes

• ADR for 4th entity identifier proto oneof value
• proto for 4th entity identifier oneof value (a boolean to pull entity token from request auth)

Checklist

• I have added or updated unit tests
• I have added or updated integration tests (if appropriate)
• I have added or updated documentation

Testing Instructions

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	178.551644ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	105.862349ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	361.120431ms
Throughput	276.92 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	41.195182689s
Average Latency	409.252079ms
Throughput	121.37 requests/second

NANOTDF Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	28.573362992s
Average Latency	284.759446ms
Throughput	174.99 requests/second

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	175.577554ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	108.426623ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	366.668116ms
Throughput	272.73 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	41.339273752s
Average Latency	410.969525ms
Throughput	120.95 requests/second

NANOTDF Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	28.191295685s
Average Latency	280.740084ms
Throughput	177.36 requests/second

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	194.733306ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	101.43249ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	363.611993ms
Throughput	275.02 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	39.007630233s
Average Latency	388.358175ms
Throughput	128.18 requests/second

NANOTDF Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	27.023482445s
Average Latency	269.236453ms
Throughput	185.02 requests/second

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	159.631748ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	97.428321ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	349.183821ms
Throughput	286.38 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	39.537689028s
Average Latency	392.411074ms
Throughput	126.46 requests/second

NANOTDF Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	27.324998214s
Average Latency	272.28009ms
Throughput	182.98 requests/second

[cassandrabailey293]

just a nit but will it be confusing for folks? If EntityIdentifier_UseRequestToken is false, it kind of implies "the request token is not being used", rather than, "the request token is not being used AS the entity itself". maybe that's just me

[jrschumacher]

Yeah that's a valid point @cassandrabailey293. Originally it was EntityIdentifier_RequestToken, but I requested a verb to prefix it since its a boolean unlike the other options.

@jakedoublev @c-r33d we could consider something like _PassthroughRequestToken which might be a little more descriptive and less ambiguous per Cass' feedback.

[jakedoublev]

I'm happy to change the name to whatever makes most sense. I think some other options are:

FromRequestToken
DeriveFromRequestToken
FromAuthHeader
PassthroughRequestAuthToken

[cassandrabailey293]

I like the _From prefix because it's clear you're deriving the entity from the request token. but the fact that this arg itself is a boolean makes it feel a little weird, since _From kind of implies that the object type is whatever follows the _From ...

_PassthroughRequestToken or _PassthroughRequestToken is more explicit. It doesn't "sound as nice" but is more clear IMO. maybe something like _IsRequestToken ?

naming things is hard 😅

[jakedoublev]

I'm good with either of those, but just to throw one more candidate in: _PassthroughFromRequestToken?

[cassandrabailey293]

the PEP / client code using the SDK would be responsible for properly setting this, is that correct? since it's explicit, does that mean the client code will explicitly pass in NULL or FALSE when you don't want to use the token as the entity and use an entity representation instead?

what would be the implication if I as a developer accidentally (or intentionally) set this flag to TRUE within a PEP where the NPE client is super-privileged?

[jrschumacher]

the PEP / client code using the SDK would be responsible for properly setting this, is that correct?

Yes, this would be part of the GetDecision(GetDecisionRequest) request property.

Since it's explicit, does that mean the client code will explicitly pass in NULL or FALSE when you don't want to use the token as the entity and use an entity representation instead?

There is a check in the proto that the value MUST be true (expression: "this == true"). So setting to NULL or FALSE would result in a clientside error if interceptors are used and a serverside error when the request is sent.

what would be the implication if I as a developer accidentally (or intentionally) set this flag to TRUE within a PEP where the NPE client is super-privileged?

The developer would get a get a successful decision response and the audit trail would show that the NPE was granted access (not the entity who initiated the request with the PEP). The same accidental / malicious concerns could be raised about a PEP sending a GetDecisionRequest with the token field populated with their PEP's token.

Additionally, we should no longer need to be concerned with the accidental super-privileged PEP with the work @jakedoublev did to add environmental support to subject mappings.

[jakedoublev]

There is a check in the proto that the value MUST be true (expression: "this == true"). So setting to NULL or FALSE would result in a clientside error if interceptors are used and a serverside error when the request is sent.

The other piece here @cassandrabailey293 @jrschumacher is that this EntityIdentifier itself is a oneof, so the PEP could never set both this passthrough token flag to true and an entity chain, JWT, or registered resource FQN within a valid request. If this new option is true, it must be the only identified entity in the request, and vice versa if one of the other types is provided.

[cassandrabailey293]

super helpful explanations, thank you both! it quells my concerns around there being an exploit. almost goes without saying but this should be reflected in the documentation (both where we talk about authorization and entities, as well as in the openapi generated docs).

[jrschumacher]

Note, talking to @jakedoublev my recollection of where that logic got put is wrong its part of Auth service.

[jakedoublev]

Note, talking to @jakedoublev my recollection of where that logic got put is wrong its part of Auth service.

Exactly. Environment/Subject entities are defined in an entity chain by ERS, and when Auth Service is decisioning, it will skip environment entities in the chain.