You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Noble Paul (JIRA)" <ji...@apache.org> on 2018/10/11 01:26:00 UTC

[jira] [Comment Edited] (SOLR-12799) Allow Authentication Plugins to easily intercept internode requests

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

Noble Paul edited comment on SOLR-12799 at 10/11/18 1:25 AM:
-------------------------------------------------------------

I find it strange that we have to explicitly pass the Principal along in {{SolrCmdDistributor}} and {{HttpShardHandler#submit()}} . These are supposed to be copied automatically for any ThreadPool using {{MDCAwareThreadPoolExecutor}}. I haven't done a full review, but this kind of stands out 


was (Author: noble.paul):
I'm doing it now

> Allow Authentication Plugins to easily intercept internode requests
> -------------------------------------------------------------------
>
>                 Key: SOLR-12799
>                 URL: https://issues.apache.org/jira/browse/SOLR-12799
>             Project: Solr
>          Issue Type: New Feature
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Authentication
>            Reporter: Jan Høydahl
>            Assignee: Jan Høydahl
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Solr security framework currently allows a plugin to declare statically by implementing the {{HttpClientBuilderPlugin}} interface whether it will handle internode requests. If it implements the interface, the plugin MUST handle ALL internode requests, even requests originating from Solr itself. Likewise, if a plugin does not implement the interface, ALL requests will be authenticated by the built-in {{PKIAuthenticationPlugin}}.
> In some cases (such as SOLR-12121) there is a need to forward end-user credentials on internode requests, but let PKI handle it for solr-originated requests. This is currently not possible without a dirty hack where each plugin duplicates some PKI logic and calls PKI plugin from its own interceptor even if it is disabled.
> This Jira makes this use case officially supported by the framework by:
>  * Letting {{PKIAuthenticationPlugin}} be always enabled. PKI will now in its interceptor on a per-request basis first give the authc plugin a chance to handle the request
>  * Adding a protected method to abstract class {{AuthenticationPlugin}}
>    {code:java}
> protected boolean interceptInternodeRequest(HttpRequest httpRequest, HttpContext httpContext)
> {code}
> that can be overridden by plugins in order to easily intercept requests without registering its own interceptor. Returning 'false' delegates to PKI.
> Existing Authc plugins do *not* need to change as a result of this, and they will work exactly as before, i.e. either handle ALL or NONE internode auth.
> New plugins choosing to *override* the new {{interceptInternodeRequest}} method will obtain per-request control over who will secure each request. The first user of this feature will be JWT token based auth in SOLR-12121.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org