lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests
Date Tue, 19 Feb 2013 08:07:12 GMT

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

Per Steffensen edited comment on SOLR-4470 at 2/19/13 8:06 AM:
---------------------------------------------------------------

bq. Acording to HTTP-URL syntax, you can give the basic auth params using http://user:password@host:port/.
As Solr is using Commons-Httpsclient for connections, wouldnt this work automatically if you
configure the node's HTTP adress using this syntax?

This is a way to specify the credentials, yes. But it can be done in other ways and is already
done in other ways in the code - see HttpClientUtil.setBasicAuth (have to say that I am currently
looking at 4.0 code, but guess it hasnt changed). The problem is not so much setting the credentials
for the internal request, but to figure out which credentials to use.
As I described above I would like the credentials for requests issued by Solr-nodes themselves,
to be copied from the originals super-request in cases where such exist - e.g. for search
and update. For some of the requests that Solr-nodes issue themselves there are no such super-request
(e.g. for sync stuff) and for other requests the sub-requests are issued asynchronously from
its super-request (e.g. replica-creation-request are issued asynchronously from a create request
to the Collection API). For both such kind of request we need some credentials to include.
Thats where configuring "internal credentials" is needed.

If you where thinking about actually writing URLs like "http://user:password@host:port/" in
ZK, that is not going to work, since username/password is not (necessarily) static per target-node.
I want to "forward" whatever credentials are given in the super-request to the sub-requests
triggered synchronously by this super-requests (e.g. search and update) whereas "internal
credentials" will be used when there is no such super-request (sync stuff) or when there is
an asynchronous border between the super-request and the sub-requests (e.g. Collection API
operations). Besides that we plan to (later) go for HTTPS in order to encrypt the clear text
(or base64 encoded, but that can easily be decoded) username/password in the requests, and
I believe that the URL itself is not being encrypted in HTTPS.

Very concrete in our usage of Solr, we (for now) would like to have two users
* Admin-user which is allowed to do everything
* Search-user which is only allowed to search

We will configure solr-nodes with the "Admin-user credentials" as "internal credentials".
So they will be used for replica-creation and sync stuff. But "outside users" of our application
we only be given the Search-user credentials, and we want to make sure that they are not allowed
to do anything but search. It is not cool if a request made with the Search-user credentials
results in sub-requests with Admin-user credentials.

Hope it makes a little bit of sense, of else I hope it will when I provide some code. I will
post patch soon with early version of my work.
                
      was (Author: steff1193):
    bq. Acording to HTTP-URL syntax, you can give the basic auth params using http://user:password@host:port/.
As Solr is using Commons-Httpsclient for connections, wouldnt this work automatically if you
configure the node's HTTP adress using this syntax?

This is a way to specify the credentials, yes. But it can be done in other ways and is already
done in other ways in the code - see HttpClientUtil.setBasicAuth (have to say that I am currently
looking at 4.0 code, but guess it hasnt changed). The problem is not so much setting the credentials
for the internal request, but to figure out which credentials to use.
As I described above I would like the credentials for requests issued by Solr-nodes themselves,
to be copied from the originals super-request in cases where such exist - e.g. for search
and update. For some of the requests that Solr-nodes issue themselves there are no such super-request
(e.g. for sync stuff) and for other requests the sub-requests are issued asynchronously from
its super-request (e.g. replica-creation-request are issued asynchronously from a create request
to the Collection API). For both such kind of request we need some credentials to include.
Thats where configuring "internal credentials" is needed.

If you where thinking about actually writing URLs like "http://user:password@host:port/" in
ZK, that is not going to work, since username/password is not (necessarily) static per target-node.
I want to "forward" whatever credentials are given in the super-request to the sub-requests
triggered synchronously by this super-requests (e.g. search and update) whereas "internal
credentials" will be used when there is no such super-request (sync stuff) or when there is
an asynchronous border between the super-request and the sub-requests (e.g. Collection API
operations).

Very concrete in our usage of Solr, we (for now) would like to have two users
* Admin-user which is allowed to do everything
* Search-user which is only allowed to search

We will configure solr-nodes with the "Admin-user credentials" as "internal credentials".
So they will be used for replica-creation and sync stuff. But "outside users" of our application
we only be given the Search-user credentials, and we want to make sure that they are not allowed
to do anything but search. It is not cool if a request made with the Search-user credentials
results in sub-requests with Admin-user credentials.

Hope it makes a little bit of sense, of else I hope it will when I provide some code. I will
post patch soon with early version of my work.
                  
> 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
>
>
> 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