Before You Begin Configuring Security Labels
Before you begin configuring security labels for your site, do the following:
• Decide what security labels you want to configure for your site and whether they will be custom or standard security labels. Establish the list of values for each standard security label.
You can have multiple security labels defined for different purposes. To see an object, a user must be cleared for all security label values set on the object.
• Determine who will be the authorized participants for each custom security label or standard security label value, meaning who will be cleared for access to objects when that security label value is applied. Consider also if the authorized participants can be specified using a unique federation identifier (UFID) if principal is in LDAP or WTPrincipalReference if principal is in database or if you will need to write a custom evaluator class to determine which participants are authorized for each custom or standard label value.
If you specify the authorized participant using a UFID, the UFID can specify a user, user-defined group, or organization, but most commonly would be a user-defined group. Using a group as an authorized participant allows you to easily add to or change group membership using the Participant Administration utility, the > page, or a third-party LDAP tool to manage groups within an LDAP directory service.
If you specify the authorized participant using a custom evaluator class, the way the current user is authorized can vary, depending on how you implement your custom evaluator. For example, the custom evaluator could check to see if the user is a member of a particular group, which is similar to using the UFID. Alternatively, the custom evaluator could query a system outside of Windchill that lists the participants cleared for a particular label value.
If the label value is informative only, you can omit the authorized participant to indicate that all users are cleared for the value.
• Optionally, create the necessary groups to be used as the authorized participants.
| When creating user-defined groups, be sure to note the distinguished name of each group, and the directory service in which it is being stored, as this information is needed during your configuration. |
• Decide whether agreements will be enabled for your site. If you are going to enable agreements, you must also:
◦ Create or identify an existing group for agreement managers in the site context. In the example configuration, this group is the Agreement Managers group. Be sure to note the distinguished name of the group and the directory service in which it is being stored as this information is needed during your configuration. You will also need to set access control permissions for the members of the agreement managers group. For more information about setting these permissions, see
Setting Access Control Permissions for Agreement Managers.
◦ If you want more than one type of agreement to be available, create subtypes of the Agreement type. Each custom security label or standard security label value can optionally be associated with one type of agreement. Be sure to note the internal name of each agreement subtype as you will need it during your configuration.
| If you are planning to use context-based agreements, PTC recommends that you create a subtype for both context-based agreements and for standard agreements. This makes maintaining policy access control rules easier for each type as both inherit from the Agreement type by default. |
• Decide whether a download confirmation message displays when users attempt to download object content.
• Decide whether there are certain object types for which you want to hide security labels, so non-null security label values cannot be set. For the list of security labeled object types, access the <Windchill>/conf/exposedSecurityLabelObjects.xml file, where <Windchill> is the location where your Windchill solution is installed.
• Decide whether security label changes should be applied to specified versions of an object or to all versions of an object. For example, if a part exists with the latest version of B.1 and a user launches the Edit Security Labels action on it, by default the security label settings chosen by the user only applies to version B.1 of the part. However, you can change the default using the preference Security Label Changes on Object Versions with the following options:
◦ Always apply to all versions
◦ Always apply to edited versions
◦ Display a check box on the Edit Security Labels page that allows users the option to apply security label changes to all versions of the object. You can choose whether this check box is preselected by selecting the value Display all versions option selected or deselected with Display all versions option not selected. If the check box is selected, then changes to security labels are applied to all versions. If it is deselected, then changes are applied to edited versions.
If security label changes are applied to all versions of an object, changes to policy access control rules may be required. For example, if you have a policy rule in place that prevents modification of objects in a released state, then enabling the property would prevent objects with a version in a released state from being updated.
• Decide whether the Modify Security Labels permission is updatable, read-only, or hidden in permission lists throughout Windchill. This is controlled with the Access Permission Configuration (for Program, Project, Organization, and Site contexts) and Access Permission Configuration (PDM) (for Libraries and Product contexts) preferences. These preferences are managed in the > utility. By default the Modify Security Labels permission is hidden by both preferences.
> page, or a third-party LDAP tool to manage groups within an LDAP directory service.
