[
https://issues.apache.org/jira/browse/KNOX-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3143:
--------------------------------
+Apache Knox 3.0.0 release preparation+
We are about to cut the 3.0.0 release branch. master will move on to 3.1.0.
This issue is currently unresolved and is not automatically included in 3.0.0.
Please choose one of the following:
# If this belongs in 3.0.0: once the branch is cut, cherry-pick your commit(s)
onto the new v3.0.0 branch in addition to master. Leave Fix Version = 3.0.0 so
we can track it.
# Do nothing: we will move this issue to the next release (3.1.0) as part of
release cleanup.
If we don't hear back and see no cherry-pick, the issue will be re-targeted to
3.1.0. Thanks!
> 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)
