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)
