[
https://issues.apache.org/jira/browse/SOLR-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18023278#comment-18023278
]
Eric Pugh commented on SOLR-17930:
----------------------------------
This seems like a reasonable fix for our situation. On a more "meta" level,
why are we having this problem? The concept of an "xBasic" is something you
came up with for our specific situation correct?
If we were to start fresh, what would we do to better support this? It *feels*
a little bit like something more fundamental is at play that you have to do
this "hack" to get things to work.
My comment is more meant to inform the future, not to slow things down today!
Let's get auth fixed with our new UI today!
> Improve MultiAuthPlugin compatibility with BasicAuthPlugin
> ----------------------------------------------------------
>
> Key: SOLR-17930
> URL: https://issues.apache.org/jira/browse/SOLR-17930
> Project: Solr
> Issue Type: Improvement
> Components: Authentication
> Reporter: Christos Malliaridis
> Priority: Major
> Labels: authentication, new-ui, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Our current implementation of the MultiAuthPlugin is limited when used in
> combination with BasicAuthPlugin. The following scenarios describe the
> limitations:
> Consider this security.json:
> {code:json}
> {
> "authentication": {
> "class": "solr.MultiAuthPlugin",
> "schemes": [
> {
> "scheme": "Basic",
> "realm": "solr",
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
> },
> "forwardCredentials": false
> },
> {
> "scheme": "Bearer",
> "realm": "oauth",
> "class": "solr.JWTAuthPlugin",
> "blockUnknown": true,
> "wellKnownUrl":
> "http://localhost:3000/realms/master/.well-known/openid-configuration";,
> "clientId": "solr-jwt",
> "scope": "solr:admin",
> "redirectUris": "http://127.0.0.1:8983/solr/";,
> "authorizationFlow": "code_pkce"
> }
> ]
> }
> }
> {code}
> When MultiAuthPlugin is configured with BasicAuthPlugin and scheme "Basic",
> - browser clients that send ajax-requests (like old UI) will retrieve only
> the first plugin from schemes in MultiAuthPlugin, and if it is
> BasicAuthPlugin, the scheme is mapped to "xBasic"
> - browser clients that do not send ajax-requests (like new UI) will display a
> browser prompt (unwanted) but retrieve the entire list of auth headers
> The problem with this security.json is that there is no combination possible
> that provides the entire auth schemes in the "WWW-Authenticate" response
> headers, without a browser prompt showing up (which is a usability problem in
> the new UI).
The fix would likely be to use “scheme”: “xBasic” instead of
> “scheme”: “Basic” for BasicAuthPlugin. However, this is not working right
> now, because
- If clients send an authorized request with “Authenticate”:
> “Basic ...” the MultiAuthPlugin would not be able to find the plugin for the
> scheme, and
> - If clients send an authroized request with “Authenticated”: “xBasic ...”
> BasicAuthPlugin would fail because it expected “Basic ...”
> The current workaround for users is to write custom auth plugins, which is
> cumbersome and requires maintenance.
> h2. Proposal
> By allowing the MultiAuthPlugin looking up additionally for "xBasic" scheme
> if no "Basic" scheme is found, users would be able to use in clients "Basic"
> scheme even without an ajax-request, and configure the "xbasic" scheme in the
> MultiAuthPlugin with the BasicAuthPlugin as class. This would keep things
> secure with positive impact in the user experience in browser applications.
> h2. Benefits
> - Low impact of breaking changes
> - webapp (and existing clients) continue to work like before
> - MultiAuthPlugin is extended and supports “xBasic” as scheme for
> BasicAuthPlugin
> - Users can use “Basic” scheme for authorized requests by treating “xBasic”
> scheme like “Basic”
> - BasicAuthPlugin does not require any changes
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
