lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <j...@apache.org>
Subject [jira] [Updated] (SOLR-12799) Allow Authentication Plugins to easily intercept internode requests
Date Mon, 24 Sep 2018 10:07:00 GMT

     [ 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


Mime
View raw message