[
https://issues.apache.org/jira/browse/KNOX-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-929:
-------------------------------
Fix Version/s: 3.0.0
(was: 2.1.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.
> Identity Broker API
> -------------------
>
> Key: KNOX-929
> URL: https://issues.apache.org/jira/browse/KNOX-929
> Project: Apache Knox
> Issue Type: New Feature
> Components: Server
> Reporter: Larry McCay
> Assignee: Larry McCay
> Priority: Major
> Labels: KIP-11, KIP-7, security
> Fix For: 3.0.0
>
>
> Ability to request a token on behalf of another user w/ cryptographically
> verifiable trust relationship. This is essentially an extension of the
> KnoxToken service where the username of the authenticated user is presented
> and the resulting token should represent
> Ability to specify what type of token is being requested. There are use cases
> where Knox may be expected to interact with another STS service in order to
> acquire another token. This may need to be addressed as a separate REST
> resource and API or perhaps it can be a subtype of a more generic token
> response. Current KnoxToken API response looks something like:
> bq. {
> "access_token":"eyJhbGciOiJSUzI1NiJ9.
>
> eyJzdWIiOiJndWVzdCIsImF1ZCI6InRva2VuYmFzZWQiLCJpc3MiOiJLTk9YU1NPIiwiZXhwIjoxNDkzNTM4MjY1fQ.
>
> FHsIdhlCi_h61PEXoKSbIEp5AlnVe9U5uEgcp7ktmVS8kLClFD2dj0KS-8sSnvNiPYdyZhEvxqNhjmhqXMd2YQz97O6FUSGf69_
>
> lmarJPjz9K_6sDgrgpZnVQhUfHUG3k6-zetqzKZhu3gZYVLfu36TXb3C62TfXIrPF2qI9psM",
> "target_url":"https://localhost:8443/gateway/tokenbased";,
> "token_type":"Bearer ",
> "expires_in":1493538265484
> }
> It is possible that the above could be used to represent multiple token types
> by adding additional token_type values for the client to interrogate and
> handle appropriately.
> Of course, a client should request a token from a KnoxToken service that is
> configured to provide the desired token.
> Perhaps, we limit an endpoint to a single token_type or we could configure a
> single service endpoint to service requests for certain types and rely on the
> client to ask for the desired one and default to current 'Bearer' type.
> Where 'Bearer' implies our Knox JWT token.
> Other potential types would include things like S3 or AWS tokens.
> We may also want to consider base64 encoding the token for certain types.
> Clients would have to know whether it needs to be decoded based on the type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
