lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <j...@apache.org>
Subject [jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
Date Thu, 07 Mar 2013 00:26:13 GMT

    [ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13595347#comment-13595347
] 

Jan Høydahl commented on SOLR-4470:
-----------------------------------

bq. I removed the solr.xml thing again because we not are going to use it and it would just
make the patch even bigger (and we would not like that  ). 
Agree, keep it simple and iterate from there

I tried to apply the patch to trunk and there were not as many mismatches as I thought. So
although I created a branch https://svn.apache.org/repos/asf/lucene/dev/branches/security/
we may not need to use it before we feel the need for it, as long as the patch keeps applying
well for longer periods of time. Will attach trunk patch as SOLR-4470.patch

bq. Regarding running the test-suite: If not already granted in your policy file you need
to grant "permission javax.security.auth.AuthPermission "*";" in general or at least for the
JettySolrRunner (or the anonymous MappedLoginService in JettySolrRunner). This permission
is needed in order to be able to set up the LoginModule in JettySolrRunner (test-only)

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. Is it an alternative to simply modify Jetty's
xml file instead of doing it through API?

Regarding the use of "|" as separator in RegExpAuthorizationFilter
{code:xml}
  <init-param>
    <param-name>search-constraint</param-name>
    <param-value>1|update-role,admin-role|^.*/update$</param-value>
  </init-param>
{code}

Will it work with regexes containing "|"? 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.
{noformat}
    {"order": 1, "roles": ["update-role","admin-role"], "regex": "^.*/update$"}
{noformat}
                
> 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: Bug
>          Components: clients - java, multicore, replication (java), SolrCloud
>    Affects Versions: 4.0
>            Reporter: Per Steffensen
>              Labels: authentication, solrclient, solrcloud
>             Fix For: 4.2
>
>         Attachments: SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message