[
https://issues.apache.org/jira/browse/KNOX-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry McCay updated KNOX-929:
-----------------------------
Fix Version/s: (was: 0.15.0)
1.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
> Priority: Major
> Labels: KIP-7, security
> Fix For: 1.1.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
(v7.6.3#76005)
