Using Dynamic Roles in Access Control Rules
Dynamic roles represent the system groups that are created for the roles assigned to team members in context teams and shared teams. The system groups created in an application context representing the organizations that have members in the context team.
Dynamic roles can be selected for access control rules:
• In the site context, the dynamic roles are available when creating access control rules using the Policy Administration utility. These dynamic roles consist of a context team role for each role defined in the wt.project.RoleRB.rbInfo file. In the site context interface, you cannot create additional context team roles; however, as part of a customization, you can change the content of the wt.project.RoleRB.rbInfo file.
For information on modifying the content of .rbInfo files, see Best Practices for Customizing Files Supplied by PTC.
• In an organization context, the dynamic roles are available when creating access control rules using the Policy Administration utility. These dynamic roles consist of the context team roles for the roles that are set as visible in the Roles table from a given organization context.
The initial set of roles that are visible in the Roles table from a given organization context is inherited from the site context. In an organization context, organization administrators can add, delete, show, and hide the context team roles displayed in the Roles table. Therefore, they can manage the set of context team roles that display when the Policy Administration utility is launched from the organization context.
For more information, see #PolicyAdminDynamicRolesAbout/ExampleUser.
• In both the site and organization contexts, the dynamic roles consist of organization roles that represent the system groups that may be created in application contexts. The organization roles represent the organizations that have members in the context team. When creating an access control rule, the organization roles for the organizations to which you have access are available. Organization roles are automatically created; you cannot create additional organization roles.
For more information, see #PolicyAdminDynamicRolesAbout/ExampleWC.
• In an application context, the dynamic roles that are available when creating access control rules using the Policy Administration utility consist of the context team roles that are shown in the Members table on the Team page. When creating an access control rule from an application context, there are also dynamic roles that consist of organization roles. These organization roles represent system groups created in the context for each of the organizations that has members in the context team. From these organization roles, those for the organizations to which you have access are available.
Use the dynamic roles established in site and organization contexts to create general access control rules. These rules can be inherited by application contexts for all users who are added to a team in a specific role or from a specific organization.
 |
Access control rules created for dynamic roles only apply to objects that belong to the domains that reside in application contexts. This is because the roles are only used with context teams. Site and organization contexts do not have associated context teams. Therefore, rules created for dynamic roles do not apply to objects residing in domains in these contexts.
|
Example: User-Created Role
Assume that you have a group of people who write all of the specification documents for an organization. You want to grant this group of people the rights to read, download, modify content, modify, create by move, and create, all documents. To accomplish this task for the Demo Organization, you can do the following:
1. Create a new Spec Writer role from the Roles table in the Demo Organization context.
2. Launch the Policy Administration utility from the Utilities page in the Demo Organization context.
3. From the Domains pane, select the Default domain.
4. From the Access Control Rules tab, click the create new access control rule icon 
.
.5. From the New Access Control Rule window, select the following:
Field | Value to Select | ||
|---|---|---|---|
Type | Select Document. | ||
State | Select All. | ||
Participant | In the Participant field, search for Spec Writer. Spec Writer (Context Team Role - Demo Organization) displays in the Participant field. | ||
Permissions | Select Read, Download, Modify, Modify Content, Create By Move, and Create in the Grant column.
|
6. Click OK to create the rule.
The rule for the Spec Writer dynamic role is now created in the /Default domain that is associated with the Demo Organization context. All domains that are descendants of the /Default domain inherit this rule. By default, the descendant domains include the PDM, Project, and shared team domains that are used when creating non-private application contexts and shared teams. Therefore, the /Default domain within any application context that has a team that uses the Spec Writer role and that was created for a non-private application context or as shared team will automatically inherit the Spec Writer access control rule.
Creating and managing access control rules in site and organization contexts where dynamic roles are selected as the participants can help centralize the administration of access control rules. From within an application context, dynamic role participants are treated as if they are the system groups associated with corresponding context team roles and organization roles. If there are access control rules set for a context team system group and access control rules set for a corresponding dynamic role, then the rules are merged when determining the policy access control list (ACL) within a specific domain and for a specific type and state. For example, assume the following:
• The access control rule for the Spec Writer dynamic role has been created as described in the earlier example.
• The Super Bike project has been created with an access level other than the default Project Members Only under the Demo Organization and uses the standard /Default domain. The domain hierarchy for the /Default domain includes as a parent the /Default domain associated with the Demo Organization where the access control rule for the Spec Writer dynamic role was created.
• The Spec Writer role has been added to Super Bike project.
Then the ACL generated for the Spec Writer system group in the Super Bike project includes the permissions granted through the policy rule that was created for the Spec Writer dynamic role in the Demo Organization context. The Spec Writer system group could also have other policy rules and ad hoc rules created from the Super Bike project. If there are other policy rules, all policy rules (including the rule set for the Spec Writer dynamic role) are merged. For additional information about domains and domain hierarchies, see Administering Domains and Policies.
| | To effectively use access control rules that are created in the site and organization contexts for dynamic roles, you should review the access control rules set in the organization and application context templates that are used to create the contexts. Determine what changes should be made to those templates so that the rules set for dynamic roles are not duplicated in the templates. You can load example dynamic role templates that set a number of access control rules for dynamic roles using an organization template. The rules are then used in application contexts that are created from example dynamic role product, library, and project templates. For more information on the example dynamic role templates, see Using Dynamic Roles. |
Example: Windchill-Created Organization Role
Assume that you have two organizations — Sales and Manufacturing. You also have two products — Beach Umbrella and Sport Umbrella. You have six users divided among the organizations and products as illustrated in the following table:
User | Organization | Product |
|---|---|---|
Pat | Sales | Sport Umbrella |
Paul | Sales | Sport Umbrella |
Pam | Sales | Beach Umbrella |
Dawn | Manufacturing | Beach Umbrella |
Dave | Manufacturing | Beach Umbrella |
Debbie | Manufacturing | Sport Umbrella |
Windchill creates the following system groups and corresponding organization roles for the Sport Umbrella product:
Group | Members | Organization Role |
|---|---|---|
Sales | Pat, Paul | Sales |
Manufacturing | Debbie | Manufacturing |
Windchill creates the following system groups and corresponding organization roles for the Beach Umbrella product:
Group | Members | Organization Role |
|---|---|---|
Sales | Pam | Sales |
Manufacturing | Dawn, Dave | Manufacturing |
You create a policy access control rule at the Site level granting all users in the “Manufacturing” dynamic role Modify permission on Part objects. This rule is inherited by the domain where parts in the Beach Umbrella product reside. As a result, when a part is accessed in the Beach Umbrella product, the Site-level rule applies to Dawn and Dave since they are members of the Manufacturing system group for the organization. Similarly, when a part is accessed in the Sport Umbrella product, the Site-level rule applies to Debbie. If Dave was also added as a team member of the Sport Umbrella product, the rule would apply to him for parts in that product because he would also be in the “Manufacturing” dynamic role with Debbie.
Related Topics