Hi, Contributions of ne Authenitcation Plugins are surely welcome. Please open a JIRA issue to get started. You may also find this wiki page useful: http://wiki.apache.org/solr/HowToContribute
In general, it is preferred to communicate open and frequently with the community about a feature, rather than developing everything in-house and then dumping a huge patch. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 6. apr. 2016 kl. 16.46 skrev Davis, Daniel (NIH/NLM) [C] > <daniel.da...@nih.gov>: > > I'm bordering on development post, but I want to write an Authentication > Plugin that uses Proxy Authentication and a White List. > So, it will accept a request header such as REMOTE_USER as the username from > certain hosts, by default 127.0.0.1, ::1. > I also thought about having a whitelist of IPs that are assumed to be > "admin", to make the CLI more usable. > > -----Original Message----- > From: Jan Høydahl [mailto:jan....@cominvent.com] > Sent: Wednesday, April 06, 2016 4:18 AM > To: solr-user@lucene.apache.org > Subject: Re: BYOPW in security.json > > Hi > > Note that storing the user names and passwords in security.json is just one > implementation, to easily get started. It uses the > Sha256AuthenticationProvider class, which is pluggable. That means that if > you require Basic Auth with some form of self-service management, you > could/should add another AuthenticationProvider (implement interface > BasicAuthPlugin.AuthenticationProvider which e.g. pulls valid users and > passwords from a database or some other source that you control. Or perhaps > your organization uses LDAP already, it would be convenient to create an > LDAPAuthenticationProvider. > > I would not recommend adding such complexity to the existing json backed user > list, although it has the benefit of beting 100% self contained. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > >> 18. mar. 2016 kl. 23.30 skrev Oakley, Craig (NIH/NLM/NCBI) [C] >> <craig.oak...@nih.gov>: >> >> When using security.json (in Solr 5.4.1 for instance), is there a >> recommended method to allow users to change their own passwords? We >> certainly would not want to grant blanket security-edit to all users; but >> requiring users to divulge their intended passwords (in Email or by other >> means) to the administrators of the Solr installation is also arguably less >> than optimal. It is unclear whether one could setup (for each individual >> user: "user1" in this example) something like: >> >> "set-permission": {"name":"edit_pwd_user1", >> "path":"/admin/authentication", >> "params":{"command":[set-user],"login":[user1]}, >> "role": "edit_pw_user1"} >> "set-user-role": {"user1": ["edit_pw_user1","other","roles","here"]} >> >> One point that is unclear would be whether "command" and "login" are the >> correct strings in the third line of the example above: would they instead >> be "cmd" and "user"? "action" and "username"? something else? >> >> Even if this worked when implemented for each individual login, it would be >> nice to be able to say once and for all "every login can edit its own >> password". >> >> There could be ways to create a utility which would change the OS-ownership >> of its own process in order to decrypt a file containing the >> Solr-admin-password, and to use that to set the password of the Solr login >> which matched the OS login which initiated the process; but before embarking >> on developing such a utility, I thought I would ask whether there were other >> suggestions. >
