Access control list
Creating roles Creating rules, resources and privileges Assigning privileges to layers Assigning roles to users IntroductionAccess 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:
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 rolesIt 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 privilegesCreate 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:
Add new rule for editing the layer with the following values:
Assigning privileges to layersClick 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.
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 usersWe 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.
COPYRIGHT ® 2012, VEC |