KNOX-3096 - Remote Authentication Provider for Levaraging other Knox Instances

[lmccay]

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
3. headers to include in the call to the remote server from the request being processed
4. expected headers from the response to include the user and groups
5. 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 before opening a pull request.

[lmccay]

I will follow up with another change to chain the correlation id's across the local and remote knox instances. I want to get this in and make progress on it first.

[moresandeep]

Looks good!