Hey Jan, Thanks for starting this discussion. My 2 cents:
- 100% agree that RBAC is often a point of confusion for users. - +1 to the incremental improvements you suggested for 9.0 as long as there are docs that make it really clear that the security.json's semantics are changing and users shouldn't just copy over their old security.json. (Of course, this is always discouraged across major releases but I'd guess many users do it nonetheless.) - IMO the long term goal should be to introduce a replacement authz plugin that leans on an established security library. (That'd let us deprecate and eventually remove the current RuleBasedAuthorizationPlugin down the road.). The incremental improvements are going to be a big boost for 9.0, but they leave in there a lot of the most confusing aspects of RBAP that we'll eventually want gone entirely (particularly how it finds matching permissions at request-time). Best, Jason On Mon, Nov 22, 2021 at 2:16 AM Gus Heck <[email protected]> wrote: > > Yes, to all the comments about the system being unfamiliar and hard to > reason about for people who have spent time working with other such systems. > Taken in the abstract it covers the necessary functionality and is quite > powerful, but in the context of what most users already know it's a brain > buster. This talk by Jason Gerlowski at Activate has been incredibly useful, > and when I've watched it very recently I can mostly predict how solr RBAC > will behave ... > > https://youtu.be/_RS-l9l1ZxQ?t=1115 > > Note the description of how it works: > "does the request match a permission that has a role that the user has" > > The normal paradigm is > "does the user have roles, which grant a set of permissions that is a > superset of the permission(s) required for the request" > > Perhaps one of the worst bits is that solr fails open (ALLOW by default in > iptables parlance) rather than failing closed (DENY be default), which is a > rare way to operate. The worst possible mistakes (exposing the majority of > functionality) can come from not expecting this opposite policy. > > I think (as alluded to in the above mention of update vs edit) that > inconsistent naming is also a part of why things are hard to understand. > > "Edit" evokes the image of a person sitting at an editor editing a document, > and the idea that they could not see what they are editing seems like utter > nonsense. > "Write" evokes "the half of I/O flowing from the user to the data > destination" and probably no one would expect it to grant both halves of the > I/O concept. (or alternately file system permissions) > "Update" evokes the CRUD concept, again leading to an expectation that > Create, Update and Delete will be separate concepts specified separately.. > > > Consistent naming that follows a single metaphor and a predictable pattern is > likely the single simplest thing to ease the confusion. > > I have previously expressed that we should either employ or at least learn > from Apache Shiro (see > https://shiro.apache.org/java-authorization-guide.html) since the folks over > there are solely focused on auth, and likely have a fairly round wheel > already. > > So IMHO easiest quick wins are > > 1) Change to be "deny by default" any time security.json is non-empty. > - If the users haven't understood the system things are more likely to > NOT work and force them to understand before deploying with holes (not > always, but chances are better). > 2) Rename the permissions using a single consistent metaphor. > - Consistency will simplify the number of thought patterns bouncing > around in the learner's head, and be easier for future plugin writers as well. > > Longer term we should be thinking of providing an alternative plugin that > compares a set of permissions from the user's roles to one or more > permissions calculated from the request or explicitly required by the code. > > -Gus > > > On Sun, Nov 21, 2021 at 7:08 PM Jan Høydahl <[email protected]> wrote: >> >> Hi, >> >> During my work on SOLR-11623 "Every request handler in Solr should implement >> PermissionNameProvider interface" and SOLR-15776 "Make Admin UI play well >> with Authorization" I got more intimately familiar with how Solr's RBAC >> permissions are applied (or not applied), and I mapped each Admin screen to >> what permissions it may require in a spreadsheet: >> https://docs.google.com/spreadsheets/d/1s2xokDxw9IkXr7ZA5n06RPDj6EwvpbsZ7zUeKpvRC3Q/edit#gid=0 >> See >> https://solr.apache.org/guide/8_11/rule-based-authorization-plugin.html#permission-ordering-and-resolution >> for the RefGuide documentation of permission ordering and resolution. >> >> The system is so different from most other RBAC systems I've seen, and >> incoming emails and JIRAs suggest that our users often mis-unserstands and >> mis-configures Solr security. >> As an example, when I changed the ReplicationHandler so it requires READ >> permission, some tests started to fail. A user who earlier was granted >> access due to ALL permission was now denied, since he did not have READ >> permission. >> The recent addition of the Security Admin screen makes it easier for users >> to get it right, as the UI warns you about common mis-conceptions. >> >> One typical confusion is that an "edit" permission does not imply the >> corresponding "read" permission, i.e. if you can have "config-edit" but >> still not be allowed to read config. >> And guess what happens if a user is assigned only the "all" permission? Then >> she is denied "read", "update", "config-edit", "config-read" etc if any of >> those happen to be configured earlier in the list than the "all" permission. >> This is due to the first permission in the list matching a certain endpoint >> is chosen as the "governing permission", and then the user needs to have a >> role that has exactly that permission configured. I.e. to create a >> super-user role you need to include every single permission, it is not >> enough with 'ALL'. >> >> While a total re-write based on a standard security library would be nice, >> that is not in scope for 9.0, so I'll propose some incremental improvements >> instead, namely that some predefined permissions will imply some others: >> >> - Any "FOO-EDIT" permission given to a user will also grant that user the >> "FOO-READ" permission (not sure that "UPDATE" should imply "READ" though?) >> - The ALL permission given to a user will also grant that user all other >> permissions (or otherwise shortcut permission matching with the same effect) >> - COLLECTION-ADMIN-EDIT/READ will imply CORE-ADMIN-EDIT/READ >> - Perhaps CONFIG-EDIT should imply SCHEMA-EDIT? Since schema is included in >> the config-set. >> >> >> Note that even if my proposals here sound smart, I also realize that I may >> have got it all wrong and that they may totally break other subtle parts of >> the scheme. >> I suspect that few of the committers feel they have a total grasp of how >> current system is intended to work, but don't be afraid to comment anyway. >> If committers don't understand the system, how can users? :) >> >> Jan > > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
