[
https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925405#comment-17925405
]
Christos Malliaridis commented on SOLR-17659:
---------------------------------------------
I think I understand what you are referring to Gus. I believe this is clear
already, but allow me to repeat it once more to avoid any possible
misunderstanding: the new UI is just a binary file at the end of the day, not a
service that is run on the server where Solr is running. When the users access
the HTTP endpoint, they automatically download the file and run it in their
browser. Of course, this file is versioned and may leak the information of what
Solr version may be running because it is shipped with Solr (if the files are
not explicitly updated). It will obviously be >=v10.0, because the new UI does
not exist in versions prior to that. We would have the same "leak" anyway
regardless of the changes we introduce, even if we would introduce an auth
facade infront of the UI. So we would not improve the seuciry here.
The best way to protect Solr instances in such scenarios would be to disable
the UI completely and only allow clients like the standalone desktop app or
SolrJ to be used.
{quote}[...] use it to look for ways we have accidentally exposed information
or features that are not properly protected.
{quote}
I believe it would be way easier to analyze the endpoints from our source code,
rather than reverse-engineer the WebAssembly app that is a binary file to look
for unprotected information or features. The new UI does not know anything
about a Solr instance that is already leaked via the API. And I believe this is
a key difference compared to our current UI (I am not sure how the current UI
works though).
One could even host the new UI on a separate server and connect with any Solr
instance, like the desktop client of the new UI can do. So if we leak any kind
of information via our API already, and the new UI just uses that information,
then it should be addressed directly in the API level. One would not get more
information from what is already there.
{quote}[...] but we should do so in a structure suitable for all [use
cases|https://solr.apache.org/guide/solr/latest/deployment-guide/authentication-and-authorization-plugins.html#enabling-an-authentication-plugin].
{quote}
Yes, that is very important, and anyone implementing the auth should take into
account that credentials-based auth is not the only authentication option
possible. However, without implementing each use case, any structure that is
defined may not be properly evaluated until we implement all cases. There will
definitely be some kind of refactoring if the interfaces defined in the first
implementation do not work with all auth options available. But that is
acceptable and would be addressed once we reach that point of development.
{quote}An independent app that establishes auth and then redirects to the /ui
context
{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. That would
move the responsibility of the auth stuff to a "separate app", improve the
security and reduce the complexity of Solr in general, and allow apps like the
new UI use a wide range of auth options by simply "redirecting" to the
Keycloack auth website. This would also handle all these redirects you
mentioned to the individual UIs. If that is what would address your
expectations, it would not be part of the new UI, but rather the entire Solr
project. And the new UI would not even be affected by that directly.
I hope I did not misunderstand any of your words.
> 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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
