[
https://issues.apache.org/jira/browse/SOLR-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430220#comment-17430220
]
Timothy Potter commented on SOLR-12666:
---------------------------------------
I'm definitely open to an overhaul / migration to a mature framework like pac4j
or Apache Shiro but I am also curious if we can't solve the multiple
authentication plugin problem with a new plugin impl that takes config for
multiple schemes, something like:
{code}
"authentication": {
"class": "solr.MultiAuthPlugin",
"bearer": { CONFIGURE Plugin to handle Bearer token HERE, e.g.
JWTAuthPlugin },
"basic": { CONFIGURE BasciAuthPlugin HERE }
}
{code}
As far as I can tell, the Auth Plugin framework accepts arbitrary JSON and
passes around {{Map<String,Object>}} to the plugins. Under the covers, the
{{MultiAuthPlugin}} initializes the {{JWTAuthPlugin}} and {{BasicAuthPlugin}}
for example. Supporting {{Bearer}} and {{Basic}} authorization headers gets us
a pretty long way for little effort with the current framework.
The complexity with this approach would be user / role mapping, so we'd need a
custom {{RuleBasedAuthorizationPlugin}} impl that supports direct mapping for
users that auth using {{Basic}} as well as delegating to the
{{ExternalRoleRuleBasedAuthorizationPlugin}} for JWT. This is actually OK
because under this approach, there's likely to only be a few (probably just
one) users configured for Basic auth to allow for bin/solr access and other
service account type clients like Kubernetes or the Prometheus exporter.
The problem with the overhaul approach is it's going to take a fair amount of
time to select the best framework, integrate it, test it, and so on ... We
should definitely start on this. Meanwhile, the approach I'm proposing here
fills a much needed gap, esp. for running in K8s where we need to secure probe
endpoints and the prometheus exporter using basic auth. When the overhaul
framework is ready, then users will likely still want a mixed approach for all
the reasons Jan describes above.
> Support multiple AuthenticationPlugin's simultaneoulsy
> ------------------------------------------------------
>
> Key: SOLR-12666
> URL: https://issues.apache.org/jira/browse/SOLR-12666
> Project: Solr
> Issue Type: New Feature
> Components: Authentication, security
> Reporter: Jan Høydahl
> Priority: Major
> Labels: authentication
> Attachments: ShiroAuthenticationSequence.png
>
>
> 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 JIRAs to add *BasicAuth* support for
> various clients and use cases, 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), SOLR-12860 (metrics history), SOLR-11759
> (DocExpirationUpdateProcessor), SOLR-11959 (CDCR), SOLR-12359 (LIR) and
> probably more. Some of these may be bugs that can be fixed with PKI though...
> 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).- Admin UI
> has explicit support for a few plugins only.
> 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 e.g.
> BasicAuth or JWTAuth for use with other clients that do not support the
> primary auth method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
