[
https://issues.apache.org/jira/browse/SOLR-15573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter updated SOLR-15573:
----------------------------------
Description:
I ran the following command to enable basic auth for my Solr installation:
{code}
bin/solr auth enable -type basicAuth -prompt true -z localhost:2181
-blockUnknown true
{code}
It created the security policy with {{blockUnknown=false}}. That's an issue
with arg parsing in BASH (easy to fix) ... the bigger issue is the Admin UI
relies on getting a 401 from the backend to show login / logout but with
blockUnknown=false, this never shows.
The {{auth}} utility only creates role bindings for the following predefined
permissions:
{code}
{"name":"security-edit", "role":"admin"},
{"name":"collection-admin-edit", "role":"admin"},
{"name":"core-admin-edit", "role":"admin"}
{code}
The problem is when {{blockUnknown=false}}, the UI doesn't hit any endpoints
that trigger a 401 to cause the Admin UI to prompt for a login. I think the
initial {{security.json}} created by the {{auth}} tool should also include:
{code}
{"name":"security-read", "role":"admin"},
{"name":"config-edit", "role":"admin"},
{code}
The {{config-edit}} is needed for the new Schema Designer UI and we shouldn't
allow un-authenticated users to edit configs anyway.
With these two new permissions in place, when an un-authenticated user
navigates to the new Security screen, they will be redirected to login.
was:
I ran the following command to enable basic auth for my Solr installation:
{code}
bin/solr auth enable -type basicAuth -prompt true -z localhost:2181
-blockUnknown true
{code}
It created the security policy with {{blockUnknown=false}}. That's an issue ...
the bigger issue is the Admin UI relies on getting a 401 from the backend to
show login / logout but with blockUnknown=false, this never shows. I'm not
seeing this behavior on main, only 8x, so I suspect it's been fixed and just
not backported?!? Need to research.
> Basic auth must set blockUnknown=true for Admin UI to force login, with
> blockUnknown=false there's no way to login to the admin UI to do privileged
> actions
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-15573
> URL: https://issues.apache.org/jira/browse/SOLR-15573
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Timothy Potter
> Assignee: Timothy Potter
> Priority: Major
> Fix For: 8.10
>
> Attachments: no-username-but-basic-auth-enabled.png
>
>
> I ran the following command to enable basic auth for my Solr installation:
> {code}
> bin/solr auth enable -type basicAuth -prompt true -z localhost:2181
> -blockUnknown true
> {code}
> It created the security policy with {{blockUnknown=false}}. That's an issue
> with arg parsing in BASH (easy to fix) ... the bigger issue is the Admin UI
> relies on getting a 401 from the backend to show login / logout but with
> blockUnknown=false, this never shows.
> The {{auth}} utility only creates role bindings for the following predefined
> permissions:
> {code}
> {"name":"security-edit", "role":"admin"},
> {"name":"collection-admin-edit", "role":"admin"},
> {"name":"core-admin-edit", "role":"admin"}
> {code}
> The problem is when {{blockUnknown=false}}, the UI doesn't hit any endpoints
> that trigger a 401 to cause the Admin UI to prompt for a login. I think the
> initial {{security.json}} created by the {{auth}} tool should also include:
> {code}
> {"name":"security-read", "role":"admin"},
> {"name":"config-edit", "role":"admin"},
> {code}
> The {{config-edit}} is needed for the new Schema Designer UI and we shouldn't
> allow un-authenticated users to edit configs anyway.
> With these two new permissions in place, when an un-authenticated user
> navigates to the new Security screen, they will be redirected to login.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
