Configuring Access Control for a Project : Working with Access Control Files

Working with Access Control Files
In this release access control is used only by TIBCO BusinessEvents Decision Manager. This section is tailored for use by that component.
Access control settings are created using XML files with the extension .ac. This section explains the elements used to define access control, ways you can add or edit access control files, and where to place the files so they can be used by RMS and Decision Manager.
Examples shipped with the product contain access control files you can use as models.
Creating and Modifying an Access Control File
Use any of the following methods to work with access control files:
You can create or modify an RMSProject.ac file using any XML editor.
Required Location of Access Control Files
The access control file for an RMS project must be placed in the project’s config directory and it must be named using the format ProjectName.ac.
See TIBCO BusinessEvents Decision Manager User’s Guide to understand where the project directory or directories are located.
Specifying and Grouping Decision Project Resources
In the resources element, you group the project resources in whatever way supports the permissions you want to set. You give each grouping or individual resource an ID that is used when defining the permissions.
Using Resource Type as a Filter
How you specify the resource group is partly determined by the resource type attribute. The resource type can act as a filter. For example, suppose in the name attribute you specify a directory that includes events and concepts. If you set the type attribute to "CONCEPT" then the ID associated with this grouping is used to set permissions only on the concepts in that folder (and its subdirectories).
You could create a second grouping whose type specifies "EVENT" so that you can set permissions on events in that folder branch separately.
Specifying an Individual Resource
To specify an individual resource, provide the project path to the resource in the name attribute. The project path is the folder path to the ontology entity, as seen in the Explorer panel. The example below shows how to specify an ID that is associated with the FirstName property of the Person concept:
<resource name="/Concepts/Person/FirstName" id="FN" type="PROPERTY"/>
Grouping Resources Using Wildcards
You can associate groups of resources with an ID using the wildcard character in the project path. The asterisk (*) is used as the wildcard character. For example:
<resource name="/someFolder/* "id="AllP" type="PROPERTY"/>
Grouping Resources by Resource Type
The broadest resource grouping is provided by setting permissions at the level of resource type. This method groups all resources of that type in the project. To set a resource type resource group, you associate an ID with a resource type, and you do not use the name attribute:
<resource id="ID" type="ReType"/>
For example: <resource id="C" type="CONCEPT"/>
See Table 45, Resource Types and Action Types for a list of resource types, and the action types that are valid for each resource type.
Defining Permissions
By default, all permissions are denied. If a certain permission is not explicitly given to a role, then the role does not have the permission. This approach ensures unauthorized users do not accidentally gain access to restricted resources.
Permissions are not hierarchical. That is, a create permission does not imply a modify permission or a delete permission. All privileges are mutually exclusive.
For each resource type there is a predefined set of action types such as create, read, modify, and delete (see Table 45, Resource Types and Action Types). For each resource ID defined in the resources section, you must grant permission separately for each action type. For example, you would add four permission elements to give a user role permissions to create, read, modify, and delete a specified group of resources of a certain type.
Defining Permissions for Domain Models
In addition to permissions to work with a resource, you can also create permissions to work with that resource’s domain model. Domain models are used only with resources of type PROPERTY.
The method is the same as for permissions to use resources. To specify that the permission is for domain models, and not for the resources themselves, you use the permission type, DOMAINMODEL.
Just as you create a set of permissions of each type that defines what a user role can do with the resource itself, you create a set of resources that defines what a user role can do with the domain model for the resource. For example, the following gives broad permissions for a user to work with all resources of type PROPERTY:

 
<permission reref="#PR">
   <action type="create">ALLOW</action>
</permission>
<permission reref="#PR">
   <action type="modify">ALLOW</action>
</permission>
<permission reref="#PR">
   <action type="delete">ALLOW</action>
</permission>
DOMAINMODEL Permission Type
<permission reref="#PR" type="DOMAINMODEL">
   <action type="read">ALLOW</action>
</permission>
<permission reref="#PR" type="DOMAINMODEL">
   <action type="create">ALLOW</action>
</permission>
<permission reref="#PR" type="DOMAINMODEL">
   <action type="modify">ALLOW</action>
</permission>
<permission reref="#PR" type="DOMAINMODEL">
   <action type="delete">ALLOW</action>
</permission>