[
https://issues.apache.org/jira/browse/SOLR-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431099#comment-17431099
]
Jan Høydahl commented on SOLR-12666:
------------------------------------
> Under the covers, the {{MultiAuthPlugin}} initializes the {{JWTAuthPlugin}}
>and {{BasicAuthPlugin}} for example.
This could perhaps work, as it would simply choose which Auth plugin to invoke
based on the scheme detected in the Authorization header. At least you'd manage
to support both JWT and Basic at the same time.
Yea, the authz is a mess. Nobody understands it, and it's 100% custom to Solr.
I think a mature framework would be a huge win here. But as a bridge-gap
solution I guess your MultiAuthRuleBasedAuthorizationPlugin could also work,
simply delegating the authz invocation to the correct class.
The Admin UI would be confused, as it expects exactly one plugin, and the
support to edit security.json would then fall apart. Also, for a request that
lacks Authorization header, like an unauthenticated Admin UI, Solr responds
with a few headers which are scheme dependent, e.g. for JWT:
{code:java}
WWW-Authenticate: Bearer realm=myrealm
X-Solr-AuthData: <base64-encoded json data>
# Example: {"authorizationEndpoint":"https:my-idp:8888/authorize",
"client_id":"myJwtClientId", "scope":"search",
"redirect_uris":["http://solr:8083/solr/"]}{code}
For BasicAuth:
{code:java}
WWW-Authenticate: xBasic realm=myrealm{code}
Problem is that these headers are generated inside the plugin being invoked, so
we have no way of telling the AdminUI about both by sending multiple
WWW-Authenticate headers. But that would be solved by just picking the
'default-scheme' plugin if Authorization header is missing on the request.
I think it is worth a try, should be doable quite quickly without framework
changes, and the MultiAuth* classes can implement custom logic to decide corner
cases etc.
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
