Re: Security Problems

Anyone cannot just go "INSERT foo INTO bar” on a random MySql server in the data room, so why should Solr be less secure once Auth is enabled? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 16. des. 2015 kl. 17.02 skrev Noble Paul : > > I

Re: Security Problems

I have opened https://issues.apache.org/jira/browse/SOLR-8429 On Wed, Dec 16, 2015 at 9:32 PM, Noble Paul wrote: > I don't this behavior is intuitive. It is very easy to misunderstand > > I would rather just add a flag to "authentication" plugin section > which says

Re: Security Problems

I don't this behavior is intuitive. It is very easy to misunderstand I would rather just add a flag to "authentication" plugin section which says "blockUnauthenticated" : true which means all unauthenticated requests must be blocked. On Tue, Dec 15, 2015 at 7:09 PM, Jan Høydahl

Re: Security Problems

Yes, that’s why I believe it should be: 1) if only authentication is enabled, all users must authenticate and all authenticated users can do anything. 2) if authz is enabled, then all users must still authenticate, and can by default do nothing at all, unless assigned proper roles 3) if a user

Re: Security Problems

I concur - this makes sense. On Tue, Dec 15, 2015, at 01:39 PM, Jan Høydahl wrote: > Yes, that’s why I believe it should be: > 1) if only authentication is enabled, all users must authenticate and all > authenticated users can do anything. > 2) if authz is enabled, then all users must still

Re: Security Problems

> 1) "read" should cover all the paths This is very fragile. If all paths were closed by default, forgetting to configure a path would not result in a security breach like today. /Jan

Re: Security Problems

". 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

Re: Security Problems

This could have multiple solutions 1) "read" should cover all the paths 2) system properties are a strict NO . This can be strictly a property of the Authentication plugin. So , you can use the API to modify the property. On Sat, Nov 21, 2015 at 3:57 AM, Jan Høydahl

Re: Security Problems

Don, You seem to be suggesting that the UI be broken down into components that can be authorised independently. For example, a user who is allowed to query, but not to update, should not have access to UI elements (such as documents in its current incarnation) that allow updating. This is taking

Re: Security Problems

>You seem to be suggesting that the UI be broken down into components that can >be authorised independently. Yes, this is what I was mostly concerned of. It doesn’t apply much with today’s Admin UI though... >For myself, right now, I'm just keen to see that if authentication is required >for

Re: Security Problems

In traditional web interface application, the URLs can be configured as public->authenticated->authorized. Which is very similar to what you are suggesting. >I tried out BasicAuthPlugin today. Surprised that not admin UI is protected. My suggestion would be to differentiate between Web

Re: Security Problems

> ideally we should have a simple permission name called "all" (which we > don't have) > > so that one rule should be enough > > "name":"all", > "role":"somerole" > > Open a ticket and we should fix it for 5.4.0 > It should also include the admin paths as well Yes, that would be convenient.

Re: Security Problems

Would it not be less surprising if ALL requests to Solr required authentication once an AuthenticationPlugin was enabled? Then, if no AuthorizationPlugin was active, all authenticated users could do anything. But if AuthorizationPlugin was configured, you could only do what your role allows you

答复: Security Problems

e happy red cramming on my Admin Logging UI! -邮件原件- 发件人: solr-user-return-118135-mabaizhang=126@lucene.apache.org [mailto:solr-user-return-118135-mabaizhang=126@lucene.apache.org] 代表 Noble Paul 发送时间: 2015年11月20日 1:40 收件人: solr-user@lucene.apache.org 主题: Re: Security Problems What is the smalle

答复: Security Problems

r-user-return-118173-mabaizhang=126@lucene.apache.org] 代表 Byzen Ma 发送时间: 2015年11月20日 13:26 收件人: solr-user@lucene.apache.org 主题: 答复: Security Problems Thanks for the reply. The two smallest rules 1) "name":"all-admin", "collection": null, "path":"/*&

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":"/*"

Re: Security Problems

Everything requires explicit rules, if you wish to protect "/update/*" create a permission with name "update" and assign a role for the same. If you don't have an explicit rule, those paths are accessible by all On Wed, Nov 18, 2015 at 8:10 PM, Jan Høydahl wrote: > I tried

Re: Security Problems

I'm very happy for the admin UI to be served another way - i.e. not direct from Jetty, if that makes the task of securing it easier. Perhaps a request handler specifically for UI resources which would make it possible to secure it all in a more straight-forward way? Upayavira On Wed, Nov 18,

Re: Security Problems

Not sure I quite understand. You're saying that the cost for the UI is not large, but then suggesting we protect just one resource (/admin/security-check)? Why couldn't we create the permission called 'admin-ui' and protect everything under /admin/ui/ for example? Along with the root HTML link

Re: Security Problems

As of now the admin-ui calls are not protected. The static calls are served by jetty and it bypasses the authentication mechanism completely. If the admin UI relies on some API call which is served by Solr. The other option is to revamp the framework to take care of admin UI (static content) as

Re: Security Problems

I tried out BasicAuthPlugin today. Surprised that not admin UI is protected. But even more surprised that only /select seems to be protected for not logged in users. I can create collections and /update documents without being prompted for pw. My security.json is

Re: Security Problems

The authentication plugin is not expensive if you are talking in the context of admin UI. After all it is used not like 100s of requests per second. The simplest solution would be provide a well known permission name called "admin-ui" ensure that every admin page load makes a call to some

Re: Security Problems

On 11/9/2015 6:38 PM, 马柏樟 wrote: > After I configure Authentication with Basic Authentication Plugin and > Authorization with Rule-Based Authorization Plugin, How can I prevent the > strangers from visiting my solr by browser? For example, if the stranger > visit the http://(my host):8983, the

Re: Security Problems

Noble, I get that a UI which is open source does not benefit from ACL control - we're not giving away anything that isn't public (other than perhaps info that could be used to identify the version of Solr, or even the fact that it *is* solr). However, from a user experience point of view,

Re: Security Problems

The reason why we bypass that is so that we don't hit the authentication plugin for every request that comes in for static content. I think we could call the authentication plugin for that but that'd be an overkill. Better experience ? yes On Tue, Nov 10, 2015 at 11:24 AM, Upayavira

Re: Security Problems

It has a cost :) I think it'd make sense to restrict access to /admin and not really bother about .css/js etc. So if a user tries to access an image from the image from the admin UI directly, the request would go through but that should be fine. On Tue, Nov 10, 2015 at 12:22 PM, Upayavira

Re: Security Problems

Front it with request handler(s) and get security for free :) (top level not cite specific it'd have to be) > On Nov 10, 2015, at 14:24, Upayavira wrote: > > Noble, > > I get that a UI which is open source does not benefit from ACL control - > we're not giving away anything

Re: Security Problems

Is the authentication plugin that expensive? I can help by minifying the UI down to a smaller number of CSS/JS/etc files :-) It may be overkill, but it would also give better experience. And isn't that what most applications do? Check authentication tokens on every request? Upayavira On Tue,

Re: Security Problems

n 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

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

The admin UI is a bunch of static pages . We don't let the ACL control static content you must blacklist all the core/collection apis and it is pretty much useless for anyone to access the admin UI (w/o the credentials , of course) On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote:

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