Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-7896

Add a login page for Solr Administrative Interface

    Details

      Description

      Out of the box, the Solr Administrative interface should require a password that the user is required to set.

        Issue Links

          Activity

          Hide
          erickerickson Erick Erickson added a comment -

          Please bring this kind of thing up on the user's list rather than raise JIRAs to be sure you're not simply misunderstanding things. If it's a real problem in Solr, then raise a JIRA.

          Solr has never been intended to allow end-user access and thus has never implemented this kind of security. You allow me to get to the Solr URL directly and I can
          http://machine:port/solr/collection/update?commit=true&stream.body=<delete><query>:</query></delete>

          All your docs are gone.

          Show
          erickerickson Erick Erickson added a comment - Please bring this kind of thing up on the user's list rather than raise JIRAs to be sure you're not simply misunderstanding things. If it's a real problem in Solr, then raise a JIRA. Solr has never been intended to allow end-user access and thus has never implemented this kind of security. You allow me to get to the Solr URL directly and I can http://machine:port/solr/collection/update?commit=true&stream.body= <delete><query> : </query></delete> All your docs are gone.
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          You are in luck. Basic authentication has been added for the next release (5.3). See SOLR-7837.

          Also, Solr has supported SSL for a while now, see https://cwiki.apache.org/confluence/display/solr/Enabling+SSL

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - You are in luck. Basic authentication has been added for the next release (5.3). See SOLR-7837 . Also, Solr has supported SSL for a while now, see https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          Of course, this doesn't mean that you should expose Solr to the world-wide-web. It is still not secure against all kinds of attacks.

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - Of course, this doesn't mean that you should expose Solr to the world-wide-web. It is still not secure against all kinds of attacks.
          Hide
          thinkcomp Aaron Greenspan added a comment -

          SSL should be enabled by default.

          Show
          thinkcomp Aaron Greenspan added a comment - SSL should be enabled by default.
          Hide
          thinkcomp Aaron Greenspan added a comment - - edited

          It's all well and good to say that users shouldn't do things, but they're being done, and the code needs to be written to account for real-world use, not some hypothetical ideal that doesn't exist.

          Also, I would love for Solr to just be exposed exclusively on my server's internal IP address(es)--but I have no idea how to do that. The administrative web interface certainly doesn't let me select which IPs to bind to, which would be the easy way to implement that ideal. But regardless, it should never be assumed that every user will want to or know to operate Solr the same way (e.g. exclusively on a LAN behind a firewall).

          Show
          thinkcomp Aaron Greenspan added a comment - - edited It's all well and good to say that users shouldn't do things, but they're being done, and the code needs to be written to account for real-world use, not some hypothetical ideal that doesn't exist. Also, I would love for Solr to just be exposed exclusively on my server's internal IP address(es)--but I have no idea how to do that. The administrative web interface certainly doesn't let me select which IPs to bind to, which would be the easy way to implement that ideal. But regardless, it should never be assumed that every user will want to or know to operate Solr the same way (e.g. exclusively on a LAN behind a firewall).
          Hide
          thinkcomp Aaron Greenspan added a comment -

          I find it incredibly surprising that you could write the above and then change the issue status to "Not a Problem."

          Show
          thinkcomp Aaron Greenspan added a comment - I find it incredibly surprising that you could write the above and then change the issue status to "Not a Problem."
          Hide
          upayavira Upayavira added a comment -

          Given we have a new auth framework, and SSL support, this is do-able. I've not yet payed with, nor needed to, play with either.

          The benefit of discussing on the User list first, as Erick suggests, is to get more of an understanding of the use-cases you are looking at before we decide on an approach to solving them.

          Erick is right - Solr is not something that has traditionally been placed outside a firewall, because, well, it hasn't offered features that would allow that. This is starting to change, and I think auth on the admin UI would be a good thing, although I'm not yet in a position to work on it.

          Therefore, I'm inclined to re-open, even if I'm aware it'd take me some time to get around to it.

          Show
          upayavira Upayavira added a comment - Given we have a new auth framework, and SSL support, this is do-able. I've not yet payed with, nor needed to, play with either. The benefit of discussing on the User list first, as Erick suggests, is to get more of an understanding of the use-cases you are looking at before we decide on an approach to solving them. Erick is right - Solr is not something that has traditionally been placed outside a firewall, because, well, it hasn't offered features that would allow that. This is starting to change, and I think auth on the admin UI would be a good thing, although I'm not yet in a position to work on it. Therefore, I'm inclined to re-open, even if I'm aware it'd take me some time to get around to it.
          Hide
          upayavira Upayavira added a comment -

          As a slightly longer term goal, I believe this ticket does have merit, and given we have auth capabilities in Solr now, it makes sense to place the admin UI behind that.

          Show
          upayavira Upayavira added a comment - As a slightly longer term goal, I believe this ticket does have merit, and given we have auth capabilities in Solr now, it makes sense to place the admin UI behind that.
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          SSL should be enabled by default.

          I disagree. We have the option. People who need it can use them. We also have kerberos support so you can use that too along with SSL if you're really paranoid about security.

          It's all well and good to say that users shouldn't do things, but they're being done, and the code needs to be written to account for real-world use, not some hypothetical ideal that doesn't exist.

          Yeah, which is why we are building some support for security. But enabling it by default requires a lot of education for new users. We need to balance between the two. Perhaps some of this can be done via documentation? For example, we can link to the guides on SSL/Kerberos/BasicAuth on the "Taking Solr to Production" page?

          https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production

          Also, I would love for Solr to just be exposed exclusively on my server's internal IP address(es)--but I have no idea how to do that.

          You can do that by setting the "SOLR_HOST" property to the internal hostname or IP address in solr.in.

          {sh,cmd}

          . The problem with doing that from the admin web interface is:

          1. Solr has already started and bound to a port by then so reconfiguring from the UI is a bit difficult
          2. We don't have enough people contributing to the admin UI sadly so contributions are hard to come by. That being said, we have a new committer (Upayavira) who is working on improving the UI these days, so there's still hope
          Show
          shalinmangar Shalin Shekhar Mangar added a comment - SSL should be enabled by default. I disagree. We have the option. People who need it can use them. We also have kerberos support so you can use that too along with SSL if you're really paranoid about security. It's all well and good to say that users shouldn't do things, but they're being done, and the code needs to be written to account for real-world use, not some hypothetical ideal that doesn't exist. Yeah, which is why we are building some support for security. But enabling it by default requires a lot of education for new users. We need to balance between the two. Perhaps some of this can be done via documentation? For example, we can link to the guides on SSL/Kerberos/BasicAuth on the "Taking Solr to Production" page? https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production Also, I would love for Solr to just be exposed exclusively on my server's internal IP address(es)--but I have no idea how to do that. You can do that by setting the "SOLR_HOST" property to the internal hostname or IP address in solr.in. {sh,cmd} . The problem with doing that from the admin web interface is: Solr has already started and bound to a port by then so reconfiguring from the UI is a bit difficult We don't have enough people contributing to the admin UI sadly so contributions are hard to come by. That being said, we have a new committer (Upayavira) who is working on improving the UI these days, so there's still hope
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          As a slightly longer term goal, I believe this ticket does have merit, and given we have auth capabilities in Solr now, it makes sense to place the admin UI behind that.

          Upayavira, this already works if you enable Basic Auth via the new capabilities added by SOLR-7837

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - As a slightly longer term goal, I believe this ticket does have merit, and given we have auth capabilities in Solr now, it makes sense to place the admin UI behind that. Upayavira, this already works if you enable Basic Auth via the new capabilities added by SOLR-7837
          Hide
          elyograg Shawn Heisey added a comment -

          Regarding SSL on by default ... while this would provide some security out of the box, it annoys me when I try to connect to a web interface and I am immediately greeted by a security warning regarding a certificate that doesn't validate. An experienced user knows that it is safe to ignore that warning and proceed anyway, but a beginner may misinterpret what their browser is telling them, decide that Solr has security problems, and go looking for a different solution.

          I would rather present an insecure interface out of the box so that a new user can immediately see that their install is operational. I'd be OK with a warning box on every page telling the user that they should enable SSL, as long as it could be removed with a config change. Turning on SSL should be very easy for a novice to do. Another piece that must be straightforward is the installation of a custom certificate that the user might get from a public CA, and any required intermediate certificates.

          As already mentioned, we have a framework for authentication coming in 5.3. Once we are sure it's stable and effective, turning on authentication for the admin UI by default would be a good idea. The out-of-the-box credentials should be easy to locate on our website, in the first few pages of the documentation, and one or more of the .txt files included in the download.

          Show
          elyograg Shawn Heisey added a comment - Regarding SSL on by default ... while this would provide some security out of the box, it annoys me when I try to connect to a web interface and I am immediately greeted by a security warning regarding a certificate that doesn't validate. An experienced user knows that it is safe to ignore that warning and proceed anyway, but a beginner may misinterpret what their browser is telling them, decide that Solr has security problems, and go looking for a different solution. I would rather present an insecure interface out of the box so that a new user can immediately see that their install is operational. I'd be OK with a warning box on every page telling the user that they should enable SSL, as long as it could be removed with a config change. Turning on SSL should be very easy for a novice to do. Another piece that must be straightforward is the installation of a custom certificate that the user might get from a public CA, and any required intermediate certificates. As already mentioned, we have a framework for authentication coming in 5.3. Once we are sure it's stable and effective, turning on authentication for the admin UI by default would be a good idea. The out-of-the-box credentials should be easy to locate on our website, in the first few pages of the documentation, and one or more of the .txt files included in the download.
          Hide
          janhoy Jan Høydahl added a comment -

          I would rather present an insecure interface out of the box so that a new user can immediately see that their install is operational. I'd be OK with a warning box on every page telling the user that they should enable SSL, as long as it could be removed with a config change. Turning on SSL should be very easy for a novice to do.

          +1

          turning on authentication for the admin UI by default would be a good idea. The out-of-the-box credentials should be easy to locate on our website, in the first few pages of the documentation, and one or more of the .txt files included in the download.

          -0

          Perhaps not by default, it would make the simplest tutorial unnecessary complicated. And it would only work for cloud anyway. How about adding some warnings to Admin UI in cloud mode if authentication is not enabled and another warning if it is enabled with ootb passwords. And we could add an -auth flag to /bin/solr -e cloud to optionally start the cloud example with basic auth enabled...

          Show
          janhoy Jan Høydahl added a comment - I would rather present an insecure interface out of the box so that a new user can immediately see that their install is operational. I'd be OK with a warning box on every page telling the user that they should enable SSL, as long as it could be removed with a config change. Turning on SSL should be very easy for a novice to do. +1 turning on authentication for the admin UI by default would be a good idea. The out-of-the-box credentials should be easy to locate on our website, in the first few pages of the documentation, and one or more of the .txt files included in the download. -0 Perhaps not by default, it would make the simplest tutorial unnecessary complicated. And it would only work for cloud anyway. How about adding some warnings to Admin UI in cloud mode if authentication is not enabled and another warning if it is enabled with ootb passwords. And we could add an -auth flag to /bin/solr -e cloud to optionally start the cloud example with basic auth enabled...
          Hide
          grossws Konstantin Gribov added a comment -

          My point on enabling/disabling SSL by default is that Solr is often behind firewall and near to back-end which use it, they are both in some kind of private network, so TLS will be cpu, network and management overhead for such cases. I believe that it's primary use case and exposed Solr installations are rare.

          Also, requiring admin UI auth seems to be a good idea only at first glance.

          Under the cover it will require non-trivial role model to separate user actions and admin actions on all available handlers (like discussed in SOLR-7838) which heavy depends on configured handlers and use case: sometimes update is normal action for user and delete by id is not, sometimes delete by id should be allowed, but delete by query shouldn't etc.

          Another potential issue with self-made security framework is creating high quality security modules. If some of them may be created and distributed with Solr, so pass some QA by Solr committers, third party modules can have lesser quality and affect overall Solr experience. Buggy or just slow third party security filter will lead to bad user experience. Credentials and authN/authZ rules caching and synchronization are other hard-to-implement-correctly part, especially in distributed environment.

          Since role to user mapping is non-trivial and authN/authZ is hard to configure, security setup as standard Solr installation step would be frightening for many users. I think, it should be optional for users, who want or have to use such security model.

          Show
          grossws Konstantin Gribov added a comment - My point on enabling/disabling SSL by default is that Solr is often behind firewall and near to back-end which use it, they are both in some kind of private network, so TLS will be cpu, network and management overhead for such cases. I believe that it's primary use case and exposed Solr installations are rare. Also, requiring admin UI auth seems to be a good idea only at first glance. Under the cover it will require non-trivial role model to separate user actions and admin actions on all available handlers (like discussed in SOLR-7838 ) which heavy depends on configured handlers and use case: sometimes update is normal action for user and delete by id is not, sometimes delete by id should be allowed, but delete by query shouldn't etc. Another potential issue with self-made security framework is creating high quality security modules. If some of them may be created and distributed with Solr, so pass some QA by Solr committers, third party modules can have lesser quality and affect overall Solr experience. Buggy or just slow third party security filter will lead to bad user experience. Credentials and authN/authZ rules caching and synchronization are other hard-to-implement-correctly part, especially in distributed environment. Since role to user mapping is non-trivial and authN/authZ is hard to configure, security setup as standard Solr installation step would be frightening for many users. I think, it should be optional for users, who want or have to use such security model.
          Hide
          janhoy Jan Høydahl added a comment -

          Changed title and description to reflect that this is a new feature request about adding a login screen to the Admin UI, as the Basic Authentication plugin already supports the very simplest way of requiring a user/pass for all of Solr.

          Some initial text by Aaron Greenspan was removed from the issue description to keep it short and concise. Pasting it here for reference:

          Apparently there are ways of configuring Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced Linux admin and a programmer; I've tried, numerous times, and I've not once been able to get it to work. The point is this, though:

          No one should have to try to get their Solr instance to support password authentication and preferably SSL (even if it's just with a self-signed certificate). Solr is designed to store huge amounts of data and is therefore a likely target for malicious users.

          This needs to be addressed! It's 2015 and Solr is on version 5!

          Show
          janhoy Jan Høydahl added a comment - Changed title and description to reflect that this is a new feature request about adding a login screen to the Admin UI, as the Basic Authentication plugin already supports the very simplest way of requiring a user/pass for all of Solr. Some initial text by Aaron Greenspan was removed from the issue description to keep it short and concise. Pasting it here for reference: Apparently there are ways of configuring Jetty to do this with HTTP AUTH or whatever. I'm a moderately experienced Linux admin and a programmer; I've tried, numerous times, and I've not once been able to get it to work. The point is this, though: No one should have to try to get their Solr instance to support password authentication and preferably SSL (even if it's just with a self-signed certificate). Solr is designed to store huge amounts of data and is therefore a likely target for malicious users. This needs to be addressed! It's 2015 and Solr is on version 5!
          Hide
          janhoy Jan Høydahl added a comment -

          Let's keep this issue focused on loggin in to the Admin UI..

          Some questions regarding a possible Solr Admin Login:

          • Should it be SolrCloud only?
          • Should it require an Authentication Plugin to be configured or be separate? Can the login screen support any and all Auth methods? How?
          • What about Single Sign on? Cookies?
            • If you log in to one Solr node, should we require another login if you navigate to another node?
          • If SSL is configured, can we treat SSL client certificate based auth as a valid login, independent of what AuthPlugin is configured?

          Once the Admin UI has a login, we have the framework for adapting the UI depending on what roles the logged-in user has, i.e. create collection etc, that would be a bunch of new JIRAs.

          Show
          janhoy Jan Høydahl added a comment - Let's keep this issue focused on loggin in to the Admin UI.. Some questions regarding a possible Solr Admin Login: Should it be SolrCloud only? Should it require an Authentication Plugin to be configured or be separate? Can the login screen support any and all Auth methods? How? What about Single Sign on? Cookies? If you log in to one Solr node, should we require another login if you navigate to another node? If SSL is configured, can we treat SSL client certificate based auth as a valid login, independent of what AuthPlugin is configured? Once the Admin UI has a login, we have the framework for adapting the UI depending on what roles the logged-in user has, i.e. create collection etc, that would be a bunch of new JIRAs.
          Hide
          janhoy Jan Høydahl added a comment -

          Guess we could use this AngularJS module https://github.com/sahat/satellizer for the frontend. It uses JWT
          On the Solr end we'd need to add e.g. /auth/login/ endpoint to validate the login.
          On the Admin UI end we'd need to add the login controller and a login screen/dialogue.
          Guess we'd also need to add some kind of TokenAuthenticationPlugin which validates the Authorization: Bearer <token> header much in the same way that we have a special path to validate the SolrAuth header for PKI auth. This fellow could also take care of Single Sign on (to support user browsing away to another solr node) by securely asking the original Solr node if the token is valid.
          Further, the Admin UI will on first load make a request to Solr to ask wether login will be required, and if so, pop up the dialogue immediately.

          Do I miss anything here? Anyone who have experience in these things?
          How do the /auth/login endpoint validate a user login in case of Kerberos/Hadoop auth? Perhaps by forwarding user with OAuth2 to some other server in the network? I'm quite blank on this..

          Show
          janhoy Jan Høydahl added a comment - Guess we could use this AngularJS module https://github.com/sahat/satellizer for the frontend. It uses JWT On the Solr end we'd need to add e.g. /auth/login/ endpoint to validate the login. On the Admin UI end we'd need to add the login controller and a login screen/dialogue. Guess we'd also need to add some kind of TokenAuthenticationPlugin which validates the Authorization: Bearer <token> header much in the same way that we have a special path to validate the SolrAuth header for PKI auth. This fellow could also take care of Single Sign on (to support user browsing away to another solr node) by securely asking the original Solr node if the token is valid. Further, the Admin UI will on first load make a request to Solr to ask wether login will be required, and if so, pop up the dialogue immediately. Do I miss anything here? Anyone who have experience in these things? How do the /auth/login endpoint validate a user login in case of Kerberos/Hadoop auth? Perhaps by forwarding user with OAuth2 to some other server in the network? I'm quite blank on this..
          Hide
          arafalov Alexandre Rafalovitch added a comment -

          I think Satellizer is for 3rd party authentication. So, with user authenticating to Google/Twitter and Solr using that for internal access. That feels like a different thing from what I understand us having - which is basic authentication with passwords stored internally.

          Show
          arafalov Alexandre Rafalovitch added a comment - I think Satellizer is for 3rd party authentication. So, with user authenticating to Google/Twitter and Solr using that for internal access. That feels like a different thing from what I understand us having - which is basic authentication with passwords stored internally.
          Hide
          janhoy Jan Høydahl added a comment -

          Solr may be protected by any AuthPlugin, not only BasicAuth, so we need something that is future proof too. Of course if we limit this to only supporting BasicAuthPlugin we could let the UI add user:pass for all requests directly. However, I was hoping to have something generic. So for the BasicAuth case I think we could be using the email/password flow: https://github.com/sahat/satellizer#-login-with-email-and-password and let Solr backend validate the user/pass?

          Show
          janhoy Jan Høydahl added a comment - Solr may be protected by any AuthPlugin, not only BasicAuth, so we need something that is future proof too. Of course if we limit this to only supporting BasicAuthPlugin we could let the UI add user:pass for all requests directly. However, I was hoping to have something generic. So for the BasicAuth case I think we could be using the email/password flow: https://github.com/sahat/satellizer#-login-with-email-and-password and let Solr backend validate the user/pass?
          Hide
          elyograg Shawn Heisey added a comment -

          Been a while since I said anything on this issue. I have skimmed the newest comments, but haven't read them in-depth.

          For security on the admin UI, do we want basic authentication, or do we want to use a form-and-cookie approach like the vast majority of web applications? HTTP basic authentication is probably the only sane choice for the API, though.

          Enabling SSL out of the box still seems like a bad idea, and enabling authentication on the API by default also seems like a bad idea. Requiring authentication out of the box for the admin UI, probably with cookies, doesn't seem quite so insane, though. It might be the sort of thing where no password exists initially, but the first time you access the UI, it forces you to set one. In cloud mode, that would probably update zookeeper, affecting all Solr instances.

          What would be really nice to have is the ability to enable/disable and configure API authentication within the admin UI.

          Show
          elyograg Shawn Heisey added a comment - Been a while since I said anything on this issue. I have skimmed the newest comments, but haven't read them in-depth. For security on the admin UI, do we want basic authentication, or do we want to use a form-and-cookie approach like the vast majority of web applications? HTTP basic authentication is probably the only sane choice for the API, though. Enabling SSL out of the box still seems like a bad idea, and enabling authentication on the API by default also seems like a bad idea. Requiring authentication out of the box for the admin UI, probably with cookies, doesn't seem quite so insane, though. It might be the sort of thing where no password exists initially, but the first time you access the UI, it forces you to set one. In cloud mode, that would probably update zookeeper, affecting all Solr instances. What would be really nice to have is the ability to enable/disable and configure API authentication within the admin UI.

            People

            • Assignee:
              Unassigned
              Reporter:
              thinkcomp Aaron Greenspan
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:

                Development