[ https://issues.apache.org/jira/browse/SOLR-16907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated SOLR-16907: --------------------------------- Description: I had a very strange behaviour of Authorization after migrating a standalone solr instance to Solr 9 keeping the existing security.json file. To reproduce, place the attached [^security.json] in the solr.home (it has default password "SolrRocks"). The only change I did was adding {{"blockUnknown":false}}, because the whole idea of the file is just to prevent people doing some changes to configuration, but all queries/select/.... on cores/collections should work without authentication (basically to prevent the developers from accessing admin UI and change something). After applying this config, all requests to any core were denied with "Authentication failed, Response code: 401". This message does not come from the "BasicAuthenticationProvider" (hint: if you enable "blockUnknown", it fails earlier and print as error message: "require authentication" coming from BasicAuthenticationProvider). So the problem was *not* caused by the setting "blockUnknown=false" ignored. It took me a long time to actually find the reason and without enabling debug logging and going through all settings I found the issue. This is totally unexpected and should be fixed as no warning or reason is printed to default log. {noformat} 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler scope null||/solr/techproducts/select @ o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp} 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler context=/solr||/techproducts/select @ o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp} 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler servlet /solr|/techproducts/select|null|ServletPathMapping{matchValue=, pattern=/, servletName=default, mappingMatch=DEFAULT, servletPath=/techproducts/select, pathInfo=null} -> default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED} 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler chain=Chain@47a4b5d5(SolrRequestFilter==org.apache.solr.servlet.SolrDispatchFilter@30d15e4a{inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/WEB-INF/web.xml})->ChainEnd@2c16acde(default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED}) 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.a.s.s.SolrDispatchFilter Request to authenticate: org.apache.solr.servlet.ServletUtils$1@5726199e, domain: 127.0.0.1, port: 8983 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.a.s.s.SolrDispatchFilter User principal: null 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.AuthorizationUtils AuthorizationContext : userPrincipal: [null] type: [READ], collections: [], Path: [/select] path : /select params : 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.RuleBasedAuthorizationPluginBase Attempting to authorize request to [/select] of type: [READ], associated with collections [[]] 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.RuleBasedAuthorizationPluginBase Authorizing collection-aware request, checking perms applicable to all (*) collections 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.RuleBasedAuthorizationPluginBase Found perm [{ "name":"autoscaling-write", "role":"admin", "index":5}] to govern resource [/select] 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.RuleBasedAuthorizationPluginBase Governing permission [{ "name":"autoscaling-write", "role":"admin", "index":5}] has role, but request principal cannot be identified; forbidding access 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.AuthorizationUtils USER_REQUIRED null null 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.e.j.s.HttpChannelState sendError HttpChannelState@ca1dc41{s=HANDLING rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0} {noformat} The reason is that the role map still contains the *outdated* 8.x "autoscaling-write" permission and for unknown reason it is selected as permission that needs to be enforced for /select queries to the core. I have no idea why this happens! This is in my opinion the main issue here. After that, the rule based authorization figures out that the principal is null and send the 401 response with useless error message (and by default no log entry at all!!!!). After removing the outdated perm from the security.json, requests to /select go through without authentication. This problem may affect other people when upgrading Solr, as it is totally unexpected that a no longer existing permission is selected to authorize! To fix please try to be more helpful: - Log warnings when authorization fail, so one must not use DEBUG logging! - fix the bug that "autoscaling-write" is selected as permission for any request to the core (not only /select is affected, everything). - if a permission is unknown (legacy from 8.x), a warning should be printed on startup and in the admin UI was: I had a very strange behaviour of Authorization after migrating a standalone solr instance to Solr 9 keeping the existing security.json file. To reproduce, place the attached [^security.json] in the solr.home (it has default password "SolrRocks"). The only change I did was adding {{"blockUnknown":false}}, because the whole idea of the file is just to prevent people doing some changes to configuration, but all queries/select/.... on cores/collections should work without authentication (basically to prevent the developers from accessing admin UI and change something). After applying this config, all requests to any core were denied with "Authentication failed, Response code: 401". This message does not come from the "BasicAuthenticationProvider" (hint: if you enable "blockUnknown", it fails earlier and print as error message: "require authentication" coming from BasicAuthenticationProvider). So the problem was *not* caused by the setting "blockUnknown=false" ignored. It took me a long time to actually find the reason and without enabling debug logging and going through all settings I found the issue. This is totally unexpected and should be fixed as no warning or reason is printed to default log. {noformat} 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler scope null||/solr/techproducts/select @ o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp} 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler context=/solr||/techproducts/select @ o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp} 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler servlet /solr|/techproducts/select|null|ServletPathMapping{matchValue=, pattern=/, servletName=default, mappingMatch=DEFAULT, servletPath=/techproducts/select, pathInfo=null} -> default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED} 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler chain=Chain@47a4b5d5(SolrRequestFilter==org.apache.solr.servlet.SolrDispatchFilter@30d15e4a{inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/WEB-INF/web.xml})->ChainEnd@2c16acde(default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED}) 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.a.s.s.SolrDispatchFilter Request to authenticate: org.apache.solr.servlet.ServletUtils$1@5726199e, domain: 127.0.0.1, port: 8983 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.a.s.s.SolrDispatchFilter User principal: null 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.AuthorizationUtils AuthorizationContext : userPrincipal: [null] type: [READ], collections: [], Path: [/select] path : /select params : 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.RuleBasedAuthorizationPluginBase Attempting to authorize request to [/select] of type: [READ], associated with collections [[]] 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.RuleBasedAuthorizationPluginBase Authorizing collection-aware request, checking perms applicable to all (*) collections 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.RuleBasedAuthorizationPluginBase Found perm [{ "name":"autoscaling-write", "role":"admin", "index":5}] to govern resource [/select] 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.RuleBasedAuthorizationPluginBase Governing permission [{ "name":"autoscaling-write", "role":"admin", "index":5}] has role, but request principal cannot be identified; forbidding access 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.a.s.s.AuthorizationUtils USER_REQUIRED null null 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] o.e.j.s.HttpChannelState sendError HttpChannelState@ca1dc41{s=HANDLING rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0} {noformat} The reason is that the role map still contains the *outdated* 8.x "autoscaling-write" permission and for unknown reason it is selected as permission that needs to be enforced for /select queries to the core. I have no idea why this happens! This is in my opinion the main issue here. After that, the rule based authorization figures out that the principal is null and send the 401 response with useless error message (and by default no log entry at all!!!!). After removing the outdated role from the security.json, requests to /select go through without authentication. This problem may affect other people when upgrading Solr, as it is totally unexpected that a no longer existing permission is selected to authorize! To fix please try to be more helpful: - Log warnings when authorization fail, so one must not use DEBUG logging! - fix the bug that "autoscaling-write" is selected as permission for any request to the core (not only /select is affected, everything). - if a permission is unknown (legacy from 8.x), a warning should be printed on startup and in the admin UI > Strange behaviour after upgrade to 9.x when security json has no longer > existing permission > ------------------------------------------------------------------------------------------- > > Key: SOLR-16907 > URL: https://issues.apache.org/jira/browse/SOLR-16907 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Authentication, Authorization > Affects Versions: 9.0, 9.1, 9.2, 9.3 > Reporter: Uwe Schindler > Priority: Major > Attachments: security.json > > > I had a very strange behaviour of Authorization after migrating a standalone > solr instance to Solr 9 keeping the existing security.json file. > > To reproduce, place the attached [^security.json] in the solr.home (it has > default password "SolrRocks"). The only change I did was adding > {{"blockUnknown":false}}, because the whole idea of the file is just to > prevent people doing some changes to configuration, but all > queries/select/.... on cores/collections should work without authentication > (basically to prevent the developers from accessing admin UI and change > something). > After applying this config, all requests to any core were denied with > "Authentication failed, Response code: 401". This message does not come from > the "BasicAuthenticationProvider" (hint: if you enable "blockUnknown", it > fails earlier and print as error message: "require authentication" coming > from BasicAuthenticationProvider). So the problem was *not* caused by the > setting "blockUnknown=false" ignored. > It took me a long time to actually find the reason and without enabling debug > logging and going through all settings I found the issue. This is totally > unexpected and should be fixed as no warning or reason is printed to default > log. > {noformat} > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler > scope null||/solr/techproducts/select @ > o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe > Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp} > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler > context=/solr||/techproducts/select @ > o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe > Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp} > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler > servlet /solr|/techproducts/select|null|ServletPathMapping{matchValue=, > pattern=/, servletName=default, mappingMatch=DEFAULT, > servletPath=/techproducts/select, pathInfo=null} -> > default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED} > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler > chain=Chain@47a4b5d5(SolrRequestFilter==org.apache.solr.servlet.SolrDispatchFilter@30d15e4a{inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/WEB-INF/web.xml})->ChainEnd@2c16acde(default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED}) > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] > o.a.s.s.SolrDispatchFilter Request to authenticate: > org.apache.solr.servlet.ServletUtils$1@5726199e, domain: 127.0.0.1, port: 8983 > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] > o.a.s.s.SolrDispatchFilter User principal: null > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] > o.a.s.s.AuthorizationUtils AuthorizationContext : userPrincipal: [null] type: > [READ], collections: [], Path: [/select] path : /select params : > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] > o.a.s.s.RuleBasedAuthorizationPluginBase Attempting to authorize request to > [/select] of type: [READ], associated with collections [[]] > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] > o.a.s.s.RuleBasedAuthorizationPluginBase Authorizing collection-aware > request, checking perms applicable to all (*) collections > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] > o.a.s.s.RuleBasedAuthorizationPluginBase Found perm [{ > "name":"autoscaling-write", > "role":"admin", > "index":5}] to govern resource [/select] > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] > o.a.s.s.RuleBasedAuthorizationPluginBase Governing permission [{ > "name":"autoscaling-write", > "role":"admin", > "index":5}] has role, but request principal cannot be identified; > forbidding access > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] > o.a.s.s.AuthorizationUtils USER_REQUIRED null null > 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts] > o.e.j.s.HttpChannelState sendError HttpChannelState@ca1dc41{s=HANDLING > rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0} > {noformat} > The reason is that the role map still contains the *outdated* 8.x > "autoscaling-write" permission and for unknown reason it is selected as > permission that needs to be enforced for /select queries to the core. I have > no idea why this happens! This is in my opinion the main issue here. After > that, the rule based authorization figures out that the principal is null and > send the 401 response with useless error message (and by default no log entry > at all!!!!). > After removing the outdated perm from the security.json, requests to /select > go through without authentication. > This problem may affect other people when upgrading Solr, as it is totally > unexpected that a no longer existing permission is selected to authorize! > To fix please try to be more helpful: > - Log warnings when authorization fail, so one must not use DEBUG logging! > - fix the bug that "autoscaling-write" is selected as permission for any > request to the core (not only /select is affected, everything). > - if a permission is unknown (legacy from 8.x), a warning should be printed > on startup and in the admin UI -- 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