[
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 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
