[super] Change Authorization System

[johnlawrenceaspden]

Child tickets

• #1050 Authz lib improvement and refactor of ckan/lib/authztool.py
• #1004 Group creation instructions missing
• #1099 Strange interactions between two browsers while playing with authz groups
• #1115 can have two authzgroups with the same name
• #1133 command line rights manipulation doesn't work
• #1138 minor navigations behave inconsistently

Old ticket description:

1. Change name of AuthzGroup? to UserGroup? to reflect what it is for

2. Get rid of Roles, and replace them with direct assignment of actions, even though there are many actions, and extensions can add arbitrary ones.
   • Debatable whether we should cut the number of actions to correspond to the three roles defined by the base system.
   • Have a method of finding roles (or, in future, actions) relevant to a given protection object (e.g. FILE-UPLOAD(ER) not relevant to Packages)

3. Change UserGroups? so that they can have a hierarchical structure,

More info on Hierarchy change

e.g. UserGroup? NHS contains the User nhsysadmin, as well as the UserGroups? SURREY and BERKS, which themselves contain users.

One user in SURREY is Simon the Sysadmin, who has permissions on the whole system. His permissions should not leak out to other users or groups, and user permissions generally should not.

Each Group has permissions over various objects.

A user has permissions in his own right, and also has the permissions of his own group, and of all the groups contained in his group, and so on recursively.

Algorithm:

possible(user, action, package):

if user has permission for action on package

or any of have that permission

or any of his groups group-children (but not user-children), and so on recursively have the permission.

[sebbacon]

To reflect further conversations:

• We are parking this ticket until dictization is complete
• We would prefer to see roles as asserted globally by default, with packages just storing exceptions. E.g. If I am a "reader" globally, then I have "read-package" permission on all packages new and existing, unless otherwise asserted locally on a package.
• Also w.r.t. algorithm above, consider repoze.what's model; "possible" is analagous to "has_permission". See ​http://what.repoze.org/docs/1.0/Manual/Predicates/Builtin.html

[dread]

Wow, lots of solutions here, and not enough evidence of the problems encountered / difficult use cases.

I have tried here to extract what John and Seb might be suggesting is difficult with our current ​http://en.wikipedia.org/wiki/Role-based_access_control system.

1. (Seb) It seems crazy to change the User-Object-Roles for every single package to 'lockdown' a CKAN instance. Instead of using Roles 'reader' & 'editor' we start using Roles 'logged_in_user' and 'anon_user'. Then, with only changing a couple of lines of the Role-Action table for these Roles, you can give or remove permissions to edit / create packages, groups etc.

2. (John) Actions are being added all the time by migrations and extensions. I'm not sure what the problem is here - can someone explain? The separation of Users and the new Actions by adding the Role 'join' means the migration/extension can add existing Users with the new Actions. For example when we added the 'Group' protection object, logged in users could previously create groups, so it is natural to add this action to the 'editor' role. If you get rid of Roles, as John suggests, then you end up having to add as many Rights objects as users. And you might end up trying to infer new Rights on the basis of old Rights, rather than a role, which would be more natural. (Is the only reason to denormalise the UOR and RA tables the sake of ease of understanding? I would think we can explain the concept better now...!)

3. (John) This Group Hierarchy description sounds a bit like earlier incarnations of the DGU requirements. "or any of his groups group-children (but not user-children)" I'm not sure I understand the user-children bit, and I'm wary of any difficult-to-grasp concept. This modelling seems to take the UserGroup/User? hierarchy model and use that as a hard-coded interpretation of the Authorized permission. In contrast, in DGU Evan split the Organisation Hierarchy model from the Authorization model. Each User has explicit permissions for each Organisation he is allowed to add/edit packages for. This helps for these two use cases we have to contend with: when a user is an admin for unrelated branches of the Organisation hierarchy, and when an Organisation is actually in two branches of the Organisation hierarchy. It also seems more generally flexible.

[sebbacon]

Re the point against my name, yes -- I think the fundamental principles of the current system are fine, but the implementation means asserting things for every single object, whereas we should be able to optimise it for the general cases -- something along the lines you suggest.

I would be very happy to write up a full, detailed proposal for the system before we implement anything, if only as a proper straw man to have debates around.

[dread]

Great stuff Seb, cheers for that.

[thejimmyg]

This is now more urgent and I think we have enough consensus to go ahead. See #1094 too.

[thejimmyg]

Merging with #1094 so see the discussion there too.