Solr
  1. Solr
  2. SOLR-8429

add a flag blockUnknown to BasicAutPlugin

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.5, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      If authentication is setup with BasicAuthPlugin, it let's all requests go through if no credentials are passed. This was done to have minimal impact for users who only wishes to protect a few end points (say , collection admin and core admin only)

      We can add a flag to BasicAuthPlugin to allow only authenticated requests to go in

      the users can create the first security.json with that flag

      server/scripts/cloud-scripts/zkcli.sh -z localhost:9983 -cmd put /security.json '{"authentication": {"class": "solr.BasicAuthPlugin", 
      "blockUnknown": true,
      "credentials": {"solr": "orwp2Ghgj39lmnrZOTm7Qtre1VqHFDfwAEzr0ApbN3Y= Ju5osoAqOX8iafhWpPP01E5P+sg8tK8tHON7rCYZRRw="}}}'
      

      or add the flag later
      using the command

      curl  http://localhost:8983/solr/admin/authentication -H 'Content-type:application/json' -d  '{ 
      {set-property:{blockUnknown:true}
      }'
      

        Activity

        Hide
        Jan Høydahl added a comment -

        Let's make it default to true from 5.5, aligning with what people expect after enabling auth in any piece of software. We can fix back-compat using luceneMatchVersion, or I'm also OK with treating this as a Bug, documenting the change in CHANGES, since the refGuide does not even mention the current behavior.

        Is it at all possible with 5.4 to make BasicAuth work without also specifying authorization?

        Show
        Jan Høydahl added a comment - Let's make it default to true from 5.5, aligning with what people expect after enabling auth in any piece of software. We can fix back-compat using luceneMatchVersion , or I'm also OK with treating this as a Bug, documenting the change in CHANGES, since the refGuide does not even mention the current behavior. Is it at all possible with 5.4 to make BasicAuth work without also specifying authorization?
        Hide
        Noble Paul added a comment -

        I don't think we need to change the default and change the default behavior. All we need to do is change the example and add this flag there. So everyone who use this feature will see the flag. If we put in the default nobody will know this.

        The point about security is that there are a lot of users who have solr without security and they would just want to have minimal security. This would be to just avoid certain operations being performed inadvertently. So, security is a mechanism to protect their solr from themselves

        Show
        Noble Paul added a comment - I don't think we need to change the default and change the default behavior. All we need to do is change the example and add this flag there. So everyone who use this feature will see the flag. If we put in the default nobody will know this. The point about security is that there are a lot of users who have solr without security and they would just want to have minimal security. This would be to just avoid certain operations being performed inadvertently. So, security is a mechanism to protect their solr from themselves
        Hide
        Jan Høydahl added a comment -

        All we need to do is change the example and add this flag there.

        We have a tradition of letting example configs and defaults be the same, and reflect what majority of users want/need/expect.

        If we put in the default nobody will know this.

        By controlling the default in luceneMatchVersion, people upgrading solr without upgrading their config will get what they had, and still be able to add the flag if they wish. Those bumping their config version will get the new default, and they will be aware of it since it will be highlighted in the Upgrading from Solr 5.4 section of CHANGES.

        ...a lot of users who have solr without security and they would just want to have minimal security.

        With "a lot of" – do you mean "the majority"? The defaults should reflect what most people would want when securing their Solr in production for the first time. The simplest possible requirement is typically to require user/pass across the board. This should work, without also having to configure an authorization plugin. Those that also want to add users, groups and roles will add a authorization section, and those that want to open up for unauthenticated users/clients would add the new flag.

        This one command should be enough to secure all of Solr with username solr and password solr:

        server/scripts/cloud-scripts/zkcli.sh -z localhost:9983 -cmd put /security.json '{"authentication": {"class": "solr.BasicAuthPlugin","credentials": {"solr": "i9buKe/RhJV5bF/46EI9xmVVYyrnbg9zXf+2FrFwcy0= OTg3"}}}'
        

        What to do if only class and no credentials are given? A) Temporarily allow all traffic until at least 1 user is created, or B) Enable default credentials admin/admin with a big fat warning in the ADMIN UI that it must be changed?

        Show
        Jan Høydahl added a comment - All we need to do is change the example and add this flag there. We have a tradition of letting example configs and defaults be the same, and reflect what majority of users want/need/expect. If we put in the default nobody will know this. By controlling the default in luceneMatchVersion, people upgrading solr without upgrading their config will get what they had, and still be able to add the flag if they wish. Those bumping their config version will get the new default, and they will be aware of it since it will be highlighted in the Upgrading from Solr 5.4 section of CHANGES. ...a lot of users who have solr without security and they would just want to have minimal security. With "a lot of" – do you mean "the majority"? The defaults should reflect what most people would want when securing their Solr in production for the first time. The simplest possible requirement is typically to require user/pass across the board. This should work, without also having to configure an authorization plugin. Those that also want to add users, groups and roles will add a authorization section, and those that want to open up for unauthenticated users/clients would add the new flag. This one command should be enough to secure all of Solr with username solr and password solr: server/scripts/cloud-scripts/zkcli.sh -z localhost:9983 -cmd put /security.json '{ "authentication" : { "class" : "solr.BasicAuthPlugin" , "credentials" : { "solr" : "i9buKe/RhJV5bF/46EI9xmVVYyrnbg9zXf+2FrFwcy0= OTg3" }}}' What to do if only class and no credentials are given? A) Temporarily allow all traffic until at least 1 user is created, or B) Enable default credentials admin/admin with a big fat warning in the ADMIN UI that it must be changed?
        Hide
        Noble Paul added a comment -

        By controlling the default in luceneMatchVersion, people upgrading solr without upgrading their config will get what they had, and still be able to add the flag if they wish.

        I don't wish to tie this to luceneMatchVersion . This is just adding complexity and making it harder to debug

        With "a lot of" – do you mean "the majority"?

        I have no numbers to justify either way. Solr users haven't had any authentication in the past. So the assumption was that most of them did not need any security (or they had alternate solutions).

        Lets say what my proposal look like

        server/scripts/cloud-scripts/zkcli.sh -z localhost:9983 -cmd put /security.json '{"authentication": {"class": "solr.BasicAuthPlugin", 
        "blockUnauthenticated":true ,
        "credentials": {"solr": "i9buKe/RhJV5bF/46EI9xmVVYyrnbg9zXf+2FrFwcy0= OTg3"}}}'
        

        I'm eager to hear what others think about this.

        Show
        Noble Paul added a comment - By controlling the default in luceneMatchVersion, people upgrading solr without upgrading their config will get what they had, and still be able to add the flag if they wish. I don't wish to tie this to luceneMatchVersion . This is just adding complexity and making it harder to debug With "a lot of" – do you mean "the majority"? I have no numbers to justify either way. Solr users haven't had any authentication in the past. So the assumption was that most of them did not need any security (or they had alternate solutions). Lets say what my proposal look like server/scripts/cloud-scripts/zkcli.sh -z localhost:9983 -cmd put /security.json '{ "authentication" : { "class" : "solr.BasicAuthPlugin" , "blockUnauthenticated" : true , "credentials" : { "solr" : "i9buKe/RhJV5bF/46EI9xmVVYyrnbg9zXf+2FrFwcy0= OTg3" }}}' I'm eager to hear what others think about this.
        Hide
        Jan Høydahl added a comment -

        I don't wish to tie this to luceneMatchVersion

        Thinking a bit more, luceneMatchVersion wouldn't work here anyway, since we're talking node-level config and not collection-level? Still I ghink a new default setting can be introduced with proper release note documentation.

        So the assumption was that most of them did not need any security (or they had alternate solutions).

        My clients mostly use Container managed security in Jetty/Tomcat, and some use SSL client certificate authentication - both solutions lock down the entire /solr namespace. Guess there are plenty of these out there on older versions looking to switch to Solr managed security.

        So, with this new flag enabled, what if you want to add rulesBasedAuthorization and explicitly open up a certain path, say /solr/foo/select to unauthenticated users. Would that be possible, or would the enforcing of auth happen before the authz plugin can decide?

        Show
        Jan Høydahl added a comment - I don't wish to tie this to luceneMatchVersion Thinking a bit more, luceneMatchVersion wouldn't work here anyway, since we're talking node-level config and not collection-level? Still I ghink a new default setting can be introduced with proper release note documentation. So the assumption was that most of them did not need any security (or they had alternate solutions). My clients mostly use Container managed security in Jetty/Tomcat, and some use SSL client certificate authentication - both solutions lock down the entire /solr namespace. Guess there are plenty of these out there on older versions looking to switch to Solr managed security. So, with this new flag enabled, what if you want to add rulesBasedAuthorization and explicitly open up a certain path, say /solr/foo/select to unauthenticated users. Would that be possible, or would the enforcing of auth happen before the authz plugin can decide?
        Hide
        Noble Paul added a comment -

        If "blockUnauthenticated":true is set , you don't have the choice of allowing any path without authentication

        However you can do the following . create a permission called all ( SOLR-8428 ) and then explicitly open up the path /solr/foo/select using a wild card role role:"*" ( SOLR-8434 ). The rules would look like the follows

        {
        "authorization" :{
        "permissions":[
        {"name": "foo-read",
        "collection": "foo",
        "path": "/select",
        "role": null},
        {"name":"all" ,
        "role": "*"}]}}
        
        Show
        Noble Paul added a comment - If "blockUnauthenticated":true is set , you don't have the choice of allowing any path without authentication However you can do the following . create a permission called all ( SOLR-8428 ) and then explicitly open up the path /solr/foo/select using a wild card role role:"*" ( SOLR-8434 ). The rules would look like the follows { "authorization" :{ "permissions" :[ { "name" : "foo-read" , "collection" : "foo" , "path" : "/select" , "role" : null }, { "name" : "all" , "role" : "*" }]}}
        Hide
        Jan Høydahl added a comment -

        Cool. This workaround would require blockUnauthenticated to be false, right?

        Just a thought: If the new flag blockUnauthenticated is not explicitly defined in config, could the default be smart and depend on whether an Authorization plugin is active or not? There is no use in BasicAuthPlugin alone without this enabled... Pseudo:

        // Default to true if no authz configured
        boolean blockUnauthenticated = config.get("blockUnauthenticated", !hasAuthorizationPlugin());
        

        Then we would continue to omit the flag in example configs, and document it for those who rather want to block using the flag instead of an all permission. That way we'd get back compat as well, not?

        Show
        Jan Høydahl added a comment - Cool. This workaround would require blockUnauthenticated to be false, right? Just a thought: If the new flag blockUnauthenticated is not explicitly defined in config, could the default be smart and depend on whether an Authorization plugin is active or not? There is no use in BasicAuthPlugin alone without this enabled... Pseudo: // Default to true if no authz configured boolean blockUnauthenticated = config.get( "blockUnauthenticated" , !hasAuthorizationPlugin()); Then we would continue to omit the flag in example configs, and document it for those who rather want to block using the flag instead of an all permission. That way we'd get back compat as well, not?
        Hide
        Noble Paul added a comment -

        Cool. This workaround would require blockUnauthenticated to be false, right?

        yes

        Just a thought: If the new flag blockUnauthenticated is not explicitly defined in config, could the default be smart and depend on whether an Authorization plugin is active or not?

        I'm kinda against any rule which requires a user to read documentation to understand. The rule of thumb is if a user looks at the security.json he should have enough idea on what could happen.

        Show
        Noble Paul added a comment - Cool. This workaround would require blockUnauthenticated to be false, right? yes Just a thought: If the new flag blockUnauthenticated is not explicitly defined in config, could the default be smart and depend on whether an Authorization plugin is active or not? I'm kinda against any rule which requires a user to read documentation to understand. The rule of thumb is if a user looks at the security.json he should have enough idea on what could happen.
        Hide
        ASF subversion and git services added a comment -

        Commit 1720732 from Noble Paul in branch 'dev/trunk'
        [ https://svn.apache.org/r1720732 ]

        SOLR-8429 precommit error

        Show
        ASF subversion and git services added a comment - Commit 1720732 from Noble Paul in branch 'dev/trunk' [ https://svn.apache.org/r1720732 ] SOLR-8429 precommit error
        Hide
        Jan Høydahl added a comment -

        I'm kinda against any rule which requires a user to read documentation to understand. The rule of thumb is if a user looks at the security.json he should have enough idea on what could happen.

        Agree, but how can a user reading this security.json

        {"authentication": {"class": "solr.BasicAuthPlugin",  "credentials": {"solr": "i9buKe/RhJV5bF/46EI9xmVVYyrnbg9zXf+2FrFwcy0= OTg3"}}}
        

        ...have any clue that absolutely nothing will be protected – unless that was the default? On the other hand, if he saw "blockUnknown":false in there, he'd be explicitly warned that it is necessary to cover every single path in AutorizationPlugin

        Related: Should we protect the user against locking herself out, i.e. throw exception if blockUnknown is set through API before there are any registered users?

        Show
        Jan Høydahl added a comment - I'm kinda against any rule which requires a user to read documentation to understand. The rule of thumb is if a user looks at the security.json he should have enough idea on what could happen. Agree, but how can a user reading this security.json { "authentication" : { "class" : "solr.BasicAuthPlugin" , "credentials" : { "solr" : "i9buKe/RhJV5bF/46EI9xmVVYyrnbg9zXf+2FrFwcy0= OTg3" }}} ...have any clue that absolutely nothing will be protected – unless that was the default? On the other hand, if he saw "blockUnknown":false in there, he'd be explicitly warned that it is necessary to cover every single path in AutorizationPlugin Related: Should we protect the user against locking herself out, i.e. throw exception if blockUnknown is set through API before there are any registered users?
        Hide
        Noble Paul added a comment - - edited

        have any clue that absolutely nothing will be protected – unless that was the default?

        A person configuring security will follow our documentation. Our documentation will have blockUnknown=true in the sample. So his setup is protected automatically.

        Related: Should we protect the user against locking herself out,

        Nice to have. Anyway he has the option of overwriting the security.json if he screws up badly

        Show
        Noble Paul added a comment - - edited have any clue that absolutely nothing will be protected – unless that was the default? A person configuring security will follow our documentation. Our documentation will have blockUnknown=true in the sample. So his setup is protected automatically. Related: Should we protect the user against locking herself out, Nice to have. Anyway he has the option of overwriting the security.json if he screws up badly
        Hide
        Noble Paul added a comment -

        Commit 1720729 from Noble Paul in branch 'dev/trunk'
        [ https://svn.apache.org/r1720729 ]

        SOLR-8429: Add a flag 'blockUnknown' to BasicAuthPlugin to block unauthenticated requests

        Show
        Noble Paul added a comment - Commit 1720729 from Noble Paul in branch 'dev/trunk' [ https://svn.apache.org/r1720729 ] SOLR-8429 : Add a flag 'blockUnknown' to BasicAuthPlugin to block unauthenticated requests
        Hide
        ASF subversion and git services added a comment -

        Commit 1720777 from Noble Paul in branch 'dev/branches/branch_5x'
        [ https://svn.apache.org/r1720777 ]

        SOLR-8429: Add a flag 'blockUnknown' to BasicAuthPlugin to block unauthenticated requests

        Show
        ASF subversion and git services added a comment - Commit 1720777 from Noble Paul in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1720777 ] SOLR-8429 : Add a flag 'blockUnknown' to BasicAuthPlugin to block unauthenticated requests

          People

          • Assignee:
            Noble Paul
            Reporter:
            Noble Paul
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development