[
https://issues.apache.org/jira/browse/KNOX-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry McCay updated KNOX-1740:
------------------------------
Description:
There are token exchange scenarios where an application may want to acquire a
KnoxToken on behalf of a user authenticated by the application. We need to
implement a version of the Hadoop Trusted Proxy/Impersonation pattern for Knox
at the topology level.
This includes:
* Principal assertion method (possibilities: doAs query param, path segment
within an API, HTTP header)
* Config within topology for trusted principals, groups that they are allowed
to impersonate, users that they are allowed to impersonate, ip address from
which requests are expected
* Make part of the identity assertion provider since this is the provider that
determines which identity to assert to the down stream service
* Config will need to be qualified by service due to the multiple services per
topology
Example to indicate which type of impersonation mechanism to use for a given
service/s:
{code}
<param>
<name>path.segment.impersonated.principal</name>
<value>IDBROKER;credentials</value>
</param>
<param>
<name>header.impersonated.principal</name>
<value>*;SM_USER</value>
</param>
<param>
<name>query.param.impersonated.principal</name>
<value>WEBHDFS,HIVE;doas</value>
</param>
{code}
was:
There are token exchange scenarios where an application may want to acquire a
KnoxToken on behalf of a user authenticated by the application. We need to
implement a version of the Hadoop Trusted Proxy/Impersonation pattern for Knox
at the topology level.
This includes:
* Principal assertion method (possibilities: doAs query param, path segment
within an API, HTTP header)
* Config within topology for trusted principals, groups that they are allowed
to impersonate, users that they are allowed to impersonate, ip address from
which requests are expected
* Make part of the identity assertion provider since this is the provider that
determines which identity to assert to the down stream service
* Config will need to be qualified by service due to the multiple services per
topology
> Add Trusted Proxy Support to Knox
> ---------------------------------
>
> Key: KNOX-1740
> URL: https://issues.apache.org/jira/browse/KNOX-1740
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Reporter: Larry McCay
> Assignee: Larry McCay
> Priority: Major
> Fix For: 1.3.0
>
>
> There are token exchange scenarios where an application may want to acquire a
> KnoxToken on behalf of a user authenticated by the application. We need to
> implement a version of the Hadoop Trusted Proxy/Impersonation pattern for
> Knox at the topology level.
> This includes:
> * Principal assertion method (possibilities: doAs query param, path segment
> within an API, HTTP header)
> * Config within topology for trusted principals, groups that they are
> allowed to impersonate, users that they are allowed to impersonate, ip
> address from which requests are expected
> * Make part of the identity assertion provider since this is the provider
> that determines which identity to assert to the down stream service
> * Config will need to be qualified by service due to the multiple services
> per topology
> Example to indicate which type of impersonation mechanism to use for a given
> service/s:
> {code}
> <param>
> <name>path.segment.impersonated.principal</name>
> <value>IDBROKER;credentials</value>
> </param>
> <param>
> <name>header.impersonated.principal</name>
> <value>*;SM_USER</value>
> </param>
> <param>
> <name>query.param.impersonated.principal</name>
> <value>WEBHDFS,HIVE;doas</value>
> </param>
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
