[
https://issues.apache.org/jira/browse/KNOX-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry McCay updated KNOX-3120:
------------------------------
Description:
Similar to KNOX-3112 which added an API for CLIENTID for acquiring client
credentials flow CLIENT_ID and CLIENT_SECRET we should add a specialized
extension of KNOXTOKEN for an APIKEY API.
The intent here is to add an API that both frees up KNOXTOKEN to be deployed
within the same topology for known token exchange patterns as well as to codify
the conventions that are being used by some that are using the passcode token
as an API Key.
We will make appropriate configuration and metadata defaults within the API
implementation to reduce operations and config requirements and to return a
translated response with the passcode as an {api_key: xxxx} or some similar
response that meets standard or defacto standard expectations.
was:
Given the ability to support the OAuth client credentials flow with a
specialized use of the tokenid and passcode token from the KNOXTOKEN API, we
should add a corresponding API for acquiring the CLIENT_ID and CLIENT_SECRET
without requiring consumers to understand this specialized use. We will codify
the conventions being used for that into the new API extension of KNOXTOKEN
which will make CLIENTID's first class concepts rather than an interpretation
of KNOXTOKEN API responses.
> Add a specialized use API for API KEY based on KNOXTOKEN API
> ------------------------------------------------------------
>
> Key: KNOX-3120
> URL: https://issues.apache.org/jira/browse/KNOX-3120
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Reporter: Larry McCay
> Assignee: Larry McCay
> Priority: Major
> Fix For: 2.2.0
>
>
> Similar to KNOX-3112 which added an API for CLIENTID for acquiring client
> credentials flow CLIENT_ID and CLIENT_SECRET we should add a specialized
> extension of KNOXTOKEN for an APIKEY API.
> The intent here is to add an API that both frees up KNOXTOKEN to be deployed
> within the same topology for known token exchange patterns as well as to
> codify the conventions that are being used by some that are using the
> passcode token as an API Key.
> We will make appropriate configuration and metadata defaults within the API
> implementation to reduce operations and config requirements and to return a
> translated response with the passcode as an {api_key: xxxx} or some similar
> response that meets standard or defacto standard expectations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
