[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
