[
https://issues.apache.org/jira/browse/SOLR-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16581194#comment-16581194
]
Jan Høydahl commented on SOLR-12666:
------------------------------------
In order to support this, the framework would need to allow a list of auth
plugins and hand over the request to each one in turn until either one of them
says OK or all of them say NOT OK.
The {{AuthenticationPlugin}} API is very low level now, allowing each plugin to
interact with the filterChain, set headers on the response and even terminate
the request by returning an error 401 as response. We'd have to completely
rewrite the API in order to support a chained call to each plugin.
Another alternative is to add a new optional method to base class
AuthenticationPlugin, e.g.:
{code:java}
AuthResponse prepareAuthenticate(req){code}
...which would be called for all configured plugins only if multiple are
configured. The method would always return a status, and then the framework
could use the response to decide to which plugin it should send the final
{{doAuthenticate()}} call. This would give back-compat with old configurations
and plugins, but plugins who wish to be able to support chained operation can
implement this one method.
The AuthResponse object could carry information about whether credentials are
detected or not, whether the request would succeed or not, a list of HTTP
headers that the plugin would return to user etc. If no plugins find any
credentials on the request and blockUnknown==false, then continue the request.
If none of the plugins find credentials and blockUnknown==true, then return 401
with all headers each plugin wants to return (this may include multiple
WWW-Authenticate headers). If one of the plugins find credentials (e.g.
Authorization Basic header) then call doAuthenticate() on that plugin. If more
than one plugin find credentials, and all of them say that the request would
succeed then pick the first to call doAuthenticate. However, if one of them
says up front that credentials are found but the request would no succeed, then
call doAuthenticate() on that one?
I'm not sure whether there's a valid case for multiple plugins detecting
credentials. One I could think of is an IP auth plugin, it would always find an
IP address on the request, and it would be fully legal for that to not match
the configured list if another plugin finds a valid BasicAuth header.
> Support multiple AuthenticationPlugin's simultaneoulsy
> ------------------------------------------------------
>
> Key: SOLR-12666
> URL: https://issues.apache.org/jira/browse/SOLR-12666
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, security
> Reporter: Jan Høydahl
> Priority: Major
> Labels: authentication
>
> Solr is getting support for more authentication plugins year by year, and
> customers have developed their own in-house plugins as well.
> At the same time we see more and more requests to add *BasicAuth* support to
> various Solr clients such as SOLR-12584 (Solr Exporter), SOLR-9779 (Streaming
> expressions), SOLR-11356 (ConcurrentUpdateSolrClient), SOLR-8213 (JDBC),
> SOLR-12583 (Subquery docTransformer) and SOLR-10322 (Streaming expression
> daemon).
> Currently the framework supports *only one active Auth method* (except PKI
> which is special). Which means that if you use something else than BasicAuth,
> you're lucky if you get any of the above features to work with your cluster.
> Even the AdminUI only supports BasicAuth (implicit via browser).
> I think the solution is to allow more than one auth plugin to be active at
> the same time, allowing people to use their custom fancy auth which is
> tightly integrated with their environment, and at the same time activate
> BasicAuth for use with other clients that do not support the primary auth
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
