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 <jan....@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 <u...@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 <u...@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 <u...@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 <u...@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, 马柏樟 <mabaizh...@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
