Specialized Administration > Ensuring Data Security > Access Control > Using Dynamic Roles to Centralize the Administration of Access Control Rules
Using Dynamic Roles to Centralize the Administration of Access Control Rules
When you create an access control rule, you can select the type Role or All in the Find Participants window that you open from the New Access Control Rule window of the Policy Administration window to search for roles. You can select a pseudo role, a context team role, or an organization role as the participant in an access control rule. The context team and organization roles are dynamic roles that map to the system groups that are maintained for the context and shared teams in which the roles are used. The ACLs affected are those ACLs associated with domains within application contexts that are descendants of the domain for which the rule is defined.
For information about system groups, see About Roles and Groups.
To set up a dynamic roles example, assume that there is a context team role named Tester. From the New Access Control Rule window when creating an access control rule in the Site or organization contexts, open the Find Participants window and select Role or All from the Types menu. Enter “Tester” in the Name field and click Search. Choose the Tester role in the Search Results table. Click OK to return to the New Access Control Rule window. The rule that is created applies to members of the Tester role in any context team in which a domain defined in the context inherits from the domain selected for the rule. In this example, assume that the domain hierarchy for the Sales library is as follows:
Then the policies created in the /Default/PDM domain of the Bike Company organization context are inherited by the Sales library (and any other domain in which the parent domain is /Default/PDM).
With the domain structure shown in the previous example, you could choose to create a common set of access control policy rules in the Bike Company organization context using the /Default/PDM domain and the dynamic roles available in the search results of the Find Participants window, including one for the Tester role that grants members of this role Full Control for all testing documents in all states. Since the Default domain associated with the Sales library inherits the access control rules from the /Default/PDM domain of the Bike Company organization context, then those members in the Tester role in the Sales library automatically have Full Control for all testing documents in all states associated with the Default domain of the library.
Dynamic roles are available in the Policy Administration utility in all contexts; however they are only useful when consolidating the administration of policy rules from either the Site or organization context. If you duplicate the rules, the duplicates will be merged when calculating the ACLs for the application context domains and the objective of central management will not be achieved.
* 
If you choose to establish access control policy rules that use dynamic roles in either the Site or organization contexts, then be sure to set up application context templates for the creation of products, libraries, projects, and programs that do not duplicate those rules.
You can also include policy rules that use dynamic roles for participants in organization context templates. Organization context templates must be created from the Site context. For information about using dynamic roles in templates, see Using Dynamic Roles.
Was this helpful?