Access Control in VMOSS

Back to Project/VMOSS


Contents

Overview

This document explains the access control used in the VM module in VMOSS. This type of access control is also compatible with Sahana.

Definitions

  • Request
    • Every pair of 'act' and 'vm_action' URL parameters define a unique request. Requests can be thought of as use cases. They are stored in the vm_access_request database table.
  • Role
    • A way to group users and give them privileges. Roles are assigned to users through the vm_user_role database table, and every request has a set of roles associated with it from the vm_access_request_role database table. For a list of roles, see the Roles section below.
  • Constraint
    • Constraints are special specific checks or overrides that you can add to a request. They are populated through the vm_access_request database table and are linked with requests via the vm_access_constraint_to_request table. Constraints must be processed manually in the AccessController::isAuthorized() function. Currently, the only constraints available are certain case-specific ACL overrides. For a list of these and how to use them, see the Constraints section below.

Roles

  • Anonymous
    • A user is anonymous if he is not logged in. You do not need to assign this role to users, it will be automatically associated with a user if he is not logged in.
  • Volunteer
    • A volunteer.
  • Project Manager
    • A project manager.
  • VM Admin
    • A user with full access to the VM module.
  • Sahana User
    • A user who does not have any VM roles but is logged in. You do not need to assign this role to users, it is automatically associated with a user if he is logged in but does not have any VM roles.

Constraints

As mentioned in the definitions section, the currently available constraints are case-specific ACL overrides. These overrides are needed, for example, to allow a single volunteer to edit his own information without being able to edit the information of all other volunteers. Below is a list of currently supported constraints and how to make them work with your code:

  • ovr_my_info
    • This type of override grants access to the current user as long as he is accessing his own information. In order for this to work, the page that is being requested must have an entry in either the $_POST or $_GET arrays with key 'p_uuid' and value of the user's id. If that id matches the current logged-in user's id, then access is granted even though the user's roles deny him access. For example, in the volunteer edit page, there is a URL parameter called 'p_uuid' that corresponds to the id of the volunteer whose information is being edited. Since the ovr_my_info constraint is specified for this request, a volunteer can edit a volunteer's information whose p_uuid only matches his p_uuid (which is found from login and stored in the $_SESSION['user_id'] variable).
      • Allowing a volunteer to edit his own information while not being able to edit other volunteers' information
      • Allowing a volunteer to view his own information while not being able to view other volunteers' information


  • ovr_my_proj
    • This type of override grants access to the current user as long as he is accessing one of his own projects. In a manner similar to ovr_my_info, the page that is being requested must have an entry in either the $_POST or $_GET arrays with key 'proj_id' and value of the id of the project to which the user is requesting access. If the user is assigned to the project, he is granted full access.
    • Examples include:
      • Allowing a volunteer to view the information on his projects while not being able to view information on other projects


  • ovr_mgr_proj
    • This type of override grants access to the current user as long as he is a project manager who is accessing one of his own projects. In a manner similar to other overrides, the page that is being requested must have an entry in either the $_POST or $_GET arrays with key 'proj_id' and value of the id of the project to which the project manager is requesting access.
    • Examples include:
      • Allowing a project manager to view and edit his own projects while not being able to edit other projects
      • Allowing a project manager to add positions and assign users to his own projects while not being able to do so with other projects


  • ovr_mgr_pos
    • This type of override grants access to the current user as long as he is a project manager who is accessing a position that belongs to one of his projects. In a manner similar to other overrides, the page that is being requested must have an entry in either the $_POST or $_GET arrays with key 'pos_id' and value of the id of the position to which the user is requesting access.
    • Examples include:
      • Allowing a project manager to edit positions within his projects
      • Allowing a project manager to review time logged within his projects


Note that in order for a constraint to be associated with a request, you must also link them together using the vm_access_constraint_to_request database table.

Overall, these overrides (called constraints because other constraints can be implemented in the future that are not necessarily overrides) provide a way to reuse functionality. That is, the interface for editing a volunteer is the same for an administrator as well as a volunteer. The only difference is that from an access control point, the VM Admin role is the only role that has access to that request, but by specifying an ovr_my_info override, we can allow volunteers to only edit their own information.

Customization

Once VMOSS is installed, access control can be customized via the Administration -> Volunteer Management -> Customizations -> Access Control Modifications page. You can select a user and modify which roles he has, as well as select a request and modify what roles have access to it and which constraints (if any) apply.

Sahana Access Control - Overview

Sahana's method of access control is not used in the VM module for VMOSS. During VMOSS installation only (and not VM module installation), a configuration flag is set that tells the AccessController to not include the Sahana method of Access Control because it is not necessary for the VMOSS VM module, since all users will be registered via the VM module.

When the VM is included in Sahana, it also takes into account the Sahana Access Control methods, because in Sahana, not all users are associated with the VM module. If the user passes the Sahana Access Control, he is given full access. If not, the VM methods of Access Control are checked.

Sahana Access Control - In Detail

In short, the Sahana Access Control is as follows. There are a number of user groups, specified by the sys_user_groups database table, which are much like roles. Users are assigned to these groups using the sys_user_to_group database table.

Where it differs from VM Access Control is that all tables in the database are given classification levels. The classification levels can be found in the sys_data_classifications database table, and each table in the database is given a classification level using the sys_tablefields_to_data_classification database table.

Finally, each user group is given a combination of create, read, update, or delete ("crud") privileges on each classification of data. For example, superusers have "crud" access to person sensitive information, while anonymous users have no access to it at all.

As mentioned above, the VM module in VMOSS disregards this type of access control, and only uses the VM access control. However, when used within Sahana, the VM module must also incorporate this type of access control.

The way that the VM AccessController class handles this is by using the vm_access_classification_to_request database table. This table links a request with every database table it accesses as well as the types of actions (create, read, update, delete) that need to be performed on the tables in that request. The AccessController uses the Sahana inc/lib_security/lib_acl.inc library to check if the current logged-in user has access to perform all of those types of operations on each table in the request before granting access.

From a programming standpoint, no changes to new VM code need to be made to incorporate the Sahana Access Control. However, it is imperative that all new VM database tables are given a classification level in the sys_tablefields_to_data_classification table, and that all new requests are not only added to the vm_access_request database table, but also documented in the vm_access_classification_to_request table in terms of what tables are accessed in that request and what types of actions are performed.

When the VM module is in Sahana, the Module Config under the Administration module allows for customization of these data classification records. Also, whether in Sahana or not, the Administration interface for the VM module allows for customization of Access Control in general, as well as an "Audit ACL" option, which checks to make sure that all database tables have been classified, and which parses the code and tries to find requests that have not been added to the vm_access_request table.

VM Admins and System-Wide Admins

One last important point is the difference between VM Admins and System-Wide Admins. A VM Admin has full access to everything in the VM module, but not necessarily elsewhere in VMOSS. A System-Wide Admin in VMOSS will have access to everything (including the administration module for adding locations, organizations, customizing the VM, and creating other System-Wide Admins).

This (especially useful in Sahana) allows the possibility to have a user who is an administrator in VM module, but not in the rest of the system.


Back to Project/VMOSS