I think it is the right moment to think about a new Authorization Plugin, and I like what you have come up with so far. I'd like to add a few more notes and thoughts to it from a consumer's perspective, let it be a client like the new UI or the user that will have to configure it.
In a discussion with Jason about RESTful APIs and how to determine the endpoints and the nesting, we were talking a lot about "what is a resource in the context of the API". We were trying to define these and their relationships, so that we can come up with a RESTful and easily consumable v2 API. Some ideas of what can be considered a resource are listed in the sheets of the v2 API [1]. We were also talking about abstracting away / hiding some terms to make the API future-proof and less deployment-mode specific (user-managed or cloud). Some of these terms that would be "hidden" are "core" and "zookeeper", where other terms like "collections" would be defined in a more general way. Now, why am I mentioning that? At the end, what we try to secure is the API and the resource / data objects accessible through it. And if I understand your message correctly about "facet value leakage", there are some cases where it is possible to get more resources or data objects through an endpoint. It is also important to know what permissions someone needs to access and do something with a resource, resource collection or data object. So it should be possible to document it in a similar way like the Google Calendar API [2], ideally in the OpenAPI spec through the typical OAuth 2 scopes [3] (without of course the need to limit ourselves in OAuth only). I believe in your pattern "Feature:Collection:Action:FilterID" you are going towards that direction. I believe it would be useful to define clearly what each segment is defining, and what the possible values are. For example, are wildcards allowed, are some values dynamic, what characters are forbidden, etc. Of course the permissions should also be consumable in the client-side, so that clients like the new UI could benefit from that and hide sections or features that are not accessible due to the limited access. If we consider a Solr deployment as a resource server (in terms of OAuth), in my opinion it would be best to define the authorization scopes on a resource level and grant access by authorizing users or roles via tokens (either tokens that include the scopes, or tokens that are used as IDs to look up the group of scopes). If I had to define the authorization scope format, it would be similar to what you proposed, just more API-oriented like [resource].[operation].[resource-id] so for example fetching the details of a single collection, which would be the endpoint GET /api/collections/getting_started (operation getCollection) the auth scope would be collections.getCollection.gettingstarted or with a wildcard collections.getCollection.* that grants access to all collections. For listing all collections (list) via GET /api/collections (operation getCollections) the auth scope would be collections.getCollections or if necessary it could be restricted with collections.getCollections.tech_* to limit the scope of getCollections to only collections matching tech_* In the mentioned google sheet from [1] there are proposals for endpoints with operation Ids and resource categorization that could be used for orientation. I am not sure if my thoughts / opinion is strongly influenced by the OAuth standards that I see everywhere, but I definitely see a good fit here. [1] https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?gid=1878317994#gid=1878317994&range=R:R [2] https://developers.google.com/workspace/calendar/api/v3/reference/calendarList/get#auth [3] https://swagger.io/docs/specification/v3_0/authentication/oauth2/#about-scopes Best, Christos On Tue, Feb 10, 2026 at 6:22 AM Gus Heck <[email protected]> wrote: > Apache Shiro now has a snapshot build that is fully Jakarta EE compliant > and so I'm beginning to think about what we might be able to do with it to > provide a simpler and easier to manage authorization system. This mail is a > fairly raw dump of what I'm thinking, yet to be vetted in any significant > way... just initial thoughts. Please chime in with positive and negative > impressions > > The following is a Javadoc that I hung on an entirely empty subclass of > AuthorizationPlugin tonight. It of course will likely be changed, some of > it moved to ref guide etc, etc, > > /** > * Authorization plugin based on Apache Shiro. The intent is to provide > fine-grained > * deny by default roles and permissions. Roles will imply groups of > permissions, > * and permissions will be of the form: > * <p> > * Feature:Collection:Action:FilterID > * <p> > * A basic set of permissions for admin functionality and query/update > permissions > * applicable to all collections are also be provided by default. These > * are then be organized into four default roles: Machine, Admin, QueryAll, > UpdateAll. > * Machine role will include permissions that allow actions capable of > compromising > * the hardware running solr (things like installing config sets), whereas > * admin will be administrative functions such as core, alias and > collection > * operations. QueryAll and UpdateAll will of course allow the obvious > associated operations > * for all collections by default. Action values will be CRUD, plus some > feature specific > * values such as "RELOAD" and "BACKUP" etc. Features are major areas such > as > * CollectionAdmin, Alias, Shard, Replica, Cluster, Node, Security, etc. > * an '*' for any segment of a permission will indicate a wildcard so > * CollectionAdmin:*:RELOAD:* would indicate permission to reload any > collection, > * and Alias:*:*:* would indicate permission for all alias related > commands. > * <p> > * The FilterId element will only be relevant for query related permissions > and > * provide an easy way to nominate a late-binding filter for simple use > cases > * such as user is only allowed to see documents with +type:FOO or > -type:BAR > * This of course comes with all the usual facet value leakage and > relevancy > * caveats of any other late-binding approach. The user may upload as many > * FilterId and (lucene syntax) filter pairs as they like. > * <p> > * Users are also be free to define their own permissions and roles, but > the > * options for Feature and Action elements will be limited to the existing > * values. > * <p> > * This authorization system will deny access to any user that does not > have > * at least one role that contains at least one permission granting them > access > * to the relevant feature,action,collection combination. When Solr is run > * in stand-alone mode in a self-managed cluster the collection attribute > * is ignored and treated as a wild card. Permission order will not be > * significant, and all permissions for all areas of the application will > * evaluate with the same logic. > * <p> > * Roles can be assigned to a user in the security configuration, or be > * provided by authentication tokens that have this capability (such as > * JWT). The user will have all roles from all supported sources. > */ > > The whole filterId thing is a bit of an unknown. I've done things with > matching database Ids to grant permissions on specific database objects > before, but that's slightly different because in that case you are given > the id *in the request* and match it against the permissions. I'm not sure > if I can get Shiro to tell me which permission(s) matched or otherwise > derive metadata from matching permissions, and I'm not 100% sure what I > would do if more than one permission with a filter matched. (Probably apply > both?)... Might have to drop that feature or disconnect it from > permissions, but if it could be done it would be nifty (if limited by the > usual late binding caveats). > > I also haven't yet thought at all about the implications for the security > section of the Admin UI, which I fear is going to turn out to be very > locked into to the exsisting "rule based" system. > > I haven't yet filed a Jira, but will after seeing what response/suggestions > come in for this. > > -Gus > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) >
