I brought up the topic because the SIP did not convey clearly whether this as yet another plugin on top of existing framework or a reboot. I felt we need a more fundamental reboot.
That said, it could be that we can wire in Shiro with our existing security.json as configuration source, since that is configurable. I agree that tangential topics such as where security.json is stored is better suited for a separate discussion to keep the scope narrow. Jan > 5. mai 2026 kl. 14:49 skrev Jason Gerlowski <[email protected]>: > > Hey Gus, > > Thanks for writing this up and considering implementation Gus! > > At a high-level, I notice there's not a ton about Shiro in the SIP. I > guess I expected to see a bit more on "Here's why Shiro is a good > choice", or "Here's what Shiro gets us compared to other > alternatives", or "Here's the bits of Shiro I think we should use". > That might be good to add at some point. > > Lower-level comments on the SIP "inline" below... > >> ["Shortcomings" section] Solr will start up (or continue running) with a >> broken security.json > > At startup this is definitely true. But once running, if someone > uploads a malformed security.json Solr will ignore the changes and > continue enforcing the last well-formed security.json. > > (Not saying this is great or worth preserving; just pointing out a bit > of delta from what you described.) > > Also - is this related to the SIP? It seems conceptually unrelated > from a "Shiro RBAC Implementation". > >> ["More Common" section] When the code is reached, the user's roles are >> expanded to a list of permissions and if the role imply the required >> permission the code executes > > Can you expand a bit on what this means? (Here or in the SIP, either > way). In your writeup it seems like this is being contrasted with > permissions that are checked or applied at the request/API level. It > sounds like that'd allow for authorization to happen somewhat lazily, > perhaps even when solr is midway through processing an API call. On > the surface that seems potentially messy, but perhaps I'm > misunderstanding... > >> ["Motivation" section] The goal is to provide a new alternative that is > > Your writeup leaves off in mid-sentence here. The suspense is killing me! > :-p > >> ["Proposed Changes" section] Additionally Solr should refuse all requests if >> the security.json fails to parse > > Scope-wise, I'm surprised to see this in a SIP about a new plugin > implementation. Is there a connection between this and a Shiro plugin > I'm missing, other than that they're both generally auth related? > > FYI that there's a bit of a catch-22 problem here. Many folks rely on > Solr APIs to update their security.json, so a "refuse all requests" > strategy in this case could cut users off from the main means of > fixing their security.json and "brick" their cluster. > >> [Jan and other's discussion of security.json in thread above] I think >> perhaps a fully parallel approach... > > I'm not in love with ZK-based security.json by any means, but changing > how we manage security config is a *huge* expansion of scope in what's > already a pretty ambitious SIP. It's also a change that'd > (temporarily at least) double our attack surface from a framework > perspective. > > Unless it's inextricably tied to the Shiro work in some way, I'd be > leery of bundling this into SIP-26. > > Best, > > Jason > > On Mon, May 4, 2026 at 9:34 PM Gus Heck <[email protected]> wrote: >> >> How about this: we make it possible to push the zk security config to a >> file on all current nodes, Nodes that don't find security in zk consult the >> filesystem as a fallback. Thus the upgrade scenario can be: >> >> 1) Push down security to the nodes >> 2) remove security definitions from zk >> 3) perform upgrade >> 4) supply security to zk again to ensure uniform >> >> There could also be an optional "clear local security files" command that >> cleans the per node security files (if zk has security) out to ensure no >> confusion on subsequent startup. >> >> Folks who prever local files just never supply a security definition to zk >> in the first place... >> >> On Mon, May 4, 2026 at 10:34 AM David Smiley <[email protected]> wrote: >> >>> I love the idea of a separate module, although it isn't a necessity. With >>> such, a future potential CVE could be reported against this module, thus >>> users choosing not to use the module don't get annoying vulnerability scan >>> alerts for modules they don't use. Although it's a separate topic, I could >>> see benefits of modularizing more driven by that motivation (and other >>> motivations of course). For example, imagine if more SolrCloud aspects of >>> solr-core were separated to a jar that standalone mode could run without. >>> It would mean a SolrCloud-specific CVE could be associated to that JAR and >>> not solr-core. Just a thought. And imagine a stripped-down, embedded Solr >>> as well (low dependencies). Of course, realizing such fantasies would >>> require real work, as CoreContainer and other classes assume all public >>> classes are available to it. >>> >>> I definitely want to be able to configure security purely from local >>> files/environment, excluding ZK. Managing configuration in ZK with >>> evolving cluster upgrades has been problematic from my past experience. By >>> contrast, relying on a locally built & tested Docker image leaves less >>> "state" behind to manage with an upgrade. >>> >>> On Sun, May 3, 2026 at 6:34 PM Gus Heck <[email protected]> wrote: >>> >>>> I find the idea of out of sync security settings terrifying. If it's not >>>> managed by zk then you have to deal with any number of corner cases >>>> involving nodes that lost connectivity, were down, or in K8 world, >>> settings >>>> on the persistent volume that is re-attaching... >>>> >>>> The last thing I want is more than one notion of what the security >>> settings >>>> are. I imagine a json version of the info in shiro.ini in zk. I have a >>>> personal project where I stored the permissions in a database table and >>>> mapped it to hibernate. We could even just put an ini in zk too. >>>> >>>> I definitely would like to have this be an option not a replacement >>>> initially I suspect if it goes well the old system will be sunset at some >>>> point. >>>> >>>> Also not yet mentioned - I would *hope* I can make it a module (and move >>>> the current one to a module too, which might be a separate effort or >>>> necessary for this. >>>> >>>> >>>> On Sun, May 3, 2026 at 6:06 PM Jan Høydahl <[email protected]> >>> wrote: >>>> >>>>> Great that you want to start this effort. >>>>> >>>>> When you say "Add a new plugin based on Apache Shiro", do you then mean >>>>> trying to fit Shiro into our current security.json plugins or to start >>> a >>>>> fully parallel implementation? >>>>> I think perhaps a fully parallel approach (with shiro.ini or some other >>>>> local-to-node config format) being used. I'm starting to question if >>>> having >>>>> the central security.json in ZK is in itself a security risk compared >>> to >>>>> local files on nodes. >>>>> It is also far easier to bootstrap a solr node with security if based >>> on >>>>> local file configuration, than relying on ZK. Perhaps the SIP can >>> discuss >>>>> such tradeoffs. >>>>> >>>>> Jan >>>>> >>>>>> 3. mai 2026 kl. 23:25 skrev Gus Heck <[email protected]>: >>>>>> >>>>>> oops, forgot to put the discuss tag on the subject line, please >>> proceed >>>>> on >>>>>> this thread >>>>>> >>>>>> On Sun, May 3, 2026 at 5:20 PM Gus Heck <[email protected]> wrote: >>>>>> >>>>>>> I spent some time writing up an idea that's been growing in my head >>>>>>> since I watched Jason's talk on our "not so basic auth" at activate >>> in >>>>> 2019 >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> https://cwiki.apache.org/confluence/display/SOLR/SIP-26%3A+Role+Based+Authentication+using+Apache+Shiro >>>>>>> >>>>>>> LMK what you think. I'm hoping to begin spending some time on this >>>> soon. >>>>>>> >>>>>>> -Gus >>>>>>> >>>>>>> -- >>>>>>> http://www.needhamsoftware.com (work) >>>>>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://www.needhamsoftware.com (work) >>>>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com (work) >>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>> >>> >> >> >> -- >> http://www.needhamsoftware.com (work) >> https://a.co/d/b2sZLD9 (my fantasy fiction book) > > --------------------------------------------------------------------- > 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]
