Giscuit
Prev Next

Access control list

Introduction

Access control list (ACL) provides a lightweight and flexible implementation for privileges management. In general, an application may utilize such ACL's to control access to certain protected objects by other requesting objects.

For the purposes of this documentation:

  • a resource is an object to which access is controlled.
  • a role is an object that may request access to a Resource.

Put simply, roles request access to resources. For example, if a parking attendant requests access to a car, then the parking attendant is the requesting role, and the car is the resource, since access to the car may not be granted to everyone.

ACL provides a tree structure to which multiple resources can be added. Since resources are stored in such a tree structure, they can be organized from the general (toward the tree root) to the specific (toward the tree leaves). Queries on a specific resource will automatically search the resource's hierarchy for rules assigned to ancestor resources, allowing for simple inheritance of rules. For example, if a default rule is to be applied to each building in a city, one would simply assign the rule to the city, instead of assigning the same rule to each building. Some buildings may require exceptions to such a rule, however, and this can be achieved in ACL by assigning such exception rules to each building that requires such an exception. A resource may inherit from only one parent resource, though this parent resource can have its own parent resource, etc.

A role may inherit from one or more roles. This is to support inheritance of rules among roles. For example, a user role, such as "sally", may belong to one or more parent roles, such as "editor" and "administrator". The developer can assign rules to "editor" and "administrator" separately, and "sally" would inherit such rules from both, without having to assign rules directly to "sally".

Though the ability to inherit from multiple roles is very useful, multiple inheritance also introduces some degree of complexity.

Creating roles

It is recommended to have a good structure in mind of the users roles in the system. Also do not forget about extensibility of the roles.

In this example we have an "agency" role and an "agency_staff role", "agency" can view specific layer and agency_staff can edit it.

Click on the Access control list tab.

Add new role "agency" and extend it from "registered".

Add new role "agency_staff" and extend it from "agency".

Creating rules, resources and privileges

Create one rule for "agency" role with a privilege for viewing data and another rule for "agency_staff" role with privilege for editing data. "agency_staff" role extends "agency" so we don't need to define the rule for viewing data for role "agency_staff".

Click on the Access control list tab.

Add new rule for viewing the layer with the following values:

  • Role. Select the "agency" role from the list
  • Resource. Enter a name for the resource, for example "world_layers"
  • Privilege. Enter a name for the privilege, for example "view"
  • Group. Select the "layer" group from the list

Add new rule for editing the layer with the following values:

  • Role. Select the "agency_staff" role from the list
  • Resource. Enter a name for the resource, for example "world_layers". As you can see we specified the same resource name, this will create one resource name with two different privledges.
  • Privilege. Enter a name for the privilege, for example "edit"
  • Group. Select the "layer" group from the list

Assigning privileges to layers

Click on the Layers tab. Select your layer in our example it's the "World boundaries", right click on it and click Edit. Click on the Share tab.

  • Resource. Select the "world_layers" resource
  • View privilege. Select the "view" privledge
  • Edit privilege. Select the "edit" privledge
  • Edit attributes only privilege. Select the "edit" privledge
  • Access OWS services privilege. Select the "view" privledge

Now the World boundaries layer is visibile by roles that are allowed to access "world_layers" resource and "view" privledge. Also it is editable by roles that are allowed to access "world_layers" resource and "edit" privledge.

Assigning roles to users

We recommend you to create a special user to test if your rules do what you expect. Users should extend the registered role to be able to log in.

Click on the Users tab. Double click on user Role cell and select "agency" or "agency_staff" role.

If you set user's role to "agency" he will be able to view the World boundaries layer, if you set it to "agency_staff" he will be able to view and edit the layer, if you set it to "registered" he will not be able to edit or view the layer.

Prev Up Next
Upload data and create layers Administrator Editing rules

COPYRIGHT ® 2012, VEC