[
https://issues.apache.org/jira/browse/KNOX-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-2714:
--------------------------------
Description:
As of now, authenticated users are allowed to acquire a Knox token for
themselves only. That is, the username the token is created for is fetched from
the request’s user principal. The goal is to be able to generate a Knox token
on behalf of somebody else.
To be able to do this, we need to enhance the current KnoxToken service API to
support a new query parameter called doAs. For instance:
{noformat}
curl -iku admin:admin-password -X GET
'https://localhost:8443/gateway/sandbox/knoxtoken/api/v1/token?doAs=bob’
{noformat}
In this case, the generated token will not belong to the _‘admin’_ user, but
it’s going to be created for {_}‘bob’{_}.
The newly introduced ‘doAs’ is an optional parameter: if not defined, the
generated token will belong to the authenticated user (in the above sample:
{_}‘admin’{_}).
Of course, we need to provide a way to control who can generate tokens for who,
so the following service-level configuration should be added too (they will be
defined in the given topology for the KNOXTOKEN service):
* {{knox.token.proxyuser.$username.users}} - indicates the list of users for
whom {{$username}} is allowed to create tokens. It is possible to set this to a
1-element list using the ‘*’ wildcard which means $username can generate tokens
for everyone. Defaults to an empty list that is equivalent to {{$username}} is
not allowed to impersonate anyone.
* {{{}knox{}}}{{{}.token{}}}{{{}.proxyuser.$username.groups{}}} - indicates
the list of group names for whose members $username is allowed to create tokens
for. It is possible to set this to a 1-element list using the ‘*’ wildcard
which means $username can generate tokens for members of any group. Defaults to
an empty list that is equivalent to {{$username}} is not allowed to impersonate
members from any group.
* {{{}knox{}}}{{{}.token{}}}{{{}.proxyuser.$username.hosts{}}} - indicates a
list of hostnames from where the requests are allowed to be accepted in case
the doAs parameter is used when creating Knox Tokens. It is possible to set
this to a 1-element list using the ‘*’ wildcard which means $username can
generate tokens from any host. Defaults to an empty list that is equivalent to
{{$username}} is not allowed to create tokens from any host.
Please note this configuration is applied only if the newly introduced doAs
query parameter is present. Applying these whitelists should be in OR relation:
if any of the declared conditions is evaluated to {_}true{_}, the token can be
created using the doAs parameter for the target user.
Let’s see some samples using the above curl command and assume that _‘bob’_ is
a member of the _‘accountants’_ group.
|*knox.token.proxyuser.admin.users*|*knox.token.proxyuser.admin.groups*|*Result*|
|Not Set|Not Set|403|
|tom, jerry|Not Set|403|
|bob, tom, jerry|Not Set|200|
|bob, tom, jerry|managers|200|
|tom, jerry|managers|403|
|Not Set|managers|403|
|Not Set|managers, accountants|200|
|tom, jerry|managers, accountants|200|
was:
As of now, authenticated users are allowed to acquire a Knox token for
themselves only. That is, the username the token is created for is fetched from
the request’s user principal. The goal is to be able to generate a Knox token
on behalf of somebody else.
To be able to do this, we need to enhance the current KnoxToken service API to
support a new query parameter called doAs. For instance:
{noformat}
curl -iku admin:admin-password -X GET
'https://localhost:8443/gateway/sandbox/knoxtoken/api/v1/token?doAs=bob’
{noformat}
In this case, the generated token will not belong to the _‘admin’_ user, but
it’s going to be created for {_}‘bob’{_}.
The newly introduced ‘doAs’ is an optional parameter: if not defined, the
generated token will belong to the authenticated user (in the above sample:
{_}‘admin’{_}).
Of course, we need to provide a way to control who can generate tokens for who,
so the following service-level configuration should be added too (they will be
defined in the given topology for the KNOXTOKEN service):
* {{knox.proxyuser.$username.users}} - indicates the list of users for whom
{{$username}} is allowed to create tokens. It is possible to set this to a
1-element list using the ‘*’ wildcard which means $username can generate tokens
for everyone. Defaults to an empty list that is equivalent to {{$username}} is
not allowed to impersonate anyone.
* {{knox.proxyuser.$username.groups}} - indicates the list of group names for
whose members $username is allowed to create tokens for. It is possible to set
this to a 1-element list using the ‘*’ wildcard which means $username can
generate tokens for members of any group. Defaults to an empty list that is
equivalent to {{$username}} is not allowed to impersonate members from any
group.
* {{knox.proxyuser.$username.hosts}} - indicates a list of hostnames from
where the requests are allowed to be accepted in case the doAs parameter is
used when creating Knox Tokens. It is possible to set this to a 1-element list
using the ‘*’ wildcard which means $username can generate tokens from any host.
Defaults to an empty list that is equivalent to {{$username}} is not allowed to
create tokens from any host.
Please note this configuration is applied only if the newly introduced doAs
query parameter is present. Applying these whitelists should be in OR relation:
if any of the declared conditions is evaluated to {_}true{_}, the token can be
created using the doAs parameter for the target user.
Let’s see some samples using the above curl command and assume that _‘bob’_ is
a member of the _‘accountants’_ group.
|*knox.proxyuser.admin.users*|*knox.proxyuser.admin.groups*|*Result*|
|Not Set|Not Set|403|
|tom, jerry|Not Set|403|
|bob, tom, jerry|Not Set|200|
|bob, tom, jerry|managers|200|
|tom, jerry|managers|403|
|Not Set|managers|403|
|Not Set|managers, accountants|200|
|tom, jerry|managers, accountants|200|
> Adding doAs support for KnoxToken service
> -----------------------------------------
>
> Key: KNOX-2714
> URL: https://issues.apache.org/jira/browse/KNOX-2714
> Project: Apache Knox
> Issue Type: Improvement
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Critical
>
> As of now, authenticated users are allowed to acquire a Knox token for
> themselves only. That is, the username the token is created for is fetched
> from the request’s user principal. The goal is to be able to generate a Knox
> token on behalf of somebody else.
> To be able to do this, we need to enhance the current KnoxToken service API
> to support a new query parameter called doAs. For instance:
> {noformat}
> curl -iku admin:admin-password -X GET
> 'https://localhost:8443/gateway/sandbox/knoxtoken/api/v1/token?doAs=bob’
> {noformat}
> In this case, the generated token will not belong to the _‘admin’_ user, but
> it’s going to be created for {_}‘bob’{_}.
> The newly introduced ‘doAs’ is an optional parameter: if not defined, the
> generated token will belong to the authenticated user (in the above sample:
> {_}‘admin’{_}).
> Of course, we need to provide a way to control who can generate tokens for
> who, so the following service-level configuration should be added too (they
> will be defined in the given topology for the KNOXTOKEN service):
> * {{knox.token.proxyuser.$username.users}} - indicates the list of users for
> whom {{$username}} is allowed to create tokens. It is possible to set this to
> a 1-element list using the ‘*’ wildcard which means $username can generate
> tokens for everyone. Defaults to an empty list that is equivalent to
> {{$username}} is not allowed to impersonate anyone.
> * {{{}knox{}}}{{{}.token{}}}{{{}.proxyuser.$username.groups{}}} - indicates
> the list of group names for whose members $username is allowed to create
> tokens for. It is possible to set this to a 1-element list using the ‘*’
> wildcard which means $username can generate tokens for members of any group.
> Defaults to an empty list that is equivalent to {{$username}} is not allowed
> to impersonate members from any group.
> * {{{}knox{}}}{{{}.token{}}}{{{}.proxyuser.$username.hosts{}}} - indicates a
> list of hostnames from where the requests are allowed to be accepted in case
> the doAs parameter is used when creating Knox Tokens. It is possible to set
> this to a 1-element list using the ‘*’ wildcard which means $username can
> generate tokens from any host. Defaults to an empty list that is equivalent
> to {{$username}} is not allowed to create tokens from any host.
> Please note this configuration is applied only if the newly introduced doAs
> query parameter is present. Applying these whitelists should be in OR
> relation: if any of the declared conditions is evaluated to {_}true{_}, the
> token can be created using the doAs parameter for the target user.
> Let’s see some samples using the above curl command and assume that _‘bob’_
> is a member of the _‘accountants’_ group.
> |*knox.token.proxyuser.admin.users*|*knox.token.proxyuser.admin.groups*|*Result*|
> |Not Set|Not Set|403|
> |tom, jerry|Not Set|403|
> |bob, tom, jerry|Not Set|200|
> |bob, tom, jerry|managers|200|
> |tom, jerry|managers|403|
> |Not Set|managers|403|
> |Not Set|managers, accountants|200|
> |tom, jerry|managers, accountants|200|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
