Honestly this is one of those scenarios where a front end API should be used to make it truly customizable. That way based on your business and use case needs you can control absolutely everything, Solr isn’t like sql, you can’t embed an update or delete in a search request, what you can do is intercept the call and put filter queries based on the user and their permissions to certain content,
> On Oct 9, 2026, at 12:18 PM, Jan Høydahl <[email protected]> wrote: > > Hi, > > The classic answer is OIDC, and it works pretty well. Solr does not own the > auth DB, it just receives a userid and a role from the oauth server. > > If you want basic auth, you could implement a custom AuthenticationProvider > that authenticates users with your external system. > I filed a JIRA ages ago https://issues.apache.org/jira/browse/SOLR-8951 to > make Auth providers truly pluggable, but it went nowhere. > > Jan Høydahl > >> 9. okt. 2026 kl. 17:34 skrev Eric Pugh <[email protected]>: >> >> Hey all, >> >> Looking at authenticating every individual user's searches into Solr using >> their username/password. I have a external system that manages username >> and password and what roles they have access to. >> >> The simplest option would be to just push username/password/role mappings >> into Solr from the external system. But, to do that, I would need to push >> the encrypted password into Solr, which we don't currently do (and of course >> have both sides encrypte/decrypt the same way). >> >> So I suspect that leads us to oAuth (for all the annoying reasons).... >> >> However, I'd love to hear if anyone has done this? What limitations did >> you find in what Solr offers today? >> >> Eric >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
