Applying Rules in the Policy Administration Utility
Rules against PTC FlexPLM objects must be created against all lifecycle states. PTC FlexPLM does not support lifecycle state-specific access control lists. Rules created against specific lifecycle states cause inconsistent results and are not supported.
If a subtype (or a root type) is going to be set to not instantiable (to make it not selectable in PTC FlexPLM), then it must be added to the wt.admin.hierarchyListAdditions.wt.access.PolicyAccessControlled property to make it visible in the Policy Administration utility.
• Add entries to the site.xconf file and run the command xconfmanager -p.
• Entries must follow this format:
<AddToProperty
name="wt.admin.hierarchyListAdditions.wt.access.PolicyAccessControlled"
value="fully qualified class name"/>
For example:
<AddToProperty
name="wt.admin.hierarchyListAdditions.wt.access.PolicyAccessControlled"
value="com.lcs.wc.planning.FlexPlan"/>
The requirements for policy administration in PTC FlexPLM are stricter than those allowed by the WindchillPolicy Administration utility.
Common Access Control List Rules
These rules are true for both PTC FlexPLM and Windchill PDMLink.
• Explicitly granting or denying an access control list applies to the type and all its subtypes.
Example 1:
◦ Type structure in the Type and Attribute Management utility:
◦ Access rule in the Policy Administration utility:
In this example, read permission is being granted. If this is the only rule created for the Color type, users of the Retail group have view access to both the Color type and LCSColorSubtype1 (because LCSColorSubtype1 inherits the rule from the Color type).
• If you apply a rule to a given principal, and that principal is a group, then the rule applies to all members of that group. If there is a subgroup (a group as a member of a group), then the rule also applies to all members of the subgroups, including all subgroups below them.
In Example 1, all users who are members of the Retail group directly, or are members of subgroups of the Retail group (groups that are members of Retail), have view access to the Color type and its subtypes.
• If a grant rule is not explicitly granted for any particular create, read, update, or delete action for a given type or its parents, it is considered a denial of that access.
In Example 1, only read permission is being granted. Create, modify, and delete are not explicitly granted or denied. If this is the only rule created for the Color type, users of the Retail group have view access to the Color type and LCSColorSubtype1. They do not have create, modify, or delete access to any of the Color types.
• If two explicitly created rules resolve to the same type, any deny rules take priority. An explicit deny rule always overrules an explicit grant rule. For example, for the Color type and LCSColorSubtype1, the Retail group has read access to the Color type. GroupC, a member of the Retail group, is denied read access to LCSColorSubtype1. If a user belongs to GroupC, the user is denied access.
Example 2:
◦ Group and user membership: The Retail group contains groups GroupA and GroupC. GroupA has userA as a member. GroupC has groupA and userC as members.
◦ Type structure in the Type and Attribute Management utility:
◦ Access rule in the Policy Administration utility:
In Example 2, GroupC has explicitly been granted view access to the Color type. There is also a rule denying view access to GroupA members. Even though members of GroupA are granted access to the Color type as members of GroupC (because GroupA is a member of GroupC), they are denied access to the Color type. This is because any explicit deny rule overrules any grant rule. Any other users in GroupC that are not members of GroupA have read access.
Access to Subtypes
In Windchill PDMLink, you can grant access to a subtype if the following apply:
• A parent type has been granted access, and no other rules deny that access (directly to the subtype or any of its parents).
• No specific access has been granted or denied to any parent type for the subtype (for example, null permission) and access is explicitly granted to the subtype.
In PTC FlexPLM, you have access to a subtype if the root type has been granted access, and there has been no explicit deny permissions from the root type to (including) the subtype that would remove permission for the given user
• If you do not have access for each particular create, read, update, or delete action for any given type, then you do not have that access on any subtypes for that type. You must have access to all parent types to have access to the subtype.
• Once a deny rule has been applied, it denies access to the specific type and all subtypes for the type the rule is specified on.
• A grant on subtypes does not add access if a parent type has an explicit deny, even if the parent type’s parent grants access.
Example 3:
• Type structure in the Type and Attribute Management utility:
• Access rule in the Policy Administration utility:
In Example 3, users of the Retail group are explicitly granted view access to the Color type. They are explicitly being denied view access to LCSColorSubtype1. As a result, the users of Retail group have view access to the Color type, but not to LCSColorSubtype1 or LCSColorSubtype2.
Access at the Root Type
Once access is granted at the root type, you can further refine the access using deny rules. Once access has been denied to a given type (as applied to a given user), all the subtypes also have access denied.
Example of a type and group configuration:
This diagram contains a partial type structure on the left. The diagram assumes that the type structure is repeated for the Accessories and Footwear types.
• For the Root/Apparel/Mens type, only the users in Mens Apparel group have access.
• For the Root/Apparel/Womens type, only users in the Womens Apparel group have access.
The type tree has Accessories and Footwear types that are siblings to Apparel, which is not shown in the diagram on the left. These would have similar group rules to the correlating groups. For this example, we are only setting up the permissions for types visible in the diagram and we are only setting up read permission.
To accomplish this in PTC FlexPLM, there are two options:
• Grant permission to the root type to all users who need access to any type in the tree. Create the appropriate explicit deny permissions to restrict access to the subtypes where users or groups should not have access.
◦ Create a rule that grants read permission to the Retail group for the root type. This grant then applies to all subtypes. If the permissions stopped here, access is open for all types to all users of the Retail group.
◦ Create a rule that denies read permission to the Accessories group for the Root/Apparel type.
◦ Create a rule that denies read permission to the Footwear group for the Root/Apparel type.
◦ Create a rule that denies read permission to the Mens Apparel group for the Root/Apparel/Womens type.
◦ Create a rule that denies read permission to the Womens Apparel group for the Root/Apparel/Mens type.
• Create grant rules at the root type to all users that would need access to any of the types or subtypes in the tree. Use “inverse deny” rules to reduce the number of users that have access to each appropriate subtype.
◦ Create a rule that grants read permission to the Retail group for the root type. This grant then applies to all subtypes. If the permissions stopped here, access is open for all types to all users of the Retail group.
◦ Create a rule that denies access to all users except the Apparel group for the Root/Apparel type.
◦ Create a rule that denies access to all users expect the Mens Apparel group for the Root/Apparel/Mens type.
◦ Create a rule that denies access to all users except the Womens Apparel group for the Root/Apparel/Womens type.
| • Both options start with a parent group that contains all the groups that would require access to any type in the structure. ◦ This example uses the Retail group, but that is not strictly required. ◦ Once access is granted to the root, in each subtype the list of who has access is refined through deny rules. There are never any additional grant rules. • Both options take advantage of group organization to minimize the number of rules that need to be created. You are not strictly required to do this. ◦ When creating a rule, you can only select one principal. When creating or using explicit deny rules, if you do not have a good user organization, it is cumbersome to manage the policies by adding individual rules. ◦ In the first option, the Footwear group allowed the creation of a rule that denied access to Footwear. If this group had not been present, two rules would have been created: one to deny access to the Mens Footwear group and another to deny access to the Womens Footwear group explicitly. If there is less organization, more rules need to be created. • The two options differ in users that cross groups. ◦ The first option explicitly denies access to those in a particular group. If a user is in the Mens Accessories and the Mens Apparel groups, and if access is denied to those in the Mens Accessories group, access is denied to that user, even though the user is in the Apparel group. ◦ The second option denies access to those that are not in a particular group. If users are in the group, they continue to have access. If a user is in both the Mens Accessories and Mens Apparel groups, and if access is denied to all groups except the Mens Apparel group, access is not denied to that user, even though the user is in the Mens Accessories group. |
Explicit Deny Example
• Group and user membership:
◦ The Retail group has GroupA and GroupB as members.
◦ GroupA has userA as a member.
◦ GroupB has userB as a member.
• Type structure in the Type and Attribute Management utility:
• Access rule in the Policy Administration utility:
In this example, users of the Retail group (userA and userB) are granted view access to the Color type (LCSColor). GroupA has been explicitly denied view access to LCSColorSubtype1. UserB can view objects of the Color type, LCSColorSubtype1, and LCSColorSubtype2. UserA can view the objects of the Color type, but not any objects that are of LCSColorSubtype1 or LCSColorSubtype2.
Inverse Deny Example
• Group and user membership:
◦ The Retail group has GroupA, GroupC, and GroupD as members.
◦ GroupA has userA as a member.
◦ GroupC has GroupA and userC as members.
◦ GroupD has userD as a member.
• Type structure in the Type and Attribute Management utility:
• Access rule in the Policy Administration utility:
In this example, view permission has been granted to the Color type (LCSColor) for all users in the Retail group (including subgroups). Additionally, permission has been denied to LCSColorSubtype1 to all who are not members of GroupC. This results in userA, userC, and userD being able to view colors on the Color type. Because userD is not a member of GroupC, userD is denied access to LCSColorSubtype1, while userA and userC continue to have view access.
Creating the Access Control List Against the Retail Group
To grant or deny access to all users within PTC FlexPLM, create the access control list against the Retail group (because all PTC FlexPLM users must be a member of this group).
• For example, if you want to grant read permissions to the Color type for all users in PTC FlexPLM, you would create a rule granting read access to the Retail group.
• If you do not want all users in PTC FlexPLM to have access, you would create a rule that is against a subgroup of Retail. This ensures that the users being granted access are PTC FlexPLM users, yet restricts the set of users to those that would be appropriate.
For example, you have a group called Color Users as a member of the Retail group. The access control list granting read permission would be against the Color Users group. This allows only those users to see any Color information.
• If you want to grant access to a root type, but also ensure that no other rules are providing more access than explicitly stated in your rule, you would create a rule that is granting the access you want to grant, and another that is denying access to everyone else.
For example, you might have a rule that grants full control to all users on WTObject.
| This is an example of something you should definitely not do. This would enable all users in the system to have full access to everything, where it is not explicitly denied. |
If, in this scenario you want to create a rule that ensures only Color users have access to colors, you would create two rules.
◦ The first rule would be to ensure the grant always remains, even if the rule against WTObject is removed. So you would create a rule granting read access to the Color Users group.
◦ Additionally, to ensure no other users can access the Color type (through the WTObject grant to all rule), you would create a rule that denies read access to all users except the Color Users group.
◦ These rules combined ensure that no users outside the Color Users group have access to the Color type, no matter what other grants are given.
