For each RMS project, you set up an access control file. In the access control file, you group the project resources as desired, giving each group (or individual resource) an ID. Then you use these IDs to assign permissions to each user role.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.See TIBCO BusinessEvents Administration for details on configuring user authentication.
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.The access control file is an XML file named as follows: RMSProjectName.ac. In the access control file resources element, you create resource elements to define groups of resources to suit your needs. You give each resource element an ID. In the entries element, you add one entry element for each user role to define the access permissions for that role, using the resource IDs and action elements. This brief summary is provided so you can understand the following guidelines. For full details. see Structure of the Access Control File.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 exceptionsOne approach is to grant wide permissions using large resource groupings, and then selectively deny permissions within those groupings.<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 using those resources. For example, for a role named CallCenter you might set up permissions as follows: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\CreditCardApplication\configDeny everything and specify exceptionsThe 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 approachesYou 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.
<resources><entries>
• 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 resourceref 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 of resources in the specified name attribute project path are included in the permission.
• The action type attribute specifies an action type, for example, create. This attribute determines the kind of action a user has permission to do, for the specified resource or resources.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.
Copyright © TIBCO Software Inc. All Rights Reserved.