[ckan-dev] proposed authz changes

[Rufus Pollock]

On 14 April 2011 18:03, David Read <david.read at okfn.org> wrote:
> Here are some proposed changes / strawman related to CKAN's
> authorization system - they aren't very big, but should provide for
> some forthcoming use cases. Do give feedback on any of these or ask
> more questions
>
> Dave
>
> The first two changes revolve around the is_authorized method, which
> is called by the logic layer to ask whether a particular user (e.g.
> Bob) is allowed to do a certain action (e.g. edit) on a certain object
> (e.g. Package).
>
> 1. The first thing the is_authorized method is a hook to a plugin
> which can override. This can only ALLOW an action or FALLTHROUGH (rely
> on the authz table). Extend this to allow DENY, so the plugin can stop
> a user being authorized for someone.
>
> Reason: authorization can be completely delegated to another system
> (or partially)

I'm +1 here.

> 2. is_authorized method currently takes (username, action, object)
> but for action=create_package, the object supplied is System, and for
> action=edit the object supplied is the package. Instead we should pass
> the proposed new object / change.
>
> Reason: an extension can then stop you creating a package with
> particular values inside it, e.g. an allowable department for this
> user

As Friedrich explains it seems there is a pre-create and post-create
authorization step (i.e. can I even show you the page and can you
actually create with those values). There is also an alternative (as
done in IATI) which is to limit the attributes a user can create and
have a post-package-create hook. I think the requirements here
probably need more analysis before implementing as this is quite
subtle.

> 3. Actions are so close to the actions in the logic layer, we should
> just merge them. 'package_create' is the same. 'update' becomes
> 'package_update', 'group_update' or 'package_relationship_update'
> depending on the object type.

Hmmm. Note sure about the reasoning here (surely there will be some
logic layer operations which don't have a corresponding action).

We've already talked about a similar change as part of:

<http://trac.ckan.org/ticket/1065>

Where we merge protection-object type and operation into action names
so actions become of form (note separator other than underscore):

'<protection-object>::<operation>'

One really important thing atm in 1065 (none of the rest is that
urgent) is ability to get a list of 'actions' relevant to a protection
object type (needed for authz wui)

> 4. Rename these two classes to better reflect what they are
>  * AuthorizationGroup -> UserGroup
>  * Group -> PackageGroup

I generally agree with this change but it warrants some thought. In a
way current 'Groups' do aggregate both packages and users (i.e. when
interpreted as organizations) and AuthorizationGroup is currently
explicitly and only about Authorization.

Rufus