allowedRolesAndUsers and Roles Blocking


Miscellaneous notes about the security index (allowedRolesAndUsers) and roles blocking in CPS

1   Standard Behavior

user:me belongs to group:secretary

allowedRolesAndUsers: (stored in catalog index)
 ['Reviewer', 'Manager',    # (roles having permission View in security map)
  'user:toto', 'user:riri', # (users having those roles as local roles)
  'group:secretary',        # (groups having those roles as local roles)

(describes who has View permission on the object.)

The catalog query is done with our identities:

allowedRolesAndUsers=['Reviewer',        # current *global* user roles
                      'Anonymous',       # always present
                      'user:me',         # current user
                      'group:secretary', # current user's groups

Will match because of group:secretary and also Reviewer.

Why do we keep user roles? In what case could we have a Reviewer role allowed but not our 'user:me' (or one of our groups)? Only if the allowedRolesAndUsers index has 'Reviewer' and not 'user:me'. Which means that during indexing, 'user:me' didn't have the Reviewer roles, but now has it. That's not possible with local roles (because when local roles change, we re-index allowedRolesAndUsers) so it must come from a global role.

2   Blocking syntax

The blocking syntax for a role is a prefix of '-' for that role. For instance, giving the role '-Reviewer' for 'group:role:Anonymous' blocks everyone from having the role 'Reviewer'. The role '-' blocks everything.

For local role blocking to be effective and use existing catalog datastructures, we can't block arbitrarily. The only case we keep is to block everybody for a given role, and not block individual users or groups. "Everybody" is formalized as 'group:role:Anonymous'.

Because nobody or everybody is blocked for a given role, the allowedRolesAndUsers datastructure can still be computed.