[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13595705#comment-13595705
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
bq. as long as the patch keeps applying well for longer periods of time
But I guess it will not, because there are a fair amount of changes to existing
code, even though I am very eager to do "separation of concerns", and since
authentication is a separate concern I have tried to isolate as much as I can
in new separate classes like AuthCredentials and
InterSolrNodeAuthCredentialsFactory. But there are a fair amount of changes in
existing classes also
* 1) Of course the new classes needs to be used around the places in the code
where we actually do issue inter-solr-node requests. Unfortunately that is more
places than it ought to be, but not that many.
* 2) There are a lot of changes in tests inheriting from
BaseDistributedSearchTest, but they are all trivial - its just a matter of
applying credentials to many places where requests are sent
* 3) There is a two-big-blocks very well documented change in JettySolrServer
to have it support running with what I call "common security". This "common
security" is activated across all tests inheriting from
BaseDistributedSearchTest
* 4) There is also a fair amount of changes to HttpClientUtil, because I like
to isolate everything around credentials setup on HttpClient level in there
With respect to "applying well for longer periods of time" I am a little afraid
that 1), 2) and maybe 4) will not.
Please consider committing it. I will be around to help fix bugs if there are
any, but I am like 99% sure there are not (e.g. the test-suite is still green
and we are already using it intensively in our test and staging), and as long
as you do not turn on security (as you where not able to do before anyway) I am
like 99,9999% sure nothing is broke.
bq. Hmm, it took some trial & error before I understood why tests failed, then
I saw this comment and changed my java.policy file. But how can this be better
integrated with Ant so that patching java.policy for all your JDKs is not a
requirement for passing Lucene/Solr tests? I think such a requirement may be a
no-starter.
It might be a no-start, yes. But I only experienced this on my local Mac
development machine. Our CI buildagents (plain Ubuntu server 12.04 LTS with
plain Oracle java6 installed) had no problem, so I think this might just be a
problem out-of-the-box on "normal peoples" machines, because most OS (at last
OSX does) force a tighter security policy for java than server installations
does. If this is just a problem on "developer machines" and it just runs
out-of-the-box on your Jenkins CI machines, I believe it will be OK to just
"write our way out of problems" on a "how to setup your development
environment" Wiki page.
The java security model with policy file is based on the fact that you have
(probably as root) to do modify to the policy file to change permissions. I
believe you can point out an alternative policy file while starting the JVM,
but once started the java code itself cannot change the permissions. I guess
using an alternative policy file (from SVN) is an option.
It is also an option, and probably the easiest one, to write a small realm
ourselves that do not use JAAS javax.security.auth.AuthPermission stuff behind
the scenes.
bq. Is it an alternative to simply modify Jetty's xml file instead of doing it
through API?
I do not think so. I believe jetty.xml is read by the Jetty JVM after startup,
and that permissions cannot be changes at that point in time, but it is a long
time since I looked at how start.jar works, but if it reads jetty.xml and
starts another JVM bases on information in there it might be possible. But we
do not use jetty.xml in JettySolrRunner and I do not think we should change
that just to deal with this issue. It is also important that we do not make the
"fix" in something that will apply when using the code "for real", because it
such case I believe it is important the Solr do not change the java permissions
behind the scenes. If a concrete installation of Solr wants to use a realm,
which requires changes to the java policy it is important that the admins of
this installation actually have to deal with it manually. Remember this is just
a problem because of properties of the realm we happen to use for testing.
bq. Regarding the use of "|" as separator in RegExpAuthorizationFilter. Will it
work with regexes containing "|"?
First of all, have a look at the description of RegExpAuthorizationFilter here:
http://wiki.apache.org/solr/SolrSecurity#Security_in_Solr_on_per-operation_basis
Yes it will work with |'s in the reg-exps. I deliberately put the reg-exp last
in the |-separated list of things. "order" is a number and cannot ever contain
a |. Roles will not be allowed to contain a |, and you will have to be very
sick if you choose a role-name containing |, so that is not a problem either.
With those observations I can just do the split this way
* order is the part before the first |
* roles is the part inbetween the first and the second |
* reg-exp is "the rest" and can contain |'s
bq. Or would it be more readable (and cool) in these JSON-times to use a small
object as param-value? Then we could keep the base object syntax for any future
Filter implementations.
It would be ok for me to change the syntax into JSON, or maybe support both,
but that ought to be another improvement-jira. RegExpAuthorizationFilter is
primarily made for test-purposes, even though I put it in the non-test code,
because people actually might want to use it "for real" - we will actually do
that in my project. It is working the way it is, and if people actually start
using it for real and want a "cooler" syntax inside the configuration
init-params then make it an improvement-jira.
bq. By adding a parameter to the utiliy methods without leaving the old
signature in place, you break back-compat with people using the old signature
Ups, I actually intended only to add "new" signatures with AuthCredentials
included, but I guess I didnt do it right for "add". That can easily be
corrected.
bq. We should either ADD the new methods or simply skip adding this to
convenience signatures. Users wanting auth can do so with the other (more
elaborate) technique, they do not need a convenience method for auth
I tried to get the community opinion on this issue here:
https://issues.apache.org/jira/browse/SOLR-4470?focusedCommentId=13582144&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13582144
But there wasnt much feedback, so I needed to make a decision myself
I agree that it would be fine if AuthCredentials where not supported by those
convenience-methods on SolrServer. Primarily I added them because those methods
are used a lot from testing-code where I want to provide credentials, and if I
did not add the support for credentials in those methods, changes to the
testing-code would be much bigger and definitely harder to accept for a
committer. Now the changes to testing-code is fairly easy to grasp, because
everything is "the same as before", just with credentials added.
bq. One can argue that commitWithin is something most users want to / should
use while auth will be more of a a corner case
Agree
> Support for basic http auth in internal solr requests
> -----------------------------------------------------
>
> Key: SOLR-4470
> URL: https://issues.apache.org/jira/browse/SOLR-4470
> Project: Solr
> Issue Type: New Feature
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Labels: authentication, https, solrclient, solrcloud, ssl
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470.patch
>
>
> We want to protect any HTTP-resource (url). We want to require credentials no
> matter what kind of HTTP-request you make to a Solr-node.
> It can faily easy be acheived as described on
> http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes
> also make "internal" request to other Solr-nodes, and for it to work
> credentials need to be provided here also.
> Ideally we would like to "forward" credentials from a particular request to
> all the "internal" sub-requests it triggers. E.g. for search and update
> request.
> But there are also "internal" requests
> * that only indirectly/asynchronously triggered from "outside" requests (e.g.
> shard creation/deletion/etc based on calls to the "Collection API")
> * that do not in any way have relation to an "outside" "super"-request (e.g.
> replica synching stuff)
> We would like to aim at a solution where "original" credentials are
> "forwarded" when a request directly/synchronously trigger a subrequest, and
> fallback to a configured "internal credentials" for the
> asynchronous/non-rooted requests.
> In our solution we would aim at only supporting basic http auth, but we would
> like to make a "framework" around it, so that not to much refactoring is
> needed if you later want to make support for other kinds of auth (e.g. digest)
> We will work at a solution but create this JIRA issue early in order to get
> input/comments from the community as early as possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
