[
https://issues.apache.org/jira/browse/KNOX-3016?focusedWorklogId=909233&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-909233
]
ASF GitHub Bot logged work on KNOX-3016:
----------------------------------------
Author: ASF GitHub Bot
Created on: 11/Mar/24 15:22
Start Date: 11/Mar/24 15:22
Worklog Time Spent: 10m
Work Description: lmccay commented on code in PR #876:
URL: https://github.com/apache/knox/pull/876#discussion_r1519906008
##########
gateway-provider-security-jwt/src/main/java/org/apache/knox/gateway/provider/federation/jwt/filter/AbstractJWTFilter.java:
##########
@@ -300,8 +302,23 @@ protected Subject createSubjectFromToken(final JWT token)
throws UnknownTokenExc
public Subject createSubjectFromTokenIdentifier(final String tokenId) throws
UnknownTokenException {
TokenMetadata metadata = tokenStateService.getTokenMetadata(tokenId);
+ String username = null;
if (metadata != null) {
- return createSubjectFromTokenData(metadata.getUserName(), null);
+ String type = metadata.getMetadata(TYPE);
Review Comment:
Yeah, this is kind of a weird thing. I have a python script that is
targeting this usecase for the time being and is setting that metadata now. It
wouldn't surface in Knox code unless we had specific APIs or UI or something
that leverages this generic capability in such a vertical specific context. I'm
thinking that for now this is just a convention that needs to be followed for
this usecase. Do you have some other suggestion?
Issue Time Tracking
-------------------
Worklog Id: (was: 909233)
Time Spent: 40m (was: 0.5h)
> Add Support for Client Credentials Flow with KnoxTokens
> -------------------------------------------------------
>
> Key: KNOX-3016
> URL: https://issues.apache.org/jira/browse/KNOX-3016
> Project: Apache Knox
> Issue Type: Bug
> Components: JWT
> Reporter: Larry McCay
> Assignee: Larry McCay
> Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Adding support for integrations to Knox proxied services and APIs via OAuth
> style cllient credentials flow. This allows an integration that is provided a
> CLIENT_ID and CLIENT_SECRET to authenticate to Knox and directly access
> proxied services with those or exchange those credentials for short lived JWT
> based access, id and refresh tokens.
> This change introduces only the acceptance of the Knox TokenID and Passcode
> tokens as CLIENT_ID and CLIENT_SECRET in a standard OAuth 2.0 client
> credentials flow request body. This body will contain the following params:
> 1. grant_type and it will be "client_credentials"
> 2. client_id which will be the KnoxToken tokenId or KnoxID
> 3. client_secret which will be the passcode token for which we store the hash
> Authentication using this flow will result in the effective user being what
> is provided as the CLIENT_ID.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
