Anyone cannot just go "INSERT foo INTO bar” on a random MySql server in the
data room, so why should Solr be less secure once Auth is enabled?
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 16. des. 2015 kl. 17.02 skrev Noble Paul :
>
> I don't this behavior is int
I have opened https://issues.apache.org/jira/browse/SOLR-8429
On Wed, Dec 16, 2015 at 9:32 PM, Noble Paul wrote:
> I don't this behavior is intuitive. It is very easy to misunderstand
>
> I would rather just add a flag to "authentication" plugin section
> which says "blockUnauthenticated" : true
I don't this behavior is intuitive. It is very easy to misunderstand
I would rather just add a flag to "authentication" plugin section
which says "blockUnauthenticated" : true
which means all unauthenticated requests must be blocked.
On Tue, Dec 15, 2015 at 7:09 PM, Jan Høydahl wrote:
> Yes,
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 authen
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
". 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
O
> 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
This could have multiple solutions
1) "read" should cover all the paths
2) system properties are a strict NO . This can be strictly a property
of the Authentication plugin. So , you can use the API to modify the
property.
On Sat, Nov 21, 2015 at 3:57 AM, Jan Høydahl wrote:
>> ideally we should h
>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 S
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 t
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 Interfac
> 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
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":"somero
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
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, 201
Everything requires explicit rules, if you wish to protect "/update/*"
create a permission with name "update" and assign a role for the same.
If you don't have an explicit rule, those paths are accessible by all
On Wed, Nov 18, 2015 at 8:10 PM, Jan Høydahl wrote:
> I tried out BasicAuthPlugin tod
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/d1
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 wel
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
to
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 resour
It has a cost :)
I think it'd make sense to restrict access to /admin and not really bother
about .css/js etc. So if a user tries to access an image from the image
from the admin UI directly, the request would go through but that should be
fine.
On Tue, Nov 10, 2015 at 12:22 PM, Upayavira wrote:
Is the authentication plugin that expensive?
I can help by minifying the UI down to a smaller number of CSS/JS/etc
files :-)
It may be overkill, but it would also give better experience. And isn't
that what most applications do? Check authentication tokens on every
request?
Upayavira
On Tue, No
Front it with request handler(s) and get security for free :) (top level not
cite specific it'd have to be)
> On Nov 10, 2015, at 14:24, Upayavira wrote:
>
> Noble,
>
> I get that a UI which is open source does not benefit from ACL control -
> we're not giving away anything that isn't public (
The reason why we bypass that is so that we don't hit the authentication
plugin for every request that comes in for static content. I think we could
call the authentication plugin for that but that'd be an overkill. Better
experience ? yes
On Tue, Nov 10, 2015 at 11:24 AM, Upayavira wrote:
> Nob
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, requiri
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 b
The admin UI is a bunch of static pages . We don't let the ACL control
static content
you must blacklist all the core/collection apis and it is pretty much
useless for anyone to access the admin UI (w/o the credentials , of
course)
On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 wrote:
> Hi,
>
> After I co
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 config
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
distrib
29 matches
Mail list logo
