[jira] [Issue Comment Deleted] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Webster updated SOLR-4470: Comment: was deleted (was: We took advantage of the fact that SOLR is deployed to Tomcat. Tomcat, being the reference implementation of the servlet standard means you can use JAAS LoginModules, which essentially intercept the request stream before it even gets to the application layer, and exercise authtentication and provide authorization tokens for use in th) 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 Assignee: Jan Høydahl Labels: authentication, https, solrclient, solrcloud, ssl Fix For: 5.0 Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, SOLR-4470_trunk_r1568857.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 was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-4470) Support for basic http auth in internal solr requests
[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sea Marie updated SOLR-4470:
Comment: was deleted
(was: Hi,
I am running a simple two-node SolrCloud cluster with this patch (pulled from
Jan's GitHub and built from there) using the built-in ZooKeeper and Jetty.
I made a few small changes to the Jetty configs to restrict access via basic
auth on all SOLR resources. After rebooting with these changes, the SolrCore on
my second node is not coming up - it seems like the credentials are not being
used in the core recovery code, or not being passed to ZooKeeper, or something.
Have I missed some configuration step? Or am I confused and this scenario is
not supported by this patch?
h5. Changes I made in Jetty to enable basic auth:
h6. etc/webdefault.xml (perhaps protecting everything is overly general?):
{noformat}
security-constraint
web-resource-collection
web-resource-nameSolr authenticated application/web-resource-name
url-pattern//url-pattern
/web-resource-collection
auth-constraint
role-nameaccess-role/role-name
/auth-constraint
/security-constraint
login-config
auth-methodBASIC/auth-method
realm-nameAccess Realm/realm-name
/login-config
{noformat}
h6. etc/jetty.xml:
{noformat}
Call name=addBean
Arg
New class=org.eclipse.jetty.security.HashLoginService
Set name=nameAccess Realm/Set
Set name=configSystemProperty name=jetty.home
default=.//etc/realm.properties/Set
Set name=refreshInterval0/Set
/New
/Arg
/Call
{noformat}
h6. etc/realm.properties (redacted for obvious reasons :))
{noformat}
user: password, access-role
{noformat}
h5. Changes to SOLR-related things:
scripts/ctl.sh (on host2):
{noformat}
SOLR=$JAVABIN -Dbootstrap_confdir=$SOLR_HOME/collection1/conf
-Dcollection.configName=myconf -DzkRun -DzkHost=host1:9983
-Dsolr.solr.home=$SOLR_HOME -Djetty.logs=$INSTALL_PATH/logs/
-Djetty.home=$INSTALL_PATH/ -jar
-DinternalAuthCredentialsBasicAuthUsername=user
-DinternalAuthCredentialsBasicAuthPassword=password $INSTALL_PATH/start.jar
$INSTALL_PATH/etc/jetty.xml
{noformat}
(on host1, same as above w/o the -DzkHost param)
h5. The error I'm seeing (on host2, the second node, only. host1, the
leader is fine):
{noformat}
INFO - 2013-09-16 23:36:58.409;
org.apache.solr.client.solrj.impl.HttpClientUtil; Creating new http client,
config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
ERROR - 2013-09-16 23:36:58.433; org.apache.solr.common.SolrException; Error
while trying to recover.
core=collection1:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
Server at http://host1:8983/solr returned non ok status:401,
message:Unauthorized
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at
org.apache.solr.cloud.RecoveryStrategy.sendPrepRecoveryCmd(RecoveryStrategy.java:198)
at
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:342)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:219)
{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: New Feature
Components: clients - java, multicore, replication (java), SolrCloud
Affects Versions: 4.0
Reporter: Per Steffensen
Assignee: Jan Høydahl
Labels: authentication, https, solrclient, solrcloud, ssl
Fix For: 4.5, 5.0
Attachments: SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470.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
