You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Jan Høydahl (JIRA)" <ji...@apache.org> on 2018/09/24 10:07:00 UTC
[jira] [Updated] (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:all-tabpanel ]
Jan Høydahl updated SOLR-12799:
-------------------------------
Description:
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.
was:
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 and always register its interceptor. PKI will now on a per-request 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.
> 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