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

its always a balance between access and security. we don't want to prevent genuine users from access to vital information with unnecessary security barriers.

please provide suggestions on that balance particularly for Humantarian ICT. we thought of having a hierarchical ACL.

sahana administrator:the administrator of the organization deploying sahana(lets name him Sahana admin for simplicity ), he has 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 ,date edit users,etc with privileges under the privileges granted for the organization.

in terms of ACL :there are predefined roles

we can let sahana admin define the roles ,makes it more flexible.

but we have thought of giving so many configurable options to the user ,to make the application more flexible. the downside is the advanced user might get frustrated because,there are so many options ( why i say advanced user is, with out any configuration , with default options an average user can manage, advanced user are people who want do a bit more…)

so 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 permissbale actions for an user for each resource without relying on roles.

The way the sahana framework works ,every request is routed via the front controller (index.php). front controller calls the function identified using the $_GET[“act”] and $_GET[“mod”] variables. Before calling the function ACL check is done ,if ACL is enabled. Therefore 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 contains 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. Another important point is , since it is difficult for the lay user to specify permissions for each and every function, functions can be registered under function groups (e.g “create”,“delete”) and then permission 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 with in '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. and 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.

Though the main resources we protect is the function, the design allows even database row locking. But there is no API for that as the need did not arise so far.

from a technical point of view , there is an open source class phpGACL( http://phpgacl.sourceforge.net/), with

powerfull ACL capabilities. once you download phpGACL , in docs ,there is a very easy to understand manual ,i have attached it.

just for your information 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 grain 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

GACL is used by many popular sites.(dotProject, Mambo)

see http://phpgacl.sourceforge.net/cool_apps.html

therefore 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.