[
https://issues.apache.org/jira/browse/KNOX-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandor Molnar updated KNOX-3096:
--------------------------------
Fix Version/s: 2.1.0
> 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
> Fix For: 2.1.0
>
> 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)
