[
https://issues.apache.org/jira/browse/KNOX-3016?focusedWorklogId=909154&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-909154
]
ASF GitHub Bot logged work on KNOX-3016:
----------------------------------------
Author: ASF GitHub Bot
Created on: 11/Mar/24 10:58
Start Date: 11/Mar/24 10:58
Worklog Time Spent: 10m
Work Description: smolnar82 commented on code in PR #876:
URL: https://github.com/apache/knox/pull/876#discussion_r1519517586
##########
gateway-provider-security-jwt/src/main/java/org/apache/knox/gateway/provider/federation/jwt/filter/JWTFederationFilter.java:
##########
@@ -238,10 +241,33 @@ public Pair<TokenType, String> getWireToken(final
ServletRequest request) {
}
}
+ /*
+ POST /{tenant}/oauth2/v2.0/token HTTP/1.1
+ Host: login.microsoftonline.com:443
+ Content-Type: application/x-www-form-urlencoded
+
+ client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
+ &scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
+ &client_secret=sampleCredentials
+ &grant_type=client_credentials
+ */
+
+ // Let's check whether this is a client credentials oauth request or
whether
+ // the token has been configured for another usecase specific header
if (parsed == null) {
- token = request.getParameter(this.paramName);
- if (token != null) {
- parsed = Pair.of(TokenType.JWT, token);
+ String grantType = request.getParameter(GRANT_TYPE);
+ if (CLIENT_CREDENTIALS.equals(grantType)) {
+ // this is indeed a client credentials flow client_id and
+ // client_secret are expected now the client_id will be in
+ // the token as the token_id so we will get that later
+ token = request.getParameter(CLIENT_SECRET);
+ parsed = Pair.of(TokenType.Passcode, token);
+ }
Review Comment:
I think this code - along with the above comment that explains the different
query parameters in a client credentials flow request - deserves to be in a
private method and can be added before the original `parsed == null` check.
This way it's easier to read, IMO.
For instance:
```
// Let's check whether this is a client credentials oauth request
parsed = parsed == null ? parseOauthRequestClientCredentials(request) :
parsed;
// Finally, whether the token has been configured for another usecase
specific header
if (parsed == null) {
...
```
##########
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:
As you indicated in the PR's description,
> 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
Based on this, I've to ask if there is going to be a separate PR where the
`type` metadata is created when OAuth clients get a new token (and replay the
`tokenId` and `passcode` fields as `CLIENT_ID` and `CLIENT_SECRET`)?
##########
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);
+ // using tokenID and passcode as CLIENT_ID and CLIENT_SECRET will
+ // result in a metadata item called "type". If the valid is set
Review Comment:
I'm not sure I understand this sentence. Did you mean "if the `type` is set
to CLIENT_ID"?
Issue Time Tracking
-------------------
Worklog Id: (was: 909154)
Time Spent: 20m (was: 10m)
> 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: 20m
> 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)
