[
https://issues.apache.org/jira/browse/KNOX-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3143:
--------------------------------
Fix Version/s: 3.0.0
(was: 2.2.0)
Due to the pending 2.1.0 release this JIRA has been pushed out to 3.0.0 as part
of a bulk update. If there is a specific reason to pull this back into the
2.1.0 release and you intend to provide a PR in the next few days please
provide justification and reset the Fix Version to 2.1.0.
> Add authorization related metadata to the issuance of CLIENT_ID and
> CLIENT_SECRET
> ---------------------------------------------------------------------------------
>
> Key: KNOX-3143
> URL: https://issues.apache.org/jira/browse/KNOX-3143
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Reporter: Larry McCay
> Assignee: Larry McCay
> Priority: Major
> Fix For: 3.0.0
>
>
> Current support for CLIENT_ID and CLIENT_SECRET for a client credentials flow
> leaves authorization up to policies and/or ACLs setup specifically for the
> client_id with some optional metadata available for searching and filtering
> tokens based on user name, comments, arbitrary tags.
> We can probably do better than this and potentially add some additional
> identity characteristics to the client_id that could at least be used within
> audit logs.
> My initial thinking around authorization and scopes was centered on the
> credentials representing some external user for which policies can be
> explicitly written.
> I am revisiting this context to include AI Agents and/or MCP Servers. While
> these tools may be leverage by an individual, they shouldn't necessarily have
> the same permissions as the individual. This is where the RBAC notion of user
> being applied to agents starts to break down.
> A user that has clearance for accessing certain resources themselves should
> NOT delegate that clearance to an agent that may make arbitrary decisions as
> to where to access it from or send it to. Therefore, we should add the notion
> of scopes to constrain what tools are able to do in the context of an
> extension of the user's identity.
> This will require us to consider scopes within service level authorization
> within the Knox Gateway as well as an endpoint from which downstream
> components can look up the scopes for authorization decisions by the PEPs
> within the platform.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
