[
https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925634#comment-17925634
]
Gus Heck edited comment on SOLR-17659 at 2/10/25 4:52 PM:
----------------------------------------------------------
{quote}not a service that is run on the server where Solr is running.
{quote}
This has never been a confusion on my part, however I guess it's good to have
this clarified for others who read this later.
{quote}I believe it would be way easier to analyze the endpoints from our
source code, rather than reverse-engineer the WebAssembly app
{quote}
This is exactly why version information is important. One would have to analyze
the correct version from VCS. Also I am presuming that if it is not now
possible, it will soon be possible to feed a WebAssembly app to a Chat based AI
like ChatGPT, or possibly a custom trained DeepSeek (Model License terms only
stop the good guys) etc... and ask it to list the URL's the application is
likely to access. (some trickiness possibly to word the prompt so that it knows
what to do with variable URLs like /solr/<collectionName>/select of course).
WebAssembly (or obfuscated javascript) is hard for humans to read, but a
machine doesn't care, and if one can get an LLM to do that, all questions of
versioning go away. Also, consider the answer to this [SO
post|https://stackoverflow.com/questions/61904135/decoding-wasm-webassembly-files].
{quote}That sounds very much like the concepts from OAuth. And from how I
understand your message, what you probably are looking for is "migrating" Solr
into a [resource
server|https://www.oauth.com/oauth2-servers/the-resource-server/], and allow an
external app like Keycloak manage users, access etc.
{quote}
Resource server is just a description of how you treat the server (aside from
expecting a few HTTP responses and codes in failure cases, I suppose). But I DO
hope for solr to be friendly to such usage, including not showing an additional
login page once you pass the external verification etc. In the current design
the UI will need complex "do we already have some other sort of auth?" logic to
ensure that the form isn't shown. This will need to be updated for every new
Auth mechanism (or new version of auth mechanism) that breaks the heuristic we
were using to detect it. I'm pretty sure such checks can be more easily handled
and maintained if they are not part of the UI by folks who don't have to
understand how to build or update the UI. Also there's less chance that a UI
focused contributor not fully appreciating security concerns accidentally
breaks it. Basically I'd like to have zero authentication/authorization
decision making in the UI, and if we have a login form, we definitely have to
make those decisions about when to display the form.
Also, for the folks who have made a carefully considered decision to rely on
"network security" (because that's the only way they can make a profit or they
are already inside an air gap facility containing legacy systems far more
important than Solr) there's the question of how to disable the form.... If the
login is not in the UI, and authentication is turned off, direct requests to
the UI "just work" as expected.
was (Author: gus_heck):
{quote}not a service that is run on the server where Solr is running.
{quote}
This has never been a confusion on my part, however I guess it's good to have
this clarified for others who read this later.
{quote}I believe it would be way easier to analyze the endpoints from our
source code, rather than reverse-engineer the WebAssembly app
{quote}
This is exactly why version information is important. One would have to analyze
the correct version from VCS. Also I am presuming that if it is not now
possible, it will soon be possible to feed a WebAssembly app to a Chat based AI
like ChatGPT, or possibly a custom trained DeepSeek (Model License terms only
stop the good guys) etc... and ask it to list the URL's the application is
likely to access. (some trickiness possibly to word the prompt so that it knows
what to do with variable URLs like /solr/<collectionName>/select of course).
WebAssembly (or obfuscated javascript) is hard for humans to read, but a
machine doesn't care, and if one can get an LLM to do that, all questions of
versioning go away. Also, consider the answer to this [SO
post|https://stackoverflow.com/questions/61904135/decoding-wasm-webassembly-files].
{quote}That sounds very much like the concepts from OAuth. And from how I
understand your message, what you probably are looking for is "migrating" Solr
into a [resource
server|https://www.oauth.com/oauth2-servers/the-resource-server/], and allow an
external app like Keycloak manage users, access etc.
{quote}
Resource server is just a description of how you treat the server (aside from
expecting a few HTTP responses and codes in failure cases, I suppose). But I DO
hope for solr to be friendly to such usage, including not showing an additional
login page once you pass the external verification etc. In the current design
the UI will need complex "do we already have some other sort of auth?" logic to
ensure that the form isn't shown. This will need to be updated for every new
Auth mechanism (or new version of auth mechanism) that breaks the heuristic we
were using to detect it. I'm pretty sure such checks can be more easily handled
and maintained if they are not part of the UI by folks who don't have to
understand how to build or update the UI. Also there's less chance that a UI
focused contributor not fully appreciating security concerns accidentally
breaks it. Basically I'd like to have zero authorization decision making in the
UI, and if we have a login form, we definitely have to make those decisions
about when to display the form.
Also, for the folks who have made a carefully considered decision to rely on
"network security" (because that's the only way they can make a profit or they
are already inside an air gap facility containing legacy systems far more
important than Solr) there's the question of how to disable the form.... If the
login is not in the UI, and authentication is turned off, direct requests to
the UI "just work" as expected.
> Implement basic authentication in Admin UI
> ------------------------------------------
>
> Key: SOLR-17659
> URL: https://issues.apache.org/jira/browse/SOLR-17659
> Project: Solr
> Issue Type: New Feature
> Components: Admin UI
> Reporter: Christos Malliaridis
> Priority: Major
> Labels: new-ui, ui
>
> In the new UI one of the key features that is not implemented yet is user
> authentication. In order to secure and securily access Solr, the user should
> be able to authenticate against a Solr instance with basic credentials.
> h2. Task
> Implement basic user authentication (with credentials) according to the [new
> designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1190-388&t=vMgOa9QlzQZSdjLf-1].
> h2. Acceptance Criteria
> - The user can access a Solr instance that has user authentication enabled
> - The user can at least authenticate with credentials (basic auth)
> - The credentials form is displayed after the user has established a
> connection with a Solr instance, that is, after a Solr instance was found
> - The user can return to the start screen where the Solr URL was provided,
> if he decides to abort the authentication step
> - The user is no longer redirected to the dashboard or any other screen if
> user authentication is required
> - The credentials are used for any subsequent request
> h2. Additional Information
> The support for additional authentication options does not have to be
> addressed in this issue. If it proves to be straight-forward, feel free to
> implement additional auth options as well. Note that additional
> authentication options will be added later, and therefore, the implementation
> should be expandable.
> The credentials do not have to survive an application restart (desktop).
> Storing credentials securely will be addressed in a separate issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
