openid
Allowing a PDP to specify Application id in a multi-Application/PEP to PDP environment
The current specification (1.1-01) defines resources but does not define the applications that may be providing the actions against the resources.
Should "application" be a separate thing? For example, you could have a todo app and a projectMgmt app that work against the same resources (todos). Having an application parameters allows for different permissions in the context of different applications against the same resource.
As an example, in Hexa Policy, the resource is mapped to the condition while the application is the target of the policy.
{
"meta": {
"version": "0.7",
"description": "Delete a todo if admin or owner of todo",
"policyId": "DeleteTodo"
},
"subjects": [
"role:admin",
"role:editor"
],
"actions": [
"can_delete_todo"
],
"condition": {
"rule": "subject.roles co admin or (subject.roles co editor and resource.properties.ownerID eq subject.claims.email)",
"action": "allow"
},
"object": "todo"
}
In the current Authzen implementation, we have to associate the requesting PEP client with the application "todo" in the event of a PDP supporting multiple applications.
--> Having the application in the Authzen request would be useful.
In OpenFGA we support multiple 'stores', which can be used for multiple environments or tenants. Currently we are using the store_id as part of the AuthZen base url.
If we have another way to specify it, we can use the same base URL for multiple stores, which would be nicer.
I think these implementation-specific considerations shouldn't be in the standard. There's a variety of ways you could implement your authzen endpoint to support your needs. If we start adding implementation specific stuff to the authzen payload, then we should also consider Indykite's requirements, as well as everybody else's, and we wouldn't reach the end of it...
As stated by @baboulebou and @aaguiarz, these are implementation-specific requirements that are important but belong in profiles rather than the core spec.
Once we have ratified the core spec, we can work on app-specific profiles such as:
- The AuthZEN Profile of Salesforce CRM
- The AuthZEN Profile of SAP...
These profiles would define mandatory attributes on top of the core AuthZEN attributes. These profiles can specify attribute identifiers. This is what occurred with SAML and XACML where specific bodies came in and added profiles for use cases such as IP protection and export control.
