Closed ttschampel closed 3 weeks ago
@ttschampel It seems like this clarifies quite a few things conceptually. It seems like, as a platform admin, I can define my own "trusted" and "untrusted" PEPs. I can define an Environmental Entity for a PEP I deem to be less secure for some reason and give it more obligations through Subject Mappings, and I can define another I deem to be trusted and give it no obligations. The accessibility of my platform's PEPs remains configurable through policy how I see fit, and resolutions of entities is the responsibility of my ERS code.
Is this understanding accurate in the examples above access = dataAttributes(subjectEntities) && obligations(environmentEntities)
? Since entities are resolved by ERS, there's nothing also stopping me from defining the API such that access = environmentEntity(subject, dataAttributes, obligations)
where the environment could theoretically override anything about a subject (including removing it completely from the entity resolution) depending solely on my ERS logic?
@ttschampel I am probably missing something but why is the second row in the table a deny vs the first row?
ALLOW | {[cls:topsecret, relto:usa]} |
---|
vs
DENY | {[cls:topsecret, relto:usa]} | [relto:usa] |
---|
Is it because the derived obligation or environment is missing the cls:topsecret
entitlement?
Yes, b/c there is a derived obligation that is not met
During arch meeting today this was approved.
Background
This is a follow on to ADR: Attribute Value Scoping to handle the same problem with a simpler approach through the use of typed Entities.
The Entity type provides context to policy enforcement on how to scope data policy enforcement logic and those derived from obligations. The initial Enum of Entity Types:
Examples
Given a Resource with a data policy:
{[cls:topsecret, relto:usa, relto:gbr]}
Then the following policy decisions where the derived obligations are scoped to ENVIRONMENT type entities:
Policy API Changes
The only Policy API change is the addition of Entity Type enum and type property to the authorization.Entity message
Entity Type Assignment
Logical Decision Requests against the Policy Authorization endpoints can take place as they do now with the default SUBJECT Entity type representing the intent of most use cases today. PEPs will now be able to add additional Environmental Entities to model more advanced request scenarios.
OIDC Token based entity chain resolution is still the responsibility of the Entity Resolution Service and needs to be updated to include the Entity Type while constructing the Entity Chain from the JWT.
See Token Extraction Examples
Subject Mappings
ENVIRONMENT entities can be entitled the same way as SUBJECT entities through the use of Subject Mappings. It is the responsibility of the policy administrator to not entitle SUBJECT entities with entitlements meant ONLY for ENVIRONMENT entities. e.g. a SUBJECT should not be entitled to drm:watermarking.
The addition of a Subject Mapping scope (Policy API addition) may be helpful to scope subject mappings to entities of a specific type.
Policy Enforcement
Today policy enforcement requires that all entities in the chain satisfy the data attribute policies for the set of resource data attributes.
With Entity Types in place; this enforcement logic should be scoped to only
SUBJECT
type entitiesDerived Obligations
Derived attributes from obligations should be enforced in a similar way as data attributes with two major differences:
ENVIRONMENT
type entities.To support this, a mechanism to retrieve derived obligations for a Decision Request's Resource Attributes as part of the GetDecisions endpoint is needed. See Obligations ADR. The set of derived obligations can then be cycled through the access.pdp against the environmental type entities.
If derived obligations exist, but no environmental entities exist - the decision should be
DENY
Token Entity Chain Extraction Examples
Example JWTs for different OIDC Flows using Keycloak. Note, these are simple examples and more complex extraction or context may be needed to fetch session level information from an IDP to gather things such as IP Address, etc.
Client Credential Flow
In this example, the expected Entity Chain is below; basically creating an environmental entity on the fly for the standalone client:
Authorization Code Flow
In this example user
mmiller
has authenticated using the web clientcop-web
. The expected entity chain:OBO: On-behalf Of
This is an example on-behalf of flow using Keycloak's Token Exchange by client opentdf for an authenticated opentdf-sdk client.
There is no clear way to understand, without additional context, that this is an OBO flow. Given this, custom logic to understand this an OBO flow will have to live in the ERS until Keycloak creates more standards based claims such as
act
Creates an entity chain :