[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926184#comment-17926184 ] David Smiley commented on SOLR-17659: - I completely agree with Jan. This issue is about the front-end, not the backend. As such, if the front-end somehow gets info from the back-end, it's fair-game to display it. > 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
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926179#comment-17926179 ] Jan Høydahl commented on SOLR-17659: There are probably dozens of ways to find out it’s solr. But this is all backend and not related to new ui. If you want to work on solr stealth, that belong in some new jira. > 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
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926161#comment-17926161 ] Gus Heck commented on SOLR-17659: - Ah but one thing perhaps I haven't made clear. I would like it to be hard for an attacker to identify that it IS solr at all... If it's not on port 8983, it's just something asking for login. (Probably we want a user configurable system name so people can have conficence they are talking to the right thing, but if that name doesn't include "solr" the guy who managed to sneak onto your network has no idea that that thing on 10.x.x.x:9993 is a valuable solr target. > 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
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925765#comment-17925765 ] Jan Høydahl commented on SOLR-17659: I think this discussion is de-railing the progress for simple BasicAuth support in new UI. Let's keep Solr backend out of this in this phase. This Jira won't change anything about the security stance for Solr. The APIs are as secure as they always were, and I see no reason whatsoever to try to obscure what APIs a solr server has available. We must assume both users and attackers how what Solr is and what APIs it has. The Solr backend won't be less secure by adding another UI frontend, and it won't be more secure by trying to hide APIs or version info. Btw - the Solr APIs *do* implement fairly standard auth headers. If you hit any Solr endpoint without auth, the server will respond with 401 along with the WWW-Authenticate header, which tells the client what auth(s) is enabled on the server. And the old UI parses the WWW-Authenticate header to choose what login form to display. In case of JWT auth enabled, Solr *also* emits [a custom header "X-Solr-AuthData"|https://github.com/apache/solr/blob/main/solr/modules/jwt-auth/src/java/org/apache/solr/security/jwt/JWTAuthPlugin.java#L850-L862] that the UI parses to have enough data for it to handle the OIDC auth flow. Since the Admin UI is 100% static it needs to get this from the server. > 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
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925695#comment-17925695 ] Christos Malliaridis commented on SOLR-17659: - I start to get a better understanding now. What I am wondering now is, would a deep link / a "redirect" to the new UI (either web, desktop client or anything else), with the necessary authentication / authorization token be sufficient? Because the new UI will have to handle such cases, like for OAuth, anyway. Completely hiding the UI from the user would be possible, but there must be then a module that will take care of the auth and that would handle all the redirects and token generation flows. And I think from the perspective of OAuth at least, this could be cumbersome to implement, as OAuth flows are very specific which parties are involved and who is redirecting where. I believe it can work without issues and as expected, as long as there is this "facade" infront of the UI. I'm still not sure though if this could be addressed early enough so that the new UI could make use of that (if it has to do anything differently, like not showing login masks). Perhaps it is for now quicker to go with a more "direct" approach and implement the most important auth options in the new UI, and until we have a working solution for "hiding" the UI, we would use the UIs auth screens? And we should still not forget that we try to address relatively serious issue, the replacement of angularjs that has been discontinued since 2022. With that said, we should definitely not take the security lightly, which is why we discuss these matters in such detail. :) > 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
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[
https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925634#comment-17925634
]
Gus Heck commented on SOLR-17659:
-
{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//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 th
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[
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 af
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925396#comment-17925396 ] Gus Heck commented on SOLR-17659: - I also hope that the login stuff is kept simple enough that it rarely changes and attackers have difficulty identifying the version of Solr based on it (and thus don't know what exploits to focus on). > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925394#comment-17925394 ] Gus Heck commented on SOLR-17659: - To be clearer, think of the browser based UI as a pre-made list of URLs and Features to try to exploit. I would prefer not to allow attackers to be able to download a guided tour of things to hack from my server. > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925389#comment-17925389 ] Gus Heck commented on SOLR-17659: - Yes I believe I said just that. > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925383#comment-17925383 ] Jan Høydahl commented on SOLR-17659: Ui is only yet another solr client. No data. No special access. Any client must be granted direct access to Solrs backend port 8983. Thus whether you use a UI or cURL or SolrJ, you will gain access to exactly the same APIs and data, depending on how auth/autz is configured in solr. > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925379#comment-17925379 ] Gus Heck commented on SOLR-17659: - Another facet of what I'm saying is that the login should be tiny and easy to audit relative to the overall UI. > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925377#comment-17925377 ] Gus Heck commented on SOLR-17659: - What I'm advocating is that unauthenticated users cannot load the browser based client (application, aka ui) and use it to look for ways we have accidentally exposed information or features that are not properly protected. The login page should be a separate app (installed at the root context so it can set cookies/Authorization/etc that the browser will happily send to /solr /api etc.). I'm happy to agree that this ticket only handles Basic Auth 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]. That means we need to identify the flows for all use cases and understand how this form will satisfy them even if we don't create the plumbing to actually do so. Otherwise we likely wind up with three login forms that have to be enabled/disabled depending on what's being done, or a spiderweb of code dispatching on auth type that makes it very difficult to add new auth types when they come along. An independent app that establishes auth (either with a form or by redirecting to an external provider) and then redirects to the /ui context (or provides that redirect url to the external provider) to load the browser based ui application hopefully is reusable in all cases (if not I'm of course open to other solutions). Friendly 503 pages etc should just use the jetty error page functionality. Also I think it's fine for this ticket to only cover the UI side of it, anything that needs to change in core Solr to allow for sanity here can be a linked ticket. As a side note I'd expect that if we build it this way it would be easy for the same login form to * redirect to the old UI * redirect to the new UI (config option) * redirect to a custom UI written by a third party and added in to solr * redirect to a custom UI written by a third party hosted elsewhere (perhaps requires some as yet undeveloped proxy magic in cases that rely on basic or schemes involving cookies?) > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[
https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925328#comment-17925328
]
Christos Malliaridis commented on SOLR-17659:
-
As Jan correctly said, the new UI is a client side application that only
interacts with Solr via the existing API. The new UI is "just a client with a
user interface" that loads Solr information only via Solr's existing API. So
even if all "pages" of the UI are accessible or the login form is "bypassed",
the user won't get any information about Solr through the new UI if the API is
properly requiring and checking the necessary authentication / authorization.
{quote}Additionally I think rather than "basic auth" this should work with
"whatever auth is configured for solr as a whole" So if they are using JWT, the
login should redirect to the JWT token provider login, and if they have the
appropriate token already, it should not show up.
{quote}
I agree, that is the goal and what we aim for, to support all authentication
options that can be configured in Solr. I even want to support multiple auth
options if more than one is configured. However, since I expect a larger
workload when we try to address all authentication options at the same time,
this issue focuses only on the basic auth with credentials for now. Bringing
support for the rest should be addressed one by one and in separate tickets, so
that the scope of each issue stays managable.
{quote}Finally in the design I don't understand "back" or what Start Screen
would be in the criteria above. If authentication is enabled, there should be
nothing visible other than the login screen (and it's required resources).
{quote}
To understand the requirement here, it is important to distinguish between a
desktop client that can connect to any Solr instance via a URL the user
provides, and the web-browser that is deployed right now with an existing Solr
instance and accessed with the according URL from the browser window (this
means, the Solr URL is already known and fix). In the scenario of a desktop
client, the users have the "start screen" where they can type in the URL of a
Solr instance. Once they provide a valid URL and hit "connect", it will check
if there is for that specific instance authentication required. If so, the next
"form" will be the authentication form. In case the user decides to "abort" and
go back to type in another instance URL, there should be a back button to go
back to the previous form.
If we look at the browser variant only, the "start screen" has only one purpose
right now, and that is to check if authentication is required and show the
login form if that is the case. Theoretically, other error handling options
like for "service unavailable (HTTP 503)" could be added in the future, so that
if a solr instance is unavailable during an update or so, the UI could still be
displaying a helpful message like "please try again in a few minutes" (if it is
of course available).
And about OAuth and OIDC, I am not sure about Solr's current state, but I
believe that using an external Identity Provider with OAuth/OIDC support, Solr
would be just a "resource server" in terms of OAuth, those the sole
responsibility of Solr's API would be to verify the tokens provided by requests
like from the new UI and grant / refuse access. Not sure if we need additional
changes on Solr's part. The new UI on the other hand would have to follow the
"Authorization Code Flow with Proof Key for Code Exchange (PKCE)", which does
not require a client secret to be shipped with the client, which otherwise
could easily be extracted from browser and from the standalone client. But that
is a discussion for the follow-up issue that addresses OAuth/OIDC support in
the new UI. :)
> 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
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925323#comment-17925323 ] Jan Høydahl commented on SOLR-17659: This is an exciting part of the UI, and I see where you're coming from Gus. But before we dive deep into your proposals, let's make clear the scope of the first version of the new UI. The new UI is a client side application which hits Solr's normal REST APIs. There is not dedicated admin-UI backend component/servlet, thus any authentication that can be done on top of existing Solr backend must use Solr's existing auth capabilities, and each and every call from the UI app must carry the "Authorization" header. There is really not "login" or "logout" or session. Thus I think the scope of supporting BasicAuth only from the get-go is a good one. I feel your pain Gus about Solr's home-made auth framework. It would be nice to have a better version, but it's a totally separate effort. Wrt the JWT and OIDC auth, it is currently implemented on the client side (JS) and the browser keeps a long-lived bearer token. It is not the best solution, and we should really not go that direction with the new UI. Ideally we should have a new ui-backend servlet that takes care of code-flow with client-secret, session handling, issuing cookie to the new UI etc. Such a servlet should ideally take all UI traffic and proxy it to the Solr APIs, and it should be deploable either on a normal Solr node or on a dedicated UI backend node (using node roles). Such a UI backend could then de-couple human auth methods from the auth necessary to impelement on solr backends, and even if a user loggs in with OIDC to the UI backend, the requests sent to the solr nodes could use a different auth, such as mTLS or basicAuth. > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925320#comment-17925320 ] Gus Heck commented on SOLR-17659: - I suspect you probably already intend it but to be explicit I think we also want these criteria. * Authentication is not required to see the login form (pretty obvious) * _*Only*_ the login form and it's dedicated images/js/css can be viewed without authentication, no other services or files are available (and no info useful to attackers about the version of solr or jetty etc is exposed) Additionally I think rather than "basic auth" this should work with "whatever auth is configured for solr as a whole" So if they are using JWT, the login should redirect to the JWT token provider login, and if they have the appropriate token already, it should not show up. I think the best strategy is to have this be an entirely separate application context so that it just simply has no access to any solr code at all, and have a servlet filter around the solr stuff that redirects to it if authentication is not satisfied. I know this is pretty far out of the UI realm, but login page design really has to work with a backend, and the way we do it now we are already well into SolrDispatchFilter before auth is checked which makes it hard to protect the UI in the same manner as the services. Finally in the design I don't understand "back" or what Start Screen would be in the criteria above. If authentication is enabled, there should be nothing visible other than the login screen (and it's required resources). > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
