Re: Security Problems
Anyone cannot just go "INSERT foo INTO bar” on a random MySql server in the data room, so why should Solr be less secure once Auth is enabled? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 16. des. 2015 kl. 17.02 skrev Noble Paul : > > I don't this behavior is intuitive. It is very easy to misunderstand > > I would rather just add a flag to "authentication" plugin section > which says "blockUnauthenticated" : true > > which means all unauthenticated requests must be blocked. > > > > > On Tue, Dec 15, 2015 at 7:09 PM, Jan Høydahl wrote: >> Yes, that’s why I believe it should be: >> 1) if only authentication is enabled, all users must authenticate and all >> authenticated users can do anything. >> 2) if authz is enabled, then all users must still authenticate, and can by >> default do nothing at all, unless assigned proper roles >> 3) if a user is assigned the default “read” rule, and a collection adds a >> custom “/myselect” handler, that one is unavailable until the user gets it >> assigned >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >>> 14. des. 2015 kl. 14.15 skrev Noble Paul : >>> >>> ". If all paths were closed by default, forgetting to configure a path >>> would not result in a security breach like today." >>> >>> But it will still mean that unauthorized users are able to access, >>> like guest being able to post to "/update". Just authenticating is not >>> enough without proper authorization >>> >>> On Mon, Dec 14, 2015 at 3:59 PM, Jan Høydahl wrote: > 1) "read" should cover all the paths This is very fragile. If all paths were closed by default, forgetting to configure a path would not result in a security breach like today. /Jan >>> >>> >>> >>> -- >>> - >>> Noble Paul >> > > > > -- > - > Noble Paul
Re: Security Problems
I have opened https://issues.apache.org/jira/browse/SOLR-8429 On Wed, Dec 16, 2015 at 9:32 PM, Noble Paul wrote: > I don't this behavior is intuitive. It is very easy to misunderstand > > I would rather just add a flag to "authentication" plugin section > which says "blockUnauthenticated" : true > > which means all unauthenticated requests must be blocked. > > > > > On Tue, Dec 15, 2015 at 7:09 PM, Jan Høydahl wrote: >> Yes, that’s why I believe it should be: >> 1) if only authentication is enabled, all users must authenticate and all >> authenticated users can do anything. >> 2) if authz is enabled, then all users must still authenticate, and can by >> default do nothing at all, unless assigned proper roles >> 3) if a user is assigned the default “read” rule, and a collection adds a >> custom “/myselect” handler, that one is unavailable until the user gets it >> assigned >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >>> 14. des. 2015 kl. 14.15 skrev Noble Paul : >>> >>> ". If all paths were closed by default, forgetting to configure a path >>> would not result in a security breach like today." >>> >>> But it will still mean that unauthorized users are able to access, >>> like guest being able to post to "/update". Just authenticating is not >>> enough without proper authorization >>> >>> On Mon, Dec 14, 2015 at 3:59 PM, Jan Høydahl wrote: > 1) "read" should cover all the paths This is very fragile. If all paths were closed by default, forgetting to configure a path would not result in a security breach like today. /Jan >>> >>> >>> >>> -- >>> - >>> Noble Paul >> > > > > -- > - > Noble Paul -- - Noble Paul
Re: Security Problems
I don't this behavior is intuitive. It is very easy to misunderstand I would rather just add a flag to "authentication" plugin section which says "blockUnauthenticated" : true which means all unauthenticated requests must be blocked. On Tue, Dec 15, 2015 at 7:09 PM, Jan Høydahl wrote: > Yes, that’s why I believe it should be: > 1) if only authentication is enabled, all users must authenticate and all > authenticated users can do anything. > 2) if authz is enabled, then all users must still authenticate, and can by > default do nothing at all, unless assigned proper roles > 3) if a user is assigned the default “read” rule, and a collection adds a > custom “/myselect” handler, that one is unavailable until the user gets it > assigned > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > >> 14. des. 2015 kl. 14.15 skrev Noble Paul : >> >> ". If all paths were closed by default, forgetting to configure a path >> would not result in a security breach like today." >> >> But it will still mean that unauthorized users are able to access, >> like guest being able to post to "/update". Just authenticating is not >> enough without proper authorization >> >> On Mon, Dec 14, 2015 at 3:59 PM, Jan Høydahl wrote: 1) "read" should cover all the paths >>> >>> This is very fragile. If all paths were closed by default, forgetting to >>> configure a path would not result in a security breach like today. >>> >>> /Jan >> >> >> >> -- >> - >> Noble Paul > -- - Noble Paul
Re: Security Problems
I concur - this makes sense. On Tue, Dec 15, 2015, at 01:39 PM, Jan Høydahl wrote: > Yes, that’s why I believe it should be: > 1) if only authentication is enabled, all users must authenticate and all > authenticated users can do anything. > 2) if authz is enabled, then all users must still authenticate, and can > by default do nothing at all, unless assigned proper roles > 3) if a user is assigned the default “read” rule, and a collection adds a > custom “/myselect” handler, that one is unavailable until the user gets > it assigned > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > > 14. des. 2015 kl. 14.15 skrev Noble Paul : > > > > ". If all paths were closed by default, forgetting to configure a path > > would not result in a security breach like today." > > > > But it will still mean that unauthorized users are able to access, > > like guest being able to post to "/update". Just authenticating is not > > enough without proper authorization > > > > On Mon, Dec 14, 2015 at 3:59 PM, Jan Høydahl wrote: > >>> 1) "read" should cover all the paths > >> > >> This is very fragile. If all paths were closed by default, forgetting to > >> configure a path would not result in a security breach like today. > >> > >> /Jan > > > > > > > > -- > > - > > Noble Paul >
Re: Security Problems
Yes, that’s why I believe it should be: 1) if only authentication is enabled, all users must authenticate and all authenticated users can do anything. 2) if authz is enabled, then all users must still authenticate, and can by default do nothing at all, unless assigned proper roles 3) if a user is assigned the default “read” rule, and a collection adds a custom “/myselect” handler, that one is unavailable until the user gets it assigned -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 14. des. 2015 kl. 14.15 skrev Noble Paul : > > ". If all paths were closed by default, forgetting to configure a path > would not result in a security breach like today." > > But it will still mean that unauthorized users are able to access, > like guest being able to post to "/update". Just authenticating is not > enough without proper authorization > > On Mon, Dec 14, 2015 at 3:59 PM, Jan Høydahl wrote: >>> 1) "read" should cover all the paths >> >> This is very fragile. If all paths were closed by default, forgetting to >> configure a path would not result in a security breach like today. >> >> /Jan > > > > -- > - > Noble Paul
Re: Security Problems
". If all paths were closed by default, forgetting to configure a path would not result in a security breach like today." But it will still mean that unauthorized users are able to access, like guest being able to post to "/update". Just authenticating is not enough without proper authorization On Mon, Dec 14, 2015 at 3:59 PM, Jan Høydahl wrote: >> 1) "read" should cover all the paths > > This is very fragile. If all paths were closed by default, forgetting to > configure a path would not result in a security breach like today. > > /Jan -- - Noble Paul
Re: Security Problems
> 1) "read" should cover all the paths This is very fragile. If all paths were closed by default, forgetting to configure a path would not result in a security breach like today. /Jan
Re: Security Problems
This could have multiple solutions 1) "read" should cover all the paths 2) system properties are a strict NO . This can be strictly a property of the Authentication plugin. So , you can use the API to modify the property. On Sat, Nov 21, 2015 at 3:57 AM, Jan Høydahl wrote: >> ideally we should have a simple permission name called "all" (which we >> don't have) >> >> so that one rule should be enough >> >> "name":"all", >> "role":"somerole" >> >> Open a ticket and we should fix it for 5.4.0 >> It should also include the admin paths as well > > Yes, that would be convenient. > > I still don’t like the existing "open-by-default” security mode of Solr. It > is very fragile to mis-configuration without people noticing. Take the > well-known permission “read” for instance. It protects /select and /get. But > it won’t protect /query, /browse, /export, /spell, /suggest, /tvrh, /terms, > /clustering or /elevate, all which also expose sensitive info. > > How about allowing to choose between three different security modes? > > -Dsolr.security.mode=open : As today - paths not configured are wide > open > -Dsolr.security.mode=authenticated : Paths not configured are open to any > authenticated user > -Dsolr.security.mode=explicit : Paths not configured are closed to all. > All acccess is explicitly configured > > /Jan -- - Noble Paul
Re: Security Problems
>You seem to be suggesting that the UI be broken down into components that can >be authorised independently. Yes, this is what I was mostly concerned of. It doesn’t apply much with today’s Admin UI though... >For myself, right now, I'm just keen to see that if authentication is required >for Solr, then authentication will be required for the UI too. I agree with you, if it is just authentication for the current admin UI and if authentication is enabled, then we should just authenticate all requests. Because in HTTP, authentication is just done once and the session cookie is used for subsequent requests. So this is an extremely low (no cost) operation. When I tested Solr with Kerberos, that is how it was already working. If you don’t have not done “knit” on your local machine, you can’t access any page. If you are done kinit, then you can access the pages, but most of the stuff will not work, because you don’t make the call to get the required data. So, if you can the person the permission for action “sol_admin”, then everything should work. I have not tested BASIC auth implementation yet. So can’t speak for it. But the underlying design/implementation should be the same. Unless something changed from when I originally tested just before 5.2 was released. Bosco On 11/22/15, 12:45 PM, "Upayavira" wrote: >Don, > >You seem to be suggesting that the UI be broken down into components >that can be authorised independently. For example, a user who is allowed >to query, but not to update, should not have access to UI elements (such >as documents in its current incarnation) that allow updating. This is >taking the UI further than I had considered, in this regard. > >For myself, right now, I'm just keen to see that if authentication is >required for Solr, then authentication will be required for the UI too. > >My suggestion to put the UI within a request handler or such was to >facilitate the authentication framework interacting with it, e.g. having >an admin-ui (or just a UI) role covering the whole UI. More >sophisticated UIs are, for sure, possible, but I for one haven't thought >that far yet. > >Upayavira > >On Sat, Nov 21, 2015, at 09:42 PM, Don Bosco Durai wrote: >> In traditional web interface application, the URLs can be configured as >> public->authenticated->authorized. Which is very similar to what you are >> suggesting. >> >> >I tried out BasicAuthPlugin today. Surprised that not admin UI is protected. >> My suggestion would be to differentiate between Web Interface and HTTP >> API interfaces. Because trying to solve both using the same design will >> not be very easy and even if you do it, it will be management nightmare. >> >> >> >> >I'm very happy for the admin UI to be served another way - i.e. Not direct >> >from Jetty, if that makes the task of securing it easier. >> >> Do you see a richer Solr UI? My understanding on talking with Anshum >> (offline) was that the Solr Admin UI was only for Admin Users. So >> technically you need to have “all” permission to access the Solr Admin >> UI. Which I think is a fair point. >> >> If we are planning to give an alternate UI. Then your point is valid and >> it gives more framework options to choose from. Traditional web >> interfaces mostly deal with static pages and servlet/REST requests to get >> data from the server. Frameworks like Spring give a lot of control how >> you want to configure these URLs. I know we are trying to get out of >> Jetty and Tomcat. But frameworks like Spring make life a lot easier when >> you are dealing with Web Interfaces. It can also support different >> authentication schemes for WebUI. I feel, instead of reinventing the >> wheel here, we should consider some framework which will give Web >> Interface level access control and authentication. >> >> >> For the APIs (/select, /query, etc…), I feel, the current design is >> pretty flexible. Of course, we should make sure all access path are >> controlled and easy to manage. >> >> >Take the well-known permission “read” for instance. It protects /select and >> >/get. But it won’t protect /query, /browse, /export, /spell, /suggest, >> >/tvrh, /terms, /clustering or /elevate, all which also expose sensitive >> >info. >> >> Apache Ranger does one of the implementation for the Solr authorizer >> interface. In 5.2, we supported the following actions: >> public static final String ACCESS_TYPE_CREATE = "create"; >> public static final String ACCESS_TYPE_UPDATE = "update"; >> public static final String ACCESS_TYPE_QUERY = "query"; >> public static final String ACCESS_TYPE_OTHERS = "others"; >> public static final String ACCESS_TYPE_ADMIN = "solr_admin"; >> >> My assumptions was that the other actions will map to one of these. E.g. >> /suggest will map to “query” and “/export” will map to “solr_admin”. My >> assumptions might be incorrect. But we mapped all unknown/non-standard >> actions to “others”. I will review the code to see if I
Re: Security Problems
Don, You seem to be suggesting that the UI be broken down into components that can be authorised independently. For example, a user who is allowed to query, but not to update, should not have access to UI elements (such as documents in its current incarnation) that allow updating. This is taking the UI further than I had considered, in this regard. For myself, right now, I'm just keen to see that if authentication is required for Solr, then authentication will be required for the UI too. My suggestion to put the UI within a request handler or such was to facilitate the authentication framework interacting with it, e.g. having an admin-ui (or just a UI) role covering the whole UI. More sophisticated UIs are, for sure, possible, but I for one haven't thought that far yet. Upayavira On Sat, Nov 21, 2015, at 09:42 PM, Don Bosco Durai wrote: > In traditional web interface application, the URLs can be configured as > public->authenticated->authorized. Which is very similar to what you are > suggesting. > > >I tried out BasicAuthPlugin today. Surprised that not admin UI is protected. > My suggestion would be to differentiate between Web Interface and HTTP > API interfaces. Because trying to solve both using the same design will > not be very easy and even if you do it, it will be management nightmare. > > > > >I'm very happy for the admin UI to be served another way - i.e. Not direct > >from Jetty, if that makes the task of securing it easier. > > Do you see a richer Solr UI? My understanding on talking with Anshum > (offline) was that the Solr Admin UI was only for Admin Users. So > technically you need to have “all” permission to access the Solr Admin > UI. Which I think is a fair point. > > If we are planning to give an alternate UI. Then your point is valid and > it gives more framework options to choose from. Traditional web > interfaces mostly deal with static pages and servlet/REST requests to get > data from the server. Frameworks like Spring give a lot of control how > you want to configure these URLs. I know we are trying to get out of > Jetty and Tomcat. But frameworks like Spring make life a lot easier when > you are dealing with Web Interfaces. It can also support different > authentication schemes for WebUI. I feel, instead of reinventing the > wheel here, we should consider some framework which will give Web > Interface level access control and authentication. > > > For the APIs (/select, /query, etc…), I feel, the current design is > pretty flexible. Of course, we should make sure all access path are > controlled and easy to manage. > > >Take the well-known permission “read” for instance. It protects /select and > >/get. But it won’t protect /query, /browse, /export, /spell, /suggest, > >/tvrh, /terms, /clustering or /elevate, all which also expose sensitive info. > > Apache Ranger does one of the implementation for the Solr authorizer > interface. In 5.2, we supported the following actions: > public static final String ACCESS_TYPE_CREATE = "create"; > public static final String ACCESS_TYPE_UPDATE = "update"; > public static final String ACCESS_TYPE_QUERY = "query"; > public static final String ACCESS_TYPE_OTHERS = "others"; > public static final String ACCESS_TYPE_ADMIN = "solr_admin"; > > My assumptions was that the other actions will map to one of these. E.g. > /suggest will map to “query” and “/export” will map to “solr_admin”. My > assumptions might be incorrect. But we mapped all unknown/non-standard > actions to “others”. I will review the code to see if I missed anything. > > > Bosco > > > > > On 11/20/15, 2:27 PM, "Jan Høydahl" wrote: > > >> ideally we should have a simple permission name called "all" (which we > >> don't have) > >> > >> so that one rule should be enough > >> > >> "name":"all", > >> "role":"somerole" > >> > >> Open a ticket and we should fix it for 5.4.0 > >> It should also include the admin paths as well > > > >Yes, that would be convenient. > > > >I still don’t like the existing "open-by-default” security mode of Solr. It > >is very fragile to mis-configuration without people noticing. Take the > >well-known permission “read” for instance. It protects /select and /get. But > >it won’t protect /query, /browse, /export, /spell, /suggest, /tvrh, /terms, > >/clustering or /elevate, all which also expose sensitive info. > > > >How about allowing to choose between three different security modes? > > > >-Dsolr.security.mode=open : As today - paths not configured are > >wide open > >-Dsolr.security.mode=authenticated : Paths not configured are open to any > >authenticated user > >-Dsolr.security.mode=explicit : Paths not configured are closed to all. > >All acccess is explicitly configured > > > >/Jan >
Re: Security Problems
In traditional web interface application, the URLs can be configured as public->authenticated->authorized. Which is very similar to what you are suggesting. >I tried out BasicAuthPlugin today. Surprised that not admin UI is protected. My suggestion would be to differentiate between Web Interface and HTTP API interfaces. Because trying to solve both using the same design will not be very easy and even if you do it, it will be management nightmare. >I'm very happy for the admin UI to be served another way - i.e. Not direct >from Jetty, if that makes the task of securing it easier. Do you see a richer Solr UI? My understanding on talking with Anshum (offline) was that the Solr Admin UI was only for Admin Users. So technically you need to have “all” permission to access the Solr Admin UI. Which I think is a fair point. If we are planning to give an alternate UI. Then your point is valid and it gives more framework options to choose from. Traditional web interfaces mostly deal with static pages and servlet/REST requests to get data from the server. Frameworks like Spring give a lot of control how you want to configure these URLs. I know we are trying to get out of Jetty and Tomcat. But frameworks like Spring make life a lot easier when you are dealing with Web Interfaces. It can also support different authentication schemes for WebUI. I feel, instead of reinventing the wheel here, we should consider some framework which will give Web Interface level access control and authentication. For the APIs (/select, /query, etc…), I feel, the current design is pretty flexible. Of course, we should make sure all access path are controlled and easy to manage. >Take the well-known permission “read” for instance. It protects /select and >/get. But it won’t protect /query, /browse, /export, /spell, /suggest, /tvrh, >/terms, /clustering or /elevate, all which also expose sensitive info. Apache Ranger does one of the implementation for the Solr authorizer interface. In 5.2, we supported the following actions: public static final String ACCESS_TYPE_CREATE = "create"; public static final String ACCESS_TYPE_UPDATE = "update"; public static final String ACCESS_TYPE_QUERY = "query"; public static final String ACCESS_TYPE_OTHERS = "others"; public static final String ACCESS_TYPE_ADMIN = "solr_admin"; My assumptions was that the other actions will map to one of these. E.g. /suggest will map to “query” and “/export” will map to “solr_admin”. My assumptions might be incorrect. But we mapped all unknown/non-standard actions to “others”. I will review the code to see if I missed anything. Bosco On 11/20/15, 2:27 PM, "Jan Høydahl" wrote: >> ideally we should have a simple permission name called "all" (which we >> don't have) >> >> so that one rule should be enough >> >> "name":"all", >> "role":"somerole" >> >> Open a ticket and we should fix it for 5.4.0 >> It should also include the admin paths as well > >Yes, that would be convenient. > >I still don’t like the existing "open-by-default” security mode of Solr. It is >very fragile to mis-configuration without people noticing. Take the well-known >permission “read” for instance. It protects /select and /get. But it won’t >protect /query, /browse, /export, /spell, /suggest, /tvrh, /terms, /clustering >or /elevate, all which also expose sensitive info. > >How about allowing to choose between three different security modes? > >-Dsolr.security.mode=open : As today - paths not configured are wide >open >-Dsolr.security.mode=authenticated : Paths not configured are open to any >authenticated user >-Dsolr.security.mode=explicit : Paths not configured are closed to all. >All acccess is explicitly configured > >/Jan
Re: Security Problems
> ideally we should have a simple permission name called "all" (which we > don't have) > > so that one rule should be enough > > "name":"all", > "role":"somerole" > > Open a ticket and we should fix it for 5.4.0 > It should also include the admin paths as well Yes, that would be convenient. I still don’t like the existing "open-by-default” security mode of Solr. It is very fragile to mis-configuration without people noticing. Take the well-known permission “read” for instance. It protects /select and /get. But it won’t protect /query, /browse, /export, /spell, /suggest, /tvrh, /terms, /clustering or /elevate, all which also expose sensitive info. How about allowing to choose between three different security modes? -Dsolr.security.mode=open : As today - paths not configured are wide open -Dsolr.security.mode=authenticated : Paths not configured are open to any authenticated user -Dsolr.security.mode=explicit : Paths not configured are closed to all. All acccess is explicitly configured /Jan
答复: Security Problems
Apology for I did't read thread " replica recovery " carefully. It may be another problem. But the thread " Implementing security.json is breaking ADDREPLICA " is same as me. -邮件原件- 发件人: solr-user-return-118173-mabaizhang=126@lucene.apache.org [mailto:solr-user-return-118173-mabaizhang=126@lucene.apache.org] 代表 Byzen Ma 发送时间: 2015年11月20日 13:26 收件人: solr-user@lucene.apache.org 主题: 答复: Security Problems Thanks for the reply. The two smallest rules 1) "name":"all-admin", "collection": null, "path":"/*" "role:"somerole" 2) all core handlers "name":"all-core-handlers", "path":"/*" "role":"somerole" do work after I reset my security.json. But another magic things happened. After I accidentally just set the rule as : "name":"admin-all" "role":"admin" It still works well and I even need permission to Admin UI. Perfect for me but why? I am a inexperience solr user and can't figure out it, but I want to know why it works? And another error happens as thread "replica recovery" describe. The RecoveryStrategy on main server attempt to recover replica again and again maybe last forever. Now I can see happy red cramming on my Admin Logging UI! -邮件原件- 发件人: solr-user-return-118135-mabaizhang=126@lucene.apache.org [mailto:solr-user-return-118135-mabaizhang=126@lucene.apache.org] 代表 Noble Paul 发送时间: 2015年11月20日 1:40 收件人: solr-user@lucene.apache.org 主题: Re: Security Problems What is the smallest possible security.json required currently to protect all possible paths (except those served by Jetty)? You would need 2 rules 1) "name":"all-admin", "collection": null, "path":"/*" "role:"somerole" 2) all core handlers "name":"all-core-handlers", "path":"/*" "role":"somerole" ideally we should have a simple permission name called "all" (which we don't have) so that one rule should be enough "name":"all", "role":"somerole" Open a ticket and we should fix it for 5.4.0 It should also include the admin paths as well On Thu, Nov 19, 2015 at 6:02 PM, Jan Høydahl wrote: > Would it not be less surprising if ALL requests to Solr required > authentication once an AuthenticationPlugin was enabled? > Then, if no AuthorizationPlugin was active, all authenticated users could do > anything. > But if AuthorizationPlugin was configured, you could only do what your role > allows you to? > > As it is now it is super easy to forget a path, say you protect > /select but not /browse and /query, or someone creates a collection with some > new endpoints and forgets to update security.json - then that endpoint would > be wide open! > > What is the smallest possible security.json required currently to protect all > possible paths (except those served by Jetty)? > > -- > Jan Høydahl, search solution architect Cominvent AS - > www.cominvent.com > >> 18. nov. 2015 kl. 20.31 skrev Upayavira : >> >> I'm very happy for the admin UI to be served another way - i.e. not >> direct from Jetty, if that makes the task of securing it easier. >> >> Perhaps a request handler specifically for UI resources which would >> make it possible to secure it all in a more straight-forward way? >> >> Upayavira >> >> On Wed, Nov 18, 2015, at 01:54 PM, Noble Paul wrote: >>> As of now the admin-ui calls are not protected. The static calls are >>> served by jetty and it bypasses the authentication mechanism >>> completely. If the admin UI relies on some API call which is served >>> by Solr. >>> The other option is to revamp the framework to take care of admin UI >>> (static content) as well. This would be cleaner solution >>> >>> >>> On Wed, Nov 18, 2015 at 2:32 PM, Upayavira wrote: >>>> Not sure I quite understand. >>>> >>>> You're saying that the cost for the UI is not large, but then >>>> suggesting we protect just one resource (/admin/security-check)? >>>> >>>> Why couldn't we create the permission called 'admin-ui' and protect >>>> everything under /admin/ui/ for example? Along with the root HTML >>>> link too. >>>> >>>> Upayavira >>>> >>>> On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: >>>>> The authentication plugin is not expensive if you are talking in >>>>> the context of admin UI. After all it is used not l
答复: Security Problems
Thanks for the reply. The two smallest rules 1) "name":"all-admin", "collection": null, "path":"/*" "role:"somerole" 2) all core handlers "name":"all-core-handlers", "path":"/*" "role":"somerole" do work after I reset my security.json. But another magic things happened. After I accidentally just set the rule as : "name":"admin-all" "role":"admin" It still works well and I even need permission to Admin UI. Perfect for me but why? I am a inexperience solr user and can't figure out it, but I want to know why it works? And another error happens as thread "replica recovery" describe. The RecoveryStrategy on main server attempt to recover replica again and again maybe last forever. Now I can see happy red cramming on my Admin Logging UI! -邮件原件- 发件人: solr-user-return-118135-mabaizhang=126....@lucene.apache.org [mailto:solr-user-return-118135-mabaizhang=126@lucene.apache.org] 代表 Noble Paul 发送时间: 2015年11月20日 1:40 收件人: solr-user@lucene.apache.org 主题: Re: Security Problems What is the smallest possible security.json required currently to protect all possible paths (except those served by Jetty)? You would need 2 rules 1) "name":"all-admin", "collection": null, "path":"/*" "role:"somerole" 2) all core handlers "name":"all-core-handlers", "path":"/*" "role":"somerole" ideally we should have a simple permission name called "all" (which we don't have) so that one rule should be enough "name":"all", "role":"somerole" Open a ticket and we should fix it for 5.4.0 It should also include the admin paths as well On Thu, Nov 19, 2015 at 6:02 PM, Jan Høydahl wrote: > Would it not be less surprising if ALL requests to Solr required > authentication once an AuthenticationPlugin was enabled? > Then, if no AuthorizationPlugin was active, all authenticated users could do > anything. > But if AuthorizationPlugin was configured, you could only do what your role > allows you to? > > As it is now it is super easy to forget a path, say you protect > /select but not /browse and /query, or someone creates a collection with some > new endpoints and forgets to update security.json - then that endpoint would > be wide open! > > What is the smallest possible security.json required currently to protect all > possible paths (except those served by Jetty)? > > -- > Jan Høydahl, search solution architect Cominvent AS - > www.cominvent.com > >> 18. nov. 2015 kl. 20.31 skrev Upayavira : >> >> I'm very happy for the admin UI to be served another way - i.e. not >> direct from Jetty, if that makes the task of securing it easier. >> >> Perhaps a request handler specifically for UI resources which would >> make it possible to secure it all in a more straight-forward way? >> >> Upayavira >> >> On Wed, Nov 18, 2015, at 01:54 PM, Noble Paul wrote: >>> As of now the admin-ui calls are not protected. The static calls are >>> served by jetty and it bypasses the authentication mechanism >>> completely. If the admin UI relies on some API call which is served >>> by Solr. >>> The other option is to revamp the framework to take care of admin UI >>> (static content) as well. This would be cleaner solution >>> >>> >>> On Wed, Nov 18, 2015 at 2:32 PM, Upayavira wrote: >>>> Not sure I quite understand. >>>> >>>> You're saying that the cost for the UI is not large, but then >>>> suggesting we protect just one resource (/admin/security-check)? >>>> >>>> Why couldn't we create the permission called 'admin-ui' and protect >>>> everything under /admin/ui/ for example? Along with the root HTML >>>> link too. >>>> >>>> Upayavira >>>> >>>> On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: >>>>> The authentication plugin is not expensive if you are talking in >>>>> the context of admin UI. After all it is used not like 100s of >>>>> requests per second. >>>>> >>>>> The simplest solution would be >>>>> >>>>> provide a well known permission name called "admin-ui" >>>>> >>>>> ensure that every admin page load makes a call to some resource >>>>> say "/admin/security-check" >>>>> >>>>> Then we can jus
Re: Security Problems
What is the smallest possible security.json required currently to protect all possible paths (except those served by Jetty)? You would need 2 rules 1) "name":"all-admin", "collection": null, "path":"/*" "role:"somerole" 2) all core handlers "name":"all-core-handlers", "path":"/*" "role":"somerole" ideally we should have a simple permission name called "all" (which we don't have) so that one rule should be enough "name":"all", "role":"somerole" Open a ticket and we should fix it for 5.4.0 It should also include the admin paths as well On Thu, Nov 19, 2015 at 6:02 PM, Jan Høydahl wrote: > Would it not be less surprising if ALL requests to Solr required > authentication once an AuthenticationPlugin was enabled? > Then, if no AuthorizationPlugin was active, all authenticated users could do > anything. > But if AuthorizationPlugin was configured, you could only do what your role > allows you to? > > As it is now it is super easy to forget a path, say you protect /select but > not /browse and /query, or someone creates a collection > with some new endpoints and forgets to update security.json - then that > endpoint would be wide open! > > What is the smallest possible security.json required currently to protect all > possible paths (except those served by Jetty)? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > >> 18. nov. 2015 kl. 20.31 skrev Upayavira : >> >> I'm very happy for the admin UI to be served another way - i.e. not >> direct from Jetty, if that makes the task of securing it easier. >> >> Perhaps a request handler specifically for UI resources which would make >> it possible to secure it all in a more straight-forward way? >> >> Upayavira >> >> On Wed, Nov 18, 2015, at 01:54 PM, Noble Paul wrote: >>> As of now the admin-ui calls are not protected. The static calls are >>> served by jetty and it bypasses the authentication mechanism >>> completely. If the admin UI relies on some API call which is served by >>> Solr. >>> The other option is to revamp the framework to take care of admin UI >>> (static content) as well. This would be cleaner solution >>> >>> >>> On Wed, Nov 18, 2015 at 2:32 PM, Upayavira wrote: Not sure I quite understand. You're saying that the cost for the UI is not large, but then suggesting we protect just one resource (/admin/security-check)? Why couldn't we create the permission called 'admin-ui' and protect everything under /admin/ui/ for example? Along with the root HTML link too. Upayavira On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: > The authentication plugin is not expensive if you are talking in the > context of admin UI. After all it is used not like 100s of requests > per second. > > The simplest solution would be > > provide a well known permission name called "admin-ui" > > ensure that every admin page load makes a call to some resource say > "/admin/security-check" > > Then we can just protect that . > > The only concern thatI have is the false sense of security it would > give to the user > > But, that is a different point altogether > > On Wed, Nov 11, 2015 at 1:52 AM, Upayavira wrote: >> Is the authentication plugin that expensive? >> >> I can help by minifying the UI down to a smaller number of CSS/JS/etc >> files :-) >> >> It may be overkill, but it would also give better experience. And isn't >> that what most applications do? Check authentication tokens on every >> request? >> >> Upayavira >> >> On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: >>> The reason why we bypass that is so that we don't hit the authentication >>> plugin for every request that comes in for static content. I think we >>> could >>> call the authentication plugin for that but that'd be an overkill. >>> Better >>> experience ? yes >>> >>> On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: >>> Noble, I get that a UI which is open source does not benefit from ACL control - we're not giving away anything that isn't public (other than perhaps info that could be used to identify the version of Solr, or even the fact that it *is* solr). However, from a user experience point of view, requiring credentials to see the UI would be more conventional, and therefore lead to less confusion. Is it possible for us to protect the UI static files, only for the sake of user experience, rather than security? Upayavira On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: > The admin UI is a bunch of static pages . We don't let the ACL control > static content > > you must blacklist all the core/collection apis and it is pretty much > useless f
Re: Security Problems
Would it not be less surprising if ALL requests to Solr required authentication once an AuthenticationPlugin was enabled? Then, if no AuthorizationPlugin was active, all authenticated users could do anything. But if AuthorizationPlugin was configured, you could only do what your role allows you to? As it is now it is super easy to forget a path, say you protect /select but not /browse and /query, or someone creates a collection with some new endpoints and forgets to update security.json - then that endpoint would be wide open! What is the smallest possible security.json required currently to protect all possible paths (except those served by Jetty)? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 18. nov. 2015 kl. 20.31 skrev Upayavira : > > I'm very happy for the admin UI to be served another way - i.e. not > direct from Jetty, if that makes the task of securing it easier. > > Perhaps a request handler specifically for UI resources which would make > it possible to secure it all in a more straight-forward way? > > Upayavira > > On Wed, Nov 18, 2015, at 01:54 PM, Noble Paul wrote: >> As of now the admin-ui calls are not protected. The static calls are >> served by jetty and it bypasses the authentication mechanism >> completely. If the admin UI relies on some API call which is served by >> Solr. >> The other option is to revamp the framework to take care of admin UI >> (static content) as well. This would be cleaner solution >> >> >> On Wed, Nov 18, 2015 at 2:32 PM, Upayavira wrote: >>> Not sure I quite understand. >>> >>> You're saying that the cost for the UI is not large, but then suggesting >>> we protect just one resource (/admin/security-check)? >>> >>> Why couldn't we create the permission called 'admin-ui' and protect >>> everything under /admin/ui/ for example? Along with the root HTML link >>> too. >>> >>> Upayavira >>> >>> On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: The authentication plugin is not expensive if you are talking in the context of admin UI. After all it is used not like 100s of requests per second. The simplest solution would be provide a well known permission name called "admin-ui" ensure that every admin page load makes a call to some resource say "/admin/security-check" Then we can just protect that . The only concern thatI have is the false sense of security it would give to the user But, that is a different point altogether On Wed, Nov 11, 2015 at 1:52 AM, Upayavira wrote: > Is the authentication plugin that expensive? > > I can help by minifying the UI down to a smaller number of CSS/JS/etc > files :-) > > It may be overkill, but it would also give better experience. And isn't > that what most applications do? Check authentication tokens on every > request? > > Upayavira > > On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: >> The reason why we bypass that is so that we don't hit the authentication >> plugin for every request that comes in for static content. I think we >> could >> call the authentication plugin for that but that'd be an overkill. Better >> experience ? yes >> >> On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: >> >>> Noble, >>> >>> I get that a UI which is open source does not benefit from ACL control - >>> we're not giving away anything that isn't public (other than perhaps >>> info that could be used to identify the version of Solr, or even the >>> fact that it *is* solr). >>> >>> However, from a user experience point of view, requiring credentials to >>> see the UI would be more conventional, and therefore lead to less >>> confusion. Is it possible for us to protect the UI static files, only >>> for the sake of user experience, rather than security? >>> >>> Upayavira >>> >>> On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: The admin UI is a bunch of static pages . We don't let the ACL control static content you must blacklist all the core/collection apis and it is pretty much useless for anyone to access the admin UI (w/o the credentials , of course) On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: > Hi, > > After I configure Authentication with Basic Authentication Plugin and >>> Authorization with Rule-Based Authorization Plugin, How can I prevent >>> the >>> strangers from visiting my solr by browser? For example, if the stranger >>> visit the http://(my host):8983, the browser will pop up a window and >>> says "the server http://(my host):8983 requires a username and >>> password" -- - Noble Paul >>>
Re: Security Problems
I'm very happy for the admin UI to be served another way - i.e. not direct from Jetty, if that makes the task of securing it easier. Perhaps a request handler specifically for UI resources which would make it possible to secure it all in a more straight-forward way? Upayavira On Wed, Nov 18, 2015, at 01:54 PM, Noble Paul wrote: > As of now the admin-ui calls are not protected. The static calls are > served by jetty and it bypasses the authentication mechanism > completely. If the admin UI relies on some API call which is served by > Solr. > The other option is to revamp the framework to take care of admin UI > (static content) as well. This would be cleaner solution > > > On Wed, Nov 18, 2015 at 2:32 PM, Upayavira wrote: > > Not sure I quite understand. > > > > You're saying that the cost for the UI is not large, but then suggesting > > we protect just one resource (/admin/security-check)? > > > > Why couldn't we create the permission called 'admin-ui' and protect > > everything under /admin/ui/ for example? Along with the root HTML link > > too. > > > > Upayavira > > > > On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: > >> The authentication plugin is not expensive if you are talking in the > >> context of admin UI. After all it is used not like 100s of requests > >> per second. > >> > >> The simplest solution would be > >> > >> provide a well known permission name called "admin-ui" > >> > >> ensure that every admin page load makes a call to some resource say > >> "/admin/security-check" > >> > >> Then we can just protect that . > >> > >> The only concern thatI have is the false sense of security it would > >> give to the user > >> > >> But, that is a different point altogether > >> > >> On Wed, Nov 11, 2015 at 1:52 AM, Upayavira wrote: > >> > Is the authentication plugin that expensive? > >> > > >> > I can help by minifying the UI down to a smaller number of CSS/JS/etc > >> > files :-) > >> > > >> > It may be overkill, but it would also give better experience. And isn't > >> > that what most applications do? Check authentication tokens on every > >> > request? > >> > > >> > Upayavira > >> > > >> > On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: > >> >> The reason why we bypass that is so that we don't hit the authentication > >> >> plugin for every request that comes in for static content. I think we > >> >> could > >> >> call the authentication plugin for that but that'd be an overkill. > >> >> Better > >> >> experience ? yes > >> >> > >> >> On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: > >> >> > >> >> > Noble, > >> >> > > >> >> > I get that a UI which is open source does not benefit from ACL > >> >> > control - > >> >> > we're not giving away anything that isn't public (other than perhaps > >> >> > info that could be used to identify the version of Solr, or even the > >> >> > fact that it *is* solr). > >> >> > > >> >> > However, from a user experience point of view, requiring credentials > >> >> > to > >> >> > see the UI would be more conventional, and therefore lead to less > >> >> > confusion. Is it possible for us to protect the UI static files, only > >> >> > for the sake of user experience, rather than security? > >> >> > > >> >> > Upayavira > >> >> > > >> >> > On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: > >> >> > > The admin UI is a bunch of static pages . We don't let the ACL > >> >> > > control > >> >> > > static content > >> >> > > > >> >> > > you must blacklist all the core/collection apis and it is pretty > >> >> > > much > >> >> > > useless for anyone to access the admin UI (w/o the credentials , of > >> >> > > course) > >> >> > > > >> >> > > On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: > >> >> > > > Hi, > >> >> > > > > >> >> > > > After I configure Authentication with Basic Authentication Plugin > >> >> > > > and > >> >> > Authorization with Rule-Based Authorization Plugin, How can I prevent > >> >> > the > >> >> > strangers from visiting my solr by browser? For example, if the > >> >> > stranger > >> >> > visit the http://(my host):8983, the browser will pop up a window and > >> >> > says "the server http://(my host):8983 requires a username and > >> >> > password" > >> >> > > > >> >> > > > >> >> > > > >> >> > > -- > >> >> > > - > >> >> > > Noble Paul > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Anshum Gupta > >> > >> > >> > >> -- > >> - > >> Noble Paul > > > > -- > - > Noble Paul
Re: Security Problems
Everything requires explicit rules, if you wish to protect "/update/*" create a permission with name "update" and assign a role for the same. If you don't have an explicit rule, those paths are accessible by all On Wed, Nov 18, 2015 at 8:10 PM, Jan Høydahl wrote: > I tried out BasicAuthPlugin today. > Surprised that not admin UI is protected. > But even more surprised that only /select seems to be protected for not > logged in users. > I can create collections and /update documents without being prompted for pw. > > My security.json is https://gist.github.com/janhoy/d18854c75461816fb947 > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > >> 18. nov. 2015 kl. 14.54 skrev Noble Paul : >> >> As of now the admin-ui calls are not protected. The static calls are >> served by jetty and it bypasses the authentication mechanism >> completely. If the admin UI relies on some API call which is served by >> Solr. >> The other option is to revamp the framework to take care of admin UI >> (static content) as well. This would be cleaner solution >> >> >> On Wed, Nov 18, 2015 at 2:32 PM, Upayavira wrote: >>> Not sure I quite understand. >>> >>> You're saying that the cost for the UI is not large, but then suggesting >>> we protect just one resource (/admin/security-check)? >>> >>> Why couldn't we create the permission called 'admin-ui' and protect >>> everything under /admin/ui/ for example? Along with the root HTML link >>> too. >>> >>> Upayavira >>> >>> On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: The authentication plugin is not expensive if you are talking in the context of admin UI. After all it is used not like 100s of requests per second. The simplest solution would be provide a well known permission name called "admin-ui" ensure that every admin page load makes a call to some resource say "/admin/security-check" Then we can just protect that . The only concern thatI have is the false sense of security it would give to the user But, that is a different point altogether On Wed, Nov 11, 2015 at 1:52 AM, Upayavira wrote: > Is the authentication plugin that expensive? > > I can help by minifying the UI down to a smaller number of CSS/JS/etc > files :-) > > It may be overkill, but it would also give better experience. And isn't > that what most applications do? Check authentication tokens on every > request? > > Upayavira > > On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: >> The reason why we bypass that is so that we don't hit the authentication >> plugin for every request that comes in for static content. I think we >> could >> call the authentication plugin for that but that'd be an overkill. Better >> experience ? yes >> >> On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: >> >>> Noble, >>> >>> I get that a UI which is open source does not benefit from ACL control - >>> we're not giving away anything that isn't public (other than perhaps >>> info that could be used to identify the version of Solr, or even the >>> fact that it *is* solr). >>> >>> However, from a user experience point of view, requiring credentials to >>> see the UI would be more conventional, and therefore lead to less >>> confusion. Is it possible for us to protect the UI static files, only >>> for the sake of user experience, rather than security? >>> >>> Upayavira >>> >>> On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: The admin UI is a bunch of static pages . We don't let the ACL control static content you must blacklist all the core/collection apis and it is pretty much useless for anyone to access the admin UI (w/o the credentials , of course) On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: > Hi, > > After I configure Authentication with Basic Authentication Plugin and >>> Authorization with Rule-Based Authorization Plugin, How can I prevent >>> the >>> strangers from visiting my solr by browser? For example, if the stranger >>> visit the http://(my host):8983, the browser will pop up a window and >>> says "the server http://(my host):8983 requires a username and >>> password" -- - Noble Paul >>> >> >> >> >> -- >> Anshum Gupta -- - Noble Paul >> >> >> >> -- >> - >> Noble Paul > -- - Noble Paul
Re: Security Problems
I tried out BasicAuthPlugin today. Surprised that not admin UI is protected. But even more surprised that only /select seems to be protected for not logged in users. I can create collections and /update documents without being prompted for pw. My security.json is https://gist.github.com/janhoy/d18854c75461816fb947 -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 18. nov. 2015 kl. 14.54 skrev Noble Paul : > > As of now the admin-ui calls are not protected. The static calls are > served by jetty and it bypasses the authentication mechanism > completely. If the admin UI relies on some API call which is served by > Solr. > The other option is to revamp the framework to take care of admin UI > (static content) as well. This would be cleaner solution > > > On Wed, Nov 18, 2015 at 2:32 PM, Upayavira wrote: >> Not sure I quite understand. >> >> You're saying that the cost for the UI is not large, but then suggesting >> we protect just one resource (/admin/security-check)? >> >> Why couldn't we create the permission called 'admin-ui' and protect >> everything under /admin/ui/ for example? Along with the root HTML link >> too. >> >> Upayavira >> >> On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: >>> The authentication plugin is not expensive if you are talking in the >>> context of admin UI. After all it is used not like 100s of requests >>> per second. >>> >>> The simplest solution would be >>> >>> provide a well known permission name called "admin-ui" >>> >>> ensure that every admin page load makes a call to some resource say >>> "/admin/security-check" >>> >>> Then we can just protect that . >>> >>> The only concern thatI have is the false sense of security it would >>> give to the user >>> >>> But, that is a different point altogether >>> >>> On Wed, Nov 11, 2015 at 1:52 AM, Upayavira wrote: Is the authentication plugin that expensive? I can help by minifying the UI down to a smaller number of CSS/JS/etc files :-) It may be overkill, but it would also give better experience. And isn't that what most applications do? Check authentication tokens on every request? Upayavira On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: > The reason why we bypass that is so that we don't hit the authentication > plugin for every request that comes in for static content. I think we > could > call the authentication plugin for that but that'd be an overkill. Better > experience ? yes > > On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: > >> Noble, >> >> I get that a UI which is open source does not benefit from ACL control - >> we're not giving away anything that isn't public (other than perhaps >> info that could be used to identify the version of Solr, or even the >> fact that it *is* solr). >> >> However, from a user experience point of view, requiring credentials to >> see the UI would be more conventional, and therefore lead to less >> confusion. Is it possible for us to protect the UI static files, only >> for the sake of user experience, rather than security? >> >> Upayavira >> >> On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: >>> The admin UI is a bunch of static pages . We don't let the ACL control >>> static content >>> >>> you must blacklist all the core/collection apis and it is pretty much >>> useless for anyone to access the admin UI (w/o the credentials , of >>> course) >>> >>> On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: Hi, After I configure Authentication with Basic Authentication Plugin and >> Authorization with Rule-Based Authorization Plugin, How can I prevent the >> strangers from visiting my solr by browser? For example, if the stranger >> visit the http://(my host):8983, the browser will pop up a window and >> says "the server http://(my host):8983 requires a username and >> password" >>> >>> >>> >>> -- >>> - >>> Noble Paul >> > > > > -- > Anshum Gupta >>> >>> >>> >>> -- >>> - >>> Noble Paul > > > > -- > - > Noble Paul
Re: Security Problems
As of now the admin-ui calls are not protected. The static calls are served by jetty and it bypasses the authentication mechanism completely. If the admin UI relies on some API call which is served by Solr. The other option is to revamp the framework to take care of admin UI (static content) as well. This would be cleaner solution On Wed, Nov 18, 2015 at 2:32 PM, Upayavira wrote: > Not sure I quite understand. > > You're saying that the cost for the UI is not large, but then suggesting > we protect just one resource (/admin/security-check)? > > Why couldn't we create the permission called 'admin-ui' and protect > everything under /admin/ui/ for example? Along with the root HTML link > too. > > Upayavira > > On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: >> The authentication plugin is not expensive if you are talking in the >> context of admin UI. After all it is used not like 100s of requests >> per second. >> >> The simplest solution would be >> >> provide a well known permission name called "admin-ui" >> >> ensure that every admin page load makes a call to some resource say >> "/admin/security-check" >> >> Then we can just protect that . >> >> The only concern thatI have is the false sense of security it would >> give to the user >> >> But, that is a different point altogether >> >> On Wed, Nov 11, 2015 at 1:52 AM, Upayavira wrote: >> > Is the authentication plugin that expensive? >> > >> > I can help by minifying the UI down to a smaller number of CSS/JS/etc >> > files :-) >> > >> > It may be overkill, but it would also give better experience. And isn't >> > that what most applications do? Check authentication tokens on every >> > request? >> > >> > Upayavira >> > >> > On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: >> >> The reason why we bypass that is so that we don't hit the authentication >> >> plugin for every request that comes in for static content. I think we >> >> could >> >> call the authentication plugin for that but that'd be an overkill. Better >> >> experience ? yes >> >> >> >> On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: >> >> >> >> > Noble, >> >> > >> >> > I get that a UI which is open source does not benefit from ACL control - >> >> > we're not giving away anything that isn't public (other than perhaps >> >> > info that could be used to identify the version of Solr, or even the >> >> > fact that it *is* solr). >> >> > >> >> > However, from a user experience point of view, requiring credentials to >> >> > see the UI would be more conventional, and therefore lead to less >> >> > confusion. Is it possible for us to protect the UI static files, only >> >> > for the sake of user experience, rather than security? >> >> > >> >> > Upayavira >> >> > >> >> > On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: >> >> > > The admin UI is a bunch of static pages . We don't let the ACL control >> >> > > static content >> >> > > >> >> > > you must blacklist all the core/collection apis and it is pretty much >> >> > > useless for anyone to access the admin UI (w/o the credentials , of >> >> > > course) >> >> > > >> >> > > On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: >> >> > > > Hi, >> >> > > > >> >> > > > After I configure Authentication with Basic Authentication Plugin >> >> > > > and >> >> > Authorization with Rule-Based Authorization Plugin, How can I prevent >> >> > the >> >> > strangers from visiting my solr by browser? For example, if the stranger >> >> > visit the http://(my host):8983, the browser will pop up a window and >> >> > says "the server http://(my host):8983 requires a username and >> >> > password" >> >> > > >> >> > > >> >> > > >> >> > > -- >> >> > > - >> >> > > Noble Paul >> >> > >> >> >> >> >> >> >> >> -- >> >> Anshum Gupta >> >> >> >> -- >> - >> Noble Paul -- - Noble Paul
Re: Security Problems
Not sure I quite understand. You're saying that the cost for the UI is not large, but then suggesting we protect just one resource (/admin/security-check)? Why couldn't we create the permission called 'admin-ui' and protect everything under /admin/ui/ for example? Along with the root HTML link too. Upayavira On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote: > The authentication plugin is not expensive if you are talking in the > context of admin UI. After all it is used not like 100s of requests > per second. > > The simplest solution would be > > provide a well known permission name called "admin-ui" > > ensure that every admin page load makes a call to some resource say > "/admin/security-check" > > Then we can just protect that . > > The only concern thatI have is the false sense of security it would > give to the user > > But, that is a different point altogether > > On Wed, Nov 11, 2015 at 1:52 AM, Upayavira wrote: > > Is the authentication plugin that expensive? > > > > I can help by minifying the UI down to a smaller number of CSS/JS/etc > > files :-) > > > > It may be overkill, but it would also give better experience. And isn't > > that what most applications do? Check authentication tokens on every > > request? > > > > Upayavira > > > > On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: > >> The reason why we bypass that is so that we don't hit the authentication > >> plugin for every request that comes in for static content. I think we > >> could > >> call the authentication plugin for that but that'd be an overkill. Better > >> experience ? yes > >> > >> On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: > >> > >> > Noble, > >> > > >> > I get that a UI which is open source does not benefit from ACL control - > >> > we're not giving away anything that isn't public (other than perhaps > >> > info that could be used to identify the version of Solr, or even the > >> > fact that it *is* solr). > >> > > >> > However, from a user experience point of view, requiring credentials to > >> > see the UI would be more conventional, and therefore lead to less > >> > confusion. Is it possible for us to protect the UI static files, only > >> > for the sake of user experience, rather than security? > >> > > >> > Upayavira > >> > > >> > On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: > >> > > The admin UI is a bunch of static pages . We don't let the ACL control > >> > > static content > >> > > > >> > > you must blacklist all the core/collection apis and it is pretty much > >> > > useless for anyone to access the admin UI (w/o the credentials , of > >> > > course) > >> > > > >> > > On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: > >> > > > Hi, > >> > > > > >> > > > After I configure Authentication with Basic Authentication Plugin and > >> > Authorization with Rule-Based Authorization Plugin, How can I prevent the > >> > strangers from visiting my solr by browser? For example, if the stranger > >> > visit the http://(my host):8983, the browser will pop up a window and > >> > says "the server http://(my host):8983 requires a username and > >> > password" > >> > > > >> > > > >> > > > >> > > -- > >> > > - > >> > > Noble Paul > >> > > >> > >> > >> > >> -- > >> Anshum Gupta > > > > -- > - > Noble Paul
Re: Security Problems
The authentication plugin is not expensive if you are talking in the context of admin UI. After all it is used not like 100s of requests per second. The simplest solution would be provide a well known permission name called "admin-ui" ensure that every admin page load makes a call to some resource say "/admin/security-check" Then we can just protect that . The only concern thatI have is the false sense of security it would give to the user But, that is a different point altogether On Wed, Nov 11, 2015 at 1:52 AM, Upayavira wrote: > Is the authentication plugin that expensive? > > I can help by minifying the UI down to a smaller number of CSS/JS/etc > files :-) > > It may be overkill, but it would also give better experience. And isn't > that what most applications do? Check authentication tokens on every > request? > > Upayavira > > On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: >> The reason why we bypass that is so that we don't hit the authentication >> plugin for every request that comes in for static content. I think we >> could >> call the authentication plugin for that but that'd be an overkill. Better >> experience ? yes >> >> On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: >> >> > Noble, >> > >> > I get that a UI which is open source does not benefit from ACL control - >> > we're not giving away anything that isn't public (other than perhaps >> > info that could be used to identify the version of Solr, or even the >> > fact that it *is* solr). >> > >> > However, from a user experience point of view, requiring credentials to >> > see the UI would be more conventional, and therefore lead to less >> > confusion. Is it possible for us to protect the UI static files, only >> > for the sake of user experience, rather than security? >> > >> > Upayavira >> > >> > On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: >> > > The admin UI is a bunch of static pages . We don't let the ACL control >> > > static content >> > > >> > > you must blacklist all the core/collection apis and it is pretty much >> > > useless for anyone to access the admin UI (w/o the credentials , of >> > > course) >> > > >> > > On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: >> > > > Hi, >> > > > >> > > > After I configure Authentication with Basic Authentication Plugin and >> > Authorization with Rule-Based Authorization Plugin, How can I prevent the >> > strangers from visiting my solr by browser? For example, if the stranger >> > visit the http://(my host):8983, the browser will pop up a window and >> > says "the server http://(my host):8983 requires a username and >> > password" >> > > >> > > >> > > >> > > -- >> > > - >> > > Noble Paul >> > >> >> >> >> -- >> Anshum Gupta -- - Noble Paul
Re: Security Problems
It has a cost :) I think it'd make sense to restrict access to /admin and not really bother about .css/js etc. So if a user tries to access an image from the image from the admin UI directly, the request would go through but that should be fine. On Tue, Nov 10, 2015 at 12:22 PM, Upayavira wrote: > Is the authentication plugin that expensive? > > I can help by minifying the UI down to a smaller number of CSS/JS/etc > files :-) > > It may be overkill, but it would also give better experience. And isn't > that what most applications do? Check authentication tokens on every > request? > > Upayavira > > On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: > > The reason why we bypass that is so that we don't hit the authentication > > plugin for every request that comes in for static content. I think we > > could > > call the authentication plugin for that but that'd be an overkill. Better > > experience ? yes > > > > On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: > > > > > Noble, > > > > > > I get that a UI which is open source does not benefit from ACL control > - > > > we're not giving away anything that isn't public (other than perhaps > > > info that could be used to identify the version of Solr, or even the > > > fact that it *is* solr). > > > > > > However, from a user experience point of view, requiring credentials to > > > see the UI would be more conventional, and therefore lead to less > > > confusion. Is it possible for us to protect the UI static files, only > > > for the sake of user experience, rather than security? > > > > > > Upayavira > > > > > > On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: > > > > The admin UI is a bunch of static pages . We don't let the ACL > control > > > > static content > > > > > > > > you must blacklist all the core/collection apis and it is pretty much > > > > useless for anyone to access the admin UI (w/o the credentials , of > > > > course) > > > > > > > > On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: > > > > > Hi, > > > > > > > > > > After I configure Authentication with Basic Authentication Plugin > and > > > Authorization with Rule-Based Authorization Plugin, How can I prevent > the > > > strangers from visiting my solr by browser? For example, if the > stranger > > > visit the http://(my host):8983, the browser will pop up a window and > > > says "the server http://(my host):8983 requires a username and > > > password" > > > > > > > > > > > > > > > > -- > > > > - > > > > Noble Paul > > > > > > > > > > > -- > > Anshum Gupta > -- Anshum Gupta
Re: Security Problems
Is the authentication plugin that expensive? I can help by minifying the UI down to a smaller number of CSS/JS/etc files :-) It may be overkill, but it would also give better experience. And isn't that what most applications do? Check authentication tokens on every request? Upayavira On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote: > The reason why we bypass that is so that we don't hit the authentication > plugin for every request that comes in for static content. I think we > could > call the authentication plugin for that but that'd be an overkill. Better > experience ? yes > > On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: > > > Noble, > > > > I get that a UI which is open source does not benefit from ACL control - > > we're not giving away anything that isn't public (other than perhaps > > info that could be used to identify the version of Solr, or even the > > fact that it *is* solr). > > > > However, from a user experience point of view, requiring credentials to > > see the UI would be more conventional, and therefore lead to less > > confusion. Is it possible for us to protect the UI static files, only > > for the sake of user experience, rather than security? > > > > Upayavira > > > > On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: > > > The admin UI is a bunch of static pages . We don't let the ACL control > > > static content > > > > > > you must blacklist all the core/collection apis and it is pretty much > > > useless for anyone to access the admin UI (w/o the credentials , of > > > course) > > > > > > On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: > > > > Hi, > > > > > > > > After I configure Authentication with Basic Authentication Plugin and > > Authorization with Rule-Based Authorization Plugin, How can I prevent the > > strangers from visiting my solr by browser? For example, if the stranger > > visit the http://(my host):8983, the browser will pop up a window and > > says "the server http://(my host):8983 requires a username and > > password" > > > > > > > > > > > > -- > > > - > > > Noble Paul > > > > > > -- > Anshum Gupta
Re: Security Problems
Front it with request handler(s) and get security for free :) (top level not cite specific it'd have to be) > On Nov 10, 2015, at 14:24, Upayavira wrote: > > Noble, > > I get that a UI which is open source does not benefit from ACL control - > we're not giving away anything that isn't public (other than perhaps > info that could be used to identify the version of Solr, or even the > fact that it *is* solr). > > However, from a user experience point of view, requiring credentials to > see the UI would be more conventional, and therefore lead to less > confusion. Is it possible for us to protect the UI static files, only > for the sake of user experience, rather than security? > > Upayavira > >> On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: >> The admin UI is a bunch of static pages . We don't let the ACL control >> static content >> >> you must blacklist all the core/collection apis and it is pretty much >> useless for anyone to access the admin UI (w/o the credentials , of >> course) >> >>> On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: >>> Hi, >>> >>> After I configure Authentication with Basic Authentication Plugin and >>> Authorization with Rule-Based Authorization Plugin, How can I prevent the >>> strangers from visiting my solr by browser? For example, if the stranger >>> visit the http://(my host):8983, the browser will pop up a window and says >>> "the server http://(my host):8983 requires a username and password" >> >> >> >> -- >> - >> Noble Paul
Re: Security Problems
The reason why we bypass that is so that we don't hit the authentication plugin for every request that comes in for static content. I think we could call the authentication plugin for that but that'd be an overkill. Better experience ? yes On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote: > Noble, > > I get that a UI which is open source does not benefit from ACL control - > we're not giving away anything that isn't public (other than perhaps > info that could be used to identify the version of Solr, or even the > fact that it *is* solr). > > However, from a user experience point of view, requiring credentials to > see the UI would be more conventional, and therefore lead to less > confusion. Is it possible for us to protect the UI static files, only > for the sake of user experience, rather than security? > > Upayavira > > On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: > > The admin UI is a bunch of static pages . We don't let the ACL control > > static content > > > > you must blacklist all the core/collection apis and it is pretty much > > useless for anyone to access the admin UI (w/o the credentials , of > > course) > > > > On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: > > > Hi, > > > > > > After I configure Authentication with Basic Authentication Plugin and > Authorization with Rule-Based Authorization Plugin, How can I prevent the > strangers from visiting my solr by browser? For example, if the stranger > visit the http://(my host):8983, the browser will pop up a window and > says "the server http://(my host):8983 requires a username and > password" > > > > > > > > -- > > - > > Noble Paul > -- Anshum Gupta
Re: Security Problems
Noble, I get that a UI which is open source does not benefit from ACL control - we're not giving away anything that isn't public (other than perhaps info that could be used to identify the version of Solr, or even the fact that it *is* solr). However, from a user experience point of view, requiring credentials to see the UI would be more conventional, and therefore lead to less confusion. Is it possible for us to protect the UI static files, only for the sake of user experience, rather than security? Upayavira On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote: > The admin UI is a bunch of static pages . We don't let the ACL control > static content > > you must blacklist all the core/collection apis and it is pretty much > useless for anyone to access the admin UI (w/o the credentials , of > course) > > On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: > > Hi, > > > > After I configure Authentication with Basic Authentication Plugin and > > Authorization with Rule-Based Authorization Plugin, How can I prevent the > > strangers from visiting my solr by browser? For example, if the stranger > > visit the http://(my host):8983, the browser will pop up a window and says > > "the server http://(my host):8983 requires a username and password" > > > > -- > - > Noble Paul
Re: Security Problems
On 11/9/2015 6:38 PM, 马柏樟 wrote: > After I configure Authentication with Basic Authentication Plugin and > Authorization with Rule-Based Authorization Plugin, How can I prevent the > strangers from visiting my solr by browser? For example, if the stranger > visit the http://(my host):8983, the browser will pop up a window and says > "the server http://(my host):8983 requires a username and password" Don't expose Solr directly to the Internet or other end users, even with authentication. It's just a bad idea. The best security you can provide for Solr is to make sure it is only accessible by your client applications and trusted administrators. If you do this, you won't need any more security. With proper configuration, a proxy server can harden Solr so it is less open to attack, but it would likely still be vulnerable to denial of service queries. A proper proxy configuration would not be a trivial task. The authentication that Solr 5.3 provides will only protect the API endpoints that Solr exposes. It will *not* block access to the actual admin UI itself -- that is nothing but nearly static HTML, images, CSS, and javascript. The authentication does protect Solr, because the admin UI cannot do anything to Solr without accessing the API endpoints, which would need authentication. Thanks, Shawn
Re: Security Problems
The admin UI is a bunch of static pages . We don't let the ACL control static content you must blacklist all the core/collection apis and it is pretty much useless for anyone to access the admin UI (w/o the credentials , of course) On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote: > Hi, > > After I configure Authentication with Basic Authentication Plugin and > Authorization with Rule-Based Authorization Plugin, How can I prevent the > strangers from visiting my solr by browser? For example, if the stranger > visit the http://(my host):8983, the browser will pop up a window and says > "the server http://(my host):8983 requires a username and password" -- - Noble Paul
Re: Security Problems
Or, rather than touch Jetty, you could simply use iptables or such firewall as is provided by your operating system. Upayavira On Tue, Nov 10, 2015, at 08:08 AM, Vijay Mhaskar - 2 wrote: > Or you can try configuring IP based access control mechanism using > IPAccessHandler in jetty. I have configured this for our SolrCloud setup > and > it works very well. While configuring it for SolrCloud we need to be more > careful because Solr has lot of inter node communication happening during > distributed searching or indexing. > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Security-Problems-tp4239302p4239318.html > Sent from the Solr - User mailing list archive at Nabble.com.
Re: Security Problems
Or you can try configuring IP based access control mechanism using IPAccessHandler in jetty. I have configured this for our SolrCloud setup and it works very well. While configuring it for SolrCloud we need to be more careful because Solr has lot of inter node communication happening during distributed searching or indexing. -- View this message in context: http://lucene.472066.n3.nabble.com/Security-Problems-tp4239302p4239318.html Sent from the Solr - User mailing list archive at Nabble.com.
Security Problems
Hi, After I configure Authentication with Basic Authentication Plugin and Authorization with Rule-Based Authorization Plugin, How can I prevent the strangers from visiting my solr by browser? For example, if the stranger visit the http://(my host):8983, the browser will pop up a window and says "the server http://(my host):8983 requires a username and password"
