[
https://issues.apache.org/jira/browse/KNOX-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry McCay updated KNOX-929:
-----------------------------
Description:
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.
was:
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.
> Identity Broker API
> -------------------
>
> Key: KNOX-929
> URL: https://issues.apache.org/jira/browse/KNOX-929
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Larry McCay
> Labels: KIP-7
> Fix For: 0.13.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
(v6.3.15#6346)
