This is an old revision of the document!


Important Note: This page is DEPRECATED!

The new approach is documented here:

Introduction

ACL plays a vital role in Sahana which is responsible for maintaining a lot of sensitive information.

There's always a balance between access and security. We don't want to prevent genuine users from access to vital information with unnecessary security barriers, particularly for Humantarian ICT.

We have a hierarchical ACL:

Sahana administrator: the administrator of the organization deploying sahana (called Sahana admin for simplicity), with full control.

Organization administrator: organizations register with Sahana, and each organization administrator is granted certain privileges by the sahana admin. We may like to go up to the branch level, if required?

Organization users: organization administrator registers, data entry users, data edit users, etc with privileges under the privileges granted for the organization.

In terms of ACL, there are predefined roles

(We could let the sahana admin define the roles, making it more flexible. The downside is the advanced user might get frustrated because there are so many options )

A new user can be assigned multiple roles (when the roles are defined we make sure there are no conflicts).

The advanced user can directly specify the permissable actions for a user for each resource without relying on roles.

ACL and Front controller

The way the sahana framework works, every request is routed via the front controller (index.php). The front controller calls the function identified using the $_GET[“act”] and $_GET[“mod”] variables. If ACL is enabled, then an ACL check is done before calling the function. Therefore the main resource we protect is the function that is called via front controller. Currently All the ACL entries are aimed at protecting functions. Module (e.g.organization registry) developers can provide a script to indicate which functions to protect. Otherwise there is an interface to register functions (in System Administration). The API is there for all ACL-specific things, but the interface now covers nearly the whole API.

Below is some sample code that registers a function to be protected and gives permission for the guest role to use it.

Since it is hard to specify permissions for each and every function, functions can be registered under function groups (e.g “create”,”delete”) and then permissions are specified for those groups.

e.g :

// add an action group named "create" under the module "or"
$res=shn_acl_add_action_group("or","create","create group");

// add an action name 'shn_or_reg_org" under the above action group 
$res=shn_acl_add_action("or","create","shn_or_reg_org","Register function");

// give permission for 'create' action group within 'or' to 'guest' role
$res=shn_acl_add_perms_action_group_role('guest','or','create');

Above code is not complete, but I hope it gives an understanding of the design. For example if the functions relevant to data input can be grouped under “create” group. Then data edit functions can be grouped under “edit” group. Then for user “A” if you allow “create” group, but not “edit” group, then front controller with the ACL library will make sure user “A” cannot edit.

More complete Example

Though the main resource we protect is the functions, the design allows even database row locking. But there is no API for that as the need has not arisen so far.

Deep into the design

This implementation is based on the open source class phpGACL: http://phpgacl.sourceforge.net/. phpGACL has a very easy to understand manual, included in the download.

GACL concept is:

  • There are resources/objects you need access to (e.g webpages) : Access Control Objects (ACO)
  • There are requesters for these objects (e.g users): Access Request Objects (ARO)
  • Then for fine-grained control there are AXO's: Access eXtension Objects(AXO).

AXOs are identical to AROs in many respects. There is an AXO tree (separate from the ARO tree), with it's own Groups and AXOs. When dealing with AXOs, consider an AXO to take the old role of the ACO (i.e. “things to control access on”), and change the view of ACOs from “things to control access on” to “actions that are requested”.

ARO and ACO-only View:

  • AROs: Things requesting access
  • ACOs: Things to control access on

ARO, ACO and AXO View:

  • AROs: Things requesting access
  • ACOs: Actions that are requested
  • AXOs: Things to control access on

Example:

  • A website manager is trying to manage access to projects on the website. The ARO tree consists of all the users:

Website

├─Administrators

│ ├─Alice

│ └─Carol

└─Users

├─Bob

└─Alan

The projects are organized by Operating System into categories in the AXO tree:

Projects

├─Linux

│ ├─SpamFilter2

│ └─AutoLinusWorshipper

└─Windows

├─PaperclipKiller

└─PopupStopper

The actions that can be taken with each project are “View” and “Edit”. These are the ACOs.

GACL provides a very easy to use API to specify ACO, ARO, AXO.

Once we verify the user identity , we just need to call the API with the username(or role), with the name of the resource and the action. It will output DENY or ALLOW.

GACL is used by many popular projects (e.g. Mambo)

Main Author: Ravindra de Silva Contributors: …


Navigation
  • Navigate