[
https://issues.apache.org/jira/browse/KNOX-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry McCay updated KNOX-3096:
------------------------------
Description:
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 gateway trust config
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
was:
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
> 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: 1h
> 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. leverage gateway trust config
> 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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
