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]
