[DISCUSS] Solr RBAC permissions to imply other permissions

[Jan Høydahl <ja...@cominvent.com>]

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

Re: [DISCUSS] Solr RBAC permissions to imply other permissions

[Jason Gerlowski <ge...@gmail.com>]

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 <gu...@gmail.com> 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 <ja...@cominvent.com> 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: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org

Re: [DISCUSS] Solr RBAC permissions to imply other permissions

[Gus Heck <gu...@gmail.com>]

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 <ja...@cominvent.com> 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)