[
https://issues.apache.org/jira/browse/KNOX-3096?focusedWorklogId=958591&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-958591
]
ASF GitHub Bot logged work on KNOX-3096:
----------------------------------------
Author: ASF GitHub Bot
Created on: 24/Feb/25 23:51
Start Date: 24/Feb/25 23:51
Worklog Time Spent: 10m
Work Description: lmccay opened a new pull request, #994:
URL: https://github.com/apache/knox/pull/994
There are various possibilities for leveraging the authentication
capabilities across Knox instances. One compelling reason is for containerized
Knox instances within k8s that would like to accept CLIENT_ID and CLIENT_SECRET
or Passcode tokens but do not have a local database provisioned. These Knox
instances can accept the tokens by delegating the authentication to a remote
instance configured with the appropriate database or other details that may not
be available to all other instances. It will need to cache authentication
results for a short but meaningful enough time to reduce the chance of
authentication storms against the remote server. At the same time,
authentication can't outlive a change in the user's status any dangerous amount
of time. Perhaps default to 5 mins.
It should allow for the configuration of all relevant possible items such as:
1. remote authentication server url (likely to the KNOX-AUTH-SERVICE API)
2. leverage the gateway truststore configuration
4. headers to include in the call to the remote server from the request
being processed
5. expected headers from the response to include the user and groups
6. interval in mins for cache of authentication result to reduce
authentication storms to remote server
## How was this patch tested?
Added new unit tests and ran all existing tests.
Manually tested by configuring the RemoteAuthProvider to make calls from one
topology to another in the same instance.
Sample topology:
<?xml version="1.0" encoding="UTF-8"?>
<topology>
<uri>https://localhost:8444/gateway/tokengen</uri>
<name>tokengen</name>
<timestamp>1739846560256</timestamp>
<generated>false</generated>
<redeployTime>0</redeployTime>
<gateway>
<provider>
<role>authentication</role>
<name>RemoteAuthProvider</name>
<enabled>true</enabled>
<param>
<name>remote.auth.url</name>
<value>https://localhost:8444/gateway/sandbox/auth/api/v1/pre</value>
</param>
<param>
<name>remote.auth.include.headers</name>
<value>Authorization</value>
</param>
<param>
<name>remote.auth.expire.after</name>
<value>5</value>
</param>
<param>
<name>remote.auth.user.header</name>
<value>X-Knox-Actor-ID</value>
</param>
<param>
<name>remote.auth.group.header</name>
<value>X-Knox-Actor-Groups-1</value>
</param>
</provider>
<provider>
<role>identity-assertion</role>
<name>Default</name>
<enabled>true</enabled>
</provider>
<provider>
<role>hostmap</role>
<name>static</name>
<enabled>true</enabled>
<param>
<name>localhost</name>
<value>sandbox,sandbox.hortonworks.com</value>
</param>
</provider>
</gateway>
<service>
<role>KNOXTOKEN</role>
</service>
</topology>
The param 'remote.auth.url' specifies the knox auth service that returns the
preauth headers for successful authentication events.
The param 'remote.auth.include.headers' indicates that the Authorization
header should be sent to the remote auth service for it to be able to get the
credentials and validate them.
The 'remote.auth.expire.after' param indicates the number of mins to cache
the authentication results for the given header value - typically the same as
the header included for credential access. In this case, the authorization
header.
The 'remote.auth.user.header' and 'remote.auth.group.header' indicates the
header expected header names that remote auth service will populate upon
successful authentication for both username and the group memberships.
Using curl to access this endpoint for acquiring an access token results in
something like:
bash-3.2$ curl -iku guest:guest-password
https://localhost:8444/gateway/tokengen/knoxtoken/api/v1/token
HTTP/1.1 200 OK
Date: Mon, 24 Feb 2025 06:15:47 GMT
Content-Type: application/json
Content-Length: 2175
{"access_token":"eyJqa3UiOiJodHRwczovL2xvY2FsaG9zdDo4NDQ0L2dhdGV3YXkvdG9rZW5nZW4va25veHRva2VuL2FwaS92MS9qd2tzLmpzb24iLCJraWQiOiJCR3JiSUQxa3RFRjMyV1N2N0Q3dGUxRGs2UTFFQUhEQ0RLMVJscUM5SVAwIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJndWVzdCIsI....wMzc3Nzc4LCJtYW5hZ2VkLnRva2VuIjoiZmFsc2UiLCJrbm94LmlkIjoiZmU2NTU3N2QtYzk2ZC00YmZmLWE5MjYtYjYwMjFkZDVhZWU3In0.OxqRrjryNXcaCzIqSCmH6hWpGxxZSH1GvJJ9e0zN3N41iMyDLB5LkUll6eLwDCRGrorI5HbtxKzhfQDPK3WVDXO2s78n4xrRWjuHFmu1dF8QrLHtdFQnX4bTGPrhXgtr309oiHSEzMza_Qw8V0L_7ybtwMvgXbKNQf1rGsCJ-y76le5SRIoFNDQeOJZPo9D153k-j6wC2vaOY8zaLh4qsDOh5IAuC9xujev0KFJNzVNwFN-vv2ClSQNxW4BoA0PuUBvPaGRxvG2ugV9s6ftqSC8wk-9VjKGAaSJ6cp2Ygsi_j4V_SAd6lSQINQUM6ZMfNLzJHkT-7yewC8pJK1q3vQ","token_id":"fe65577d-c96d-4bff-a926-b6021dd5aee7","managed":"false","endpoint_public_cert":"MIIDWT...YMBYwFAYDVR0RBA0wC4IJbG9jYWxob3N0MA0GCSqGSIb3DQEBBQUAA4IBAQCBTc5905y6HxrOtWBN44B1riZeFBNl+somt5blglzLRY8Oqj9L35/TPz6IeHsa+7uASOf2ELPgdJCnAX91O+mEtr9zxdri9qtBm8/FzoadUIFoyTkjrl6bxDd1qd48lsFAXUaZ1v6h669qB8atexb95QLXDc3LCC1FWTZssNVtbxOCZU6wMQBfiUinFwFPRVzQJg6lc/+iy+Kv0nr0b9M2RXZ3C+FukiyZXnV2ffEsvND9/2R0AnMTIQ9+brH8p73b39WA6mZNMzY2E6YiaFCEdXUc4lqJHw/eXCVdTc6W3Ex1oqtRS1e5/v5PCCD3GUupUNVBGb9mHBm6w0PweYCP","token_type":"Bearer","expires_in":1740377778029}
Please review [Knox Contributing
Process](https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-GithubWorkflow)
before opening a pull request.
Issue Time Tracking
-------------------
Worklog Id: (was: 958591)
Remaining Estimate: 0h
Time Spent: 10m
> Remote Authentication Provider for Levaraging other Knox Instances
> ------------------------------------------------------------------
>
> Key: KNOX-3096
> URL: https://issues.apache.org/jira/browse/KNOX-3096
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Reporter: Larry McCay
> Assignee: Larry McCay
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are various possibilities for leveraging the authentication
> capabilities across Knox instances. One compelling reason is for
> containerized Knox instances within k8s that would like to accept CLIENT_ID
> and CLIENT_SECRET or Passcode tokens but do not have a local database
> provisioned. These Knox instances can accept the tokens by delegating the
> authentication to a remote instance configured with the appropriate database
> or other details that may not be available to all other instances. It will
> need to cache authentication results for a short but meaningful enough time
> to reduce the chance of authentication storms against the remote server. At
> the same time, authentication can't outlive a change in the user's status any
> dangerous amount of time. Perhaps default to 5 mins.
> It should allow for the configuration of all relevant possible items such as:
> 1. remote authentication server url (likely to the KNOX-AUTH-SERVICE API)
> 2. truststore location
> 3. truststore password/alias
> 4. headers to include in the call to the remote server from the request being
> processed
> 5. expected headers from the response to include the user and groups
> 6. interval in mins for cache of authentication result to reduce
> authentication storms to remote server
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
