[
https://issues.apache.org/jira/browse/SOLR-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383624#comment-14383624
]
Per Steffensen commented on SOLR-7236:
--------------------------------------
I am trying to understand why Solr wants to move away from being a web-app
running in a servlet-container. A servlet-container can deal with all of the
things you mention in a standardized way
bq. User management (flat file, AD/LDAP etc)
That should really not be a Solr-concern. If you want your users/credentials in
LDAP manage it through an LDAP management-interface, if you want them in flat
files, let the admin change the files, etc
bq. Authentication (Admin UI, Admin and data/query operations. Tons of auth
protocols: basic, digest, oauth, pki..)
Implement your own realm authenticating against whatever credentials-store you
want with whatever protocol you want - and plug it into your servlet-container.
Or use a 3party realm that authenticates against your preferred
credentials-store and supporting your auth protocol. It is easy to find realms
for Jetty (or Tomcat or ...) authenticating against flat files, LDAP or
whatever. We wrote our own realm, authenticating against credentials-store in
ZK - easy.
bq. Authorization (who can do what with what API, collection, doc)
Let your realm list roles that an authenticated user is allowed to play. Setup
web.xml mapping roles to the url-paths they are allowed use. If limited
flexibility (url-mapping with stupid limitations) of web.xml authentication is
not good enough for you, implement it as a Filter yourself, or use some of the
Filters already out there. E.g. I provided a reg-exp authorization filter with
SOLR-4470 - it is very powerful.
bq. Pluggability (no user's needs are equal)
It is all pluggable - realms, web.xml, filters etc
> Securing Solr (umbrella issue)
> ------------------------------
>
> Key: SOLR-7236
> URL: https://issues.apache.org/jira/browse/SOLR-7236
> Project: Solr
> Issue Type: New Feature
> Reporter: Jan Høydahl
> Labels: Security
>
> This is an umbrella issue for adding security to Solr. The discussion here
> should discuss real user needs and high-level strategy, before deciding on
> implementation details. All work will be done in sub tasks and linked issues.
> Solr has not traditionally concerned itself with security. And It has been a
> general view among the committers that it may be better to stay out of it to
> avoid "blood on our hands" in this mine-field. Still, Solr has lately seen
> SSL support, securing of ZK, and signing of jars, and discussions have begun
> about securing operations in Solr.
> Some of the topics to address are
> * User management (flat file, AD/LDAP etc)
> * Authentication (Admin UI, Admin and data/query operations. Tons of auth
> protocols: basic, digest, oauth, pki..)
> * Authorization (who can do what with what API, collection, doc)
> * Pluggability (no user's needs are equal)
> * And we could go on and on but this is what we've seen the most demand for
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
