You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by 马柏樟 <ma...@126.com> on 2015/11/10 02:38:16 UTC
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...."
Re: Security Problems
Posted by Shawn Heisey <ap...@elyograg.org>.
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
Posted by Upayavira <uv...@odoko.co.uk>.
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
Posted by Vijay Mhaskar - 2 <nu...@gmail.com>.
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
Posted by Erik Hatcher <er...@gmail.com>.
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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Anshum Gupta <an...@anshumgupta.net>.
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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Don Bosco Durai <bo...@apache.org>.
>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" <uv...@odoko.co.uk> 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 missed anything.
>>
>>
>> Bosco
>>
>>
>>
>>
>> On 11/20/15, 2:27 PM, "Jan Høydahl" <ja...@cominvent.com> 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
Posted by Upayavira <uv...@odoko.co.uk>.
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" <ja...@cominvent.com> 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
Posted by Don Bosco Durai <bo...@apache.org>.
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" <ja...@cominvent.com> 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
Posted by Upayavira <uv...@odoko.co.uk>.
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 <no...@gmail.com>:
> >
> > ". 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 <ja...@cominvent.com> 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
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <no...@gmail.com>:
>
> 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 <ja...@cominvent.com> 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 <no...@gmail.com>:
>>>
>>> ". 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 <ja...@cominvent.com> 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
Posted by Noble Paul <no...@gmail.com>.
I have opened https://issues.apache.org/jira/browse/SOLR-8429
On Wed, Dec 16, 2015 at 9:32 PM, Noble Paul <no...@gmail.com> 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 <ja...@cominvent.com> 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 <no...@gmail.com>:
>>>
>>> ". 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 <ja...@cominvent.com> 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
Posted by Noble Paul <no...@gmail.com>.
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 <ja...@cominvent.com> 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 <no...@gmail.com>:
>>
>> ". 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 <ja...@cominvent.com> 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
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <no...@gmail.com>:
>
> ". 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 <ja...@cominvent.com> 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
Posted by Noble Paul <no...@gmail.com>.
". 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 <ja...@cominvent.com> 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
Posted by Jan Høydahl <ja...@cominvent.com>.
> 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
Posted by Noble Paul <no...@gmail.com>.
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 <ja...@cominvent.com> 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
Posted by Jan Høydahl <ja...@cominvent.com>.
> 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
Posted by Byzen Ma <ma...@126.com>.
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.com@lucene.apache.org [mailto:solr-user-return-118173-mabaizhang=126.com@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.com@lucene.apache.org [mailto:solr-user-return-118135-mabaizhang=126.com@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 <ja...@cominvent.com> 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 <uv...@odoko.co.uk>:
>>
>> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
答复: Security Problems
Posted by Byzen Ma <ma...@126.com>.
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.com@lucene.apache.org [mailto:solr-user-return-118135-mabaizhang=126.com@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 <ja...@cominvent.com> 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 <uv...@odoko.co.uk>:
>>
>> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Noble Paul <no...@gmail.com>.
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 <ja...@cominvent.com> 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 <uv...@odoko.co.uk>:
>>
>> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <uv...@odoko.co.uk>:
>
> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Upayavira <uv...@odoko.co.uk>.
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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Noble Paul <no...@gmail.com>.
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 <ja...@cominvent.com> 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 <no...@gmail.com>:
>>
>> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <no...@gmail.com>:
>
> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Noble Paul <no...@gmail.com>.
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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Upayavira <uv...@odoko.co.uk>.
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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Noble Paul <no...@gmail.com>.
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 <uv...@odoko.co.uk> 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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Upayavira <uv...@odoko.co.uk>.
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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Anshum Gupta <an...@anshumgupta.net>.
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 <uv...@odoko.co.uk> 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, 马柏樟 <ma...@126.com> 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
Posted by Upayavira <uv...@odoko.co.uk>.
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, 马柏樟 <ma...@126.com> 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
Posted by Noble Paul <no...@gmail.com>.
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, 马柏樟 <ma...@126.com> 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