[
https://issues.apache.org/jira/browse/KNOX-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandeep More updated KNOX-3048:
-------------------------------
Description:
*Problem Statement:*
Currently Knox has the ability for specific users (say for e.g. {{sp_user}}) to
impersonate other users (say for e.g.{{ot_user}}). This is driven by configs
defined in a topology. Currently these configs are needed for each user that
impersonates other users (i.e. {{sp_user}}), this can get out of hand quickly
and can be difficult to maintain.
To solve this problem the proposed solution uses a group level impersonation
configuration. This configuration will be based on the virtual groups feature
that is already available in Knox. With this new configuration we can have
specific users who belong to a virtual group/s (based on conditions such as
{{(match groups 'analyst|scientist') }}) impersonate other users. This will
significantly cut down on the config properties and keep them readable and
maintainable.
was:
It would be useful to allow the ability to configure proxy user impersonation
configuration for all those users belonging to a particular group.
For example, topologies currently require such configuration for every "end
user" who is designated as a Knox admin to perform impersonation for the token
API. This potentially results in too much config in a topology, and represents
an administration burden on Knox admins.
The proposal is to add support for groups, for which the surrogate proxy user
config could be defined (once) in the topology, for which authenticated users
would be validated against their membership in the configured group before
being permitted to perform impersonation.
This can be supported by adding a qualifying prefix (e.g., GRP__) to a group
name, and the ACL will be created.
*Example provider configuration with "surrogate" admin group proxyuser
configuration*
{code:java}
<provider>
<role>identity-assertion</role>
<name>Default</name>
<enabled>true</enabled>
<param>
<name>hadoop.proxyuser.impersonation.enabled</name>
<value>true</value>
</param>
<param>
<name>hadoop.proxyuser.GRP__admin.users</name>
<value>*</value>
</param>
<param>
<name>hadoop.proxyuser.GRP__admin.groups</name>
<value>*</value>
</param>
<param>
<name>hadoop.proxyuser.GRP__admin.hosts</name>
<value>NONE</value>
</param>
</provider> {code}
With this type of configuration, an extension of
_org.apache.hadoop.security.authorize.DefaultImpersonationProvider_
can be implemented, overriding the following method
_public void authorize(UserGroupInformation user, String remoteAddress) throws
AuthorizationException_
to catch the AuthorizationException resulting from the lack of any
user-specific ACL, and check for ACLs associated with the impersonating user's
groups.
> Surrogate proxy user configuration for user groups
> --------------------------------------------------
>
> Key: KNOX-3048
> URL: https://issues.apache.org/jira/browse/KNOX-3048
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Affects Versions: 2.0.0
> Reporter: Philip Zampino
> Assignee: Sandeep More
> Priority: Major
> Fix For: 2.1.0
>
>
> *Problem Statement:*
> Currently Knox has the ability for specific users (say for e.g. {{sp_user}})
> to impersonate other users (say for e.g.{{ot_user}}). This is driven by
> configs defined in a topology. Currently these configs are needed for each
> user that impersonates other users (i.e. {{sp_user}}), this can get out of
> hand quickly and can be difficult to maintain.
> To solve this problem the proposed solution uses a group level impersonation
> configuration. This configuration will be based on the virtual groups feature
> that is already available in Knox. With this new configuration we can have
> specific users who belong to a virtual group/s (based on conditions such as
> {{(match groups 'analyst|scientist') }}) impersonate other users. This will
> significantly cut down on the config properties and keep them readable and
> maintainable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
