BluePrint for Authorization (alternative version)

Original proposal: BluePrint for Authorization

General model

Authorizable Methods

Authorization is implemented for the following methods:

• module access (execute, all controllers of the module)
• controller access (execute)
• table access (create/read/update/delete and custom method)
• record access (create/read/update/delete and custom method)

Basic Policy

Authorization policy is implemented as:

• if a method is not restricted, then it is accessible for everyone
• if a method is restricted, then permission must be explicitly granted, otherwise it is denied (Allow=>Deny order)

Roles

Permissions are assigned to roles (not to individual users):

• roles are stored in auth_group
• admin role is auth_group 1 (cannot be modified)
• membership in the admin role overrides any restrictions everywhere

• roles are assigned to users by auth_membership
  • this can happen either through admin UI or implicitly (no admin interaction)
  • it must be possible to log this
• additional roles can be created after deployment
  • this will usually happen implicitly, i.e. not through admin UI
  • does not require a generic UI solution
• roles of the actual user are re-read from the DB and stored in the session once per HTTP request
  • caching of this re-reading needs a proper method for cache invalidation on update notification
  • do not implement caching unless it really makes us performance problems

There are two pseudo-roles for record access:

• author (=the author of the record)
• editor (=the last author of the record)

Functions

Denial of access

shn_unauthorized(msg="You're not allowed to access this module")

• shn_unauthorized() realizes error notification and redirection as appropriate
• non-interactive modes:
  • raise a HTTP error and a JSON error message
  • MUST NOT REDIRECT!
• interactive modes, one of:
  • redirect (e.g. to login) and and display an error message on the target page (acceptable)
  • raise a HTTP error and display an error page, provide redirection options from the error page (more RESTful)

• the msg argument is optional

Module/Controller Access

if shn_has_role("Facility Admin"):
    ...

• shn_has_role() refers to the current user
• returns always True for sysadmins (auth_group 1)
• shn_has_role() tests can be combined by and, or and not

Table/Record Access

• Table auth_table_permissions: tablename, method, role
• Table auth_record_permissions: tablename, method, record_id, role
• a table/record without explicit permissions falls back to system default

• record restrictions override table permissions
• table restrictions override record permissions

shn_permit(table, method, role, id=None)

• adds role to the list of permitted roles for method on table (record id of the table)

shn_deny(table, method, role, id=None)

• removes role from the list of permitted roles for method on table (record id of the table)

shn_restrict(table, method, role=None, id=None)

• sets the list of permitted roles for method on table (record id of the table) to role

shn_permitted(table, method, id=None)

• returns True/False refering to the current user
• returns always True for sysadmins (auth_group 1)

Visibility of options

Extend MenuS3() to check for roles before inserting menu items.

Currently:

menu_option = [T("Option"), right=False, URL=url]

New:

menu_option = [T("Option"), right=False, restrict=[list_of_roles], URL=url]

• hide all sub-items when the main-item is hidden
• hide the main item when there are no more sub-items left?
• better: instead of hiding, make options "gray"

Possible extensions

• restrict access per representation (e.g. allow HTML/POST, deny XML/PUT)
• assign roles to user groups instead of individual users (optional)
• method approval constraint:
  • allow modifications in a table/record for a role, while requiring approval by another role to finalise
  • hide modifications for all other roles until finalised

---

BluePrints