[ 
https://issues.apache.org/jira/browse/KNOX-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17930458#comment-17930458
 ] 

ASF subversion and git services commented on KNOX-3096:
-------------------------------------------------------

Commit a85cdcbe1c69cf7e84a4820c5cb44cfeb57d1d98 in knox's branch 
refs/heads/master from Larry McCay
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=a85cdcbe1 ]

KNOX-3096 - Remote Authentication Provider for Levaraging other Knox Instances 
(#994)

* KNOX-3096 - Remote Auth Provider initial commit

> 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. 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)

Reply via email to