wiki:AccessControl

Version 5 (modified by dread, 5 years ago) (diff)

--

Access control

When a new package is created you as the creator automatically become admin for it and you can assign which other users have write or read access. NB: by default any user (including someone who is not-logged-in) will be able to read and write.

There are "system" level admins for CKAN who may alter permissions on any package.

Use Cases

  • A user means someone who is logged in.
  • A visitor means someone who is not logged in.
  • An entity is the subject of a permission (either a user or a pseudo-user)
  • There are roles named: Admin, Reader, Writer
  1. A visitor visits a package page and reads the content
  1. A visitor visits a package page and edits the package

3+4: Ditto for a user

  1. On package creation if done by a user and not a visitor then user is made the 'admin'
  1. An admin of a package adds a user as an admin
  1. An admin of a package removes a user as an admin
  1. Ditto for admin re. editor
  1. Ditto for admin re. reader
  1. We wish to be able assign roles to 2 specific entire groups in addition to specific users: 'visitor', 'users'. These will be termed pseudo-users as we do not have AC 'groups' as such.
  1. The sysadmin alters the assignment of entities to roles for any package
  1. A visitor goes to a package where the editor role does not include 'visitor' pseudo-user. They are unable to edit the package.
  1. Ditto for user where users pseudo-user does not have editor role and user is not an editor for the package

14+15: Ditto for above re reader role ...

16: Try to edit over REST interface a package for which 'visitor' has Editor role, but no API is supplied. Not allowed.

Optional

  • Support for access-related groups
  • Support for blacklisting

Implementation

      Context
Entity ----> Role

E.g. a user is assigned to a given role for a particular package.

    Context
Role ----> Action/Permission/Capability (on an Object e.g. a Package)

Package level:

  • Package Roles: admin, editor, reader
  • Entities: xyz@… (user), pseudo-users 'visitor'
  • Assignment of entities to roles in a given context (the package)
  • Roles give permissions (in a given context)
    • admin -> update assignment to roles, delete package, plus editor
    • editor -> update package plus reader
    • reader -> read package

System level permissions:

  • Roles:??
  • create package
  • update assignment of system level role

Determining permissions

def is_allowed(name, action, context=None):
    user = locate_user(name)
    if not user:
        # they are a visitor ...
   
    if context is None:
        context = 'system'
    contextroles = locate_roles(user, context)
    if context != 'system':
        sysrole =
        if sysrole = 'sysadmin':
            # can do anything ...
            return True
    for role in contextroles:
        # assuming 'ORing' of permissions
        if role.is_allowed(action)
            return True
    if visitor:
        visitor_role = locate_roles(visitor, context)
        # check again
    return False

Initializing Permissions for a Package

when we create a package: visitor is given reader and editor roles automatically (ditto for user)

DB Sketch

role enum: admin, editor, reader
action enum: read, edit, delete (to deleted state), purge (destroy), edit-permissions, create
context enum: system, package, tag, group, revision

shortcuts:
sysadmin can do everything on anything
? admin can do everything on the given object


role-action table

role | context | action
admin| package | update
admin| package | update-permissions
admin| package | read
editor| package | update
editor| package | read

user-role-table

username.id | context | objectid    | role
xyz.id      | package | geonames.id | admin
rgrp.id     | system  |             | admin
visitor.id  | package | geonames.id | editor 
visitor.id  | package | geonames.id | reader