Configuring Access Control for a Project : Configuring Access Control—Overview

Configuring Access Control—Overview
For each RMS project, you set up an access control file. In the access control file, you group the decision project resources as desired, giving each group (or individual resource) an ID, and then you assign permissions to each user role, using those IDs.
Establishing the User Roles
Access is defined using roles. If file-based authentication is used, roles are defined and assigned to users in the password file (by default called users.pwd). If LDAP-based authentication is used, roles are defined and assigned to users in the LDAP directory.
You add one entry element for each user role. See Structure of the Access Control File for details.
See User Authentication Overview for details.
You must use only the roles defined in the password file or LDAP directory (depending on authentication type used) when configuring the access control file.
Guidelines for Configuring Access Control
You can use two general approaches to setting permissions. The general aim is to simplify the setup, minimizing the number of permissions you have to set in the access control file.
Allow everything and specify exceptions
One approach is to grant wide permissions using large resource groupings, and then selectively deny permissions within those groupings.
For example, suppose you define two resources as follows:
<resource name="/Concepts/*" id="AllP" type="PROPERTY"/>
<resource name="/Concepts/Person/CustID" id="CID" type="PROPERTY"/>
The first resource element defines a resource group consisting of all concept properties in the /Concepts project folder. The second element specifies one property in one concept. (The setup details are explained later in the chapter.)
Then you define permissions for using those resources, for a role named CallCenter:
<permission reref="#AllP">
<action type="create">ALLOW</action>
</permission>
<permission reref="#CID">
<action type="create">DENY</action>
</permission>
With these settings, you give users with the CallCenter role the create permission for all properties in the /Concepts directory except the custID property.
An example of an access control file giving full permissions is provided in the credit card application example, located in the following directory:
BE_HOME\rms\examples\CreditCardApplicationthe CreditCardApplication
Deny everything and specify exceptions
The other approach is to deny all permissions (which is the default setting for all permissions) and then give permissions to specific resources or groups of resources as needed.
Mixing these approaches
You can mix these two approaches in one access control file. For example, you can give broad permissions to one project folder, and then specify exceptions within that folder. For another folder you might give permissions selectively.
Structure of the Access Control File
The access control file is an XML file with the following elements:

 
<acl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ACL.xsd">
<resources>
  <resource id="id" type="ReType"/>
  <resource id="id" name="ProjectPath" type="ReType"/>
  . . .
</resources>
 
<entries>
  <entry>
    <role name="RoleName"/>
    <permissions>
      <permission reref="#id">
        <action type="ActionType">[ALLOW|DENY]</action>
      </permission>
      . . .
    </permissions>
  </entry>
  . . .
</entries>
</acl>

 
The entries element contains one entry for each role. For each role, you define one set of permissions. Each permission has of the following attributes
The reref attribute references a resource ID defined in the resources element. It identifies a resource or set of resources.
The name attribute specifies the project path to the resource or resources. (The name attribute is not used when you specify permissions for an entire resource type.)
The resource type attribute specifies what types resources in the specified project path are included in the permission.
The action type attribute specifies an action type, for example, create.
See Table 45, Resource Types and Action Types.
Permissions—ALLOW and DENY
The value of the action element is one of the key words ALLOW or DENY. It determines whether the specified permission is given denied.
DENY is the default value. You only need to set the DENY value explicitly when you have given ALLOW permissions at a higher level, and want to make individual exceptions within that broad scope.
The values ALLOW and DENY are case sensitive. Use all capitals.