Customizing Security Labels
There are two types of security labels available in Windchill: custom security labels and standard security labels. For both standard and custom security labels, a security label always has a null, or unrestricted, label value and can have one or more additional label values. These non-null label values can be defined to allow access only to users who are cleared for that label value. Cleared users are called authorized participants. Security label values that clear all users can be used as purely informative markings.
Standard security labels have a pre-defined set of a null and one or more non-null values established when the standard security label is configured. When applying a standard security label to an object, a user selects the null or one of these pre-defined non-null values from a drop-down list. Each object can have only one value applied for each standard security label configured. If the standard security label is configured to be multi-valued, then more than one value can be applied.
Custom security labels do not have a pre-defined set of values. When applying a custom security label to an object, a user enters a value for the custom security label into a text field or leaves the text field blank to specify the null value. The set of custom values may be too numerous or complex to pre-define, or may originate outside of Windchill. You can customize how the custom security label values are translated between the external display value in the text field and the internal value stored in Windchill. In addition, you can customize how the authorized participants are determined for each security label value on either a custom or standard security label, and how the participants that are allowed to modify each security label value are determined.
The use of these customizations allows you to link your Windchill system to another system that may contain user data to determine if a participant is cleared for a security label value. For example, your company may collaborate with other companies using a separate non-disclosure agreement (NDA) for each company interaction. After a user agrees to the NDA, the user is automatically added to a corresponding Windchill group that represents participants in that NDA. Since some of the interactions are between multiple companies, a user needs to be a member of every NDA group involved to have full access to all Windchill data in the collaborative product.
To set up this scenario to work well with security labels, a custom security label can be implemented that allows values that can represent multiple NDA groups rather than the configured list of values offered with standard security labels. You can also use a custom evaluator to determine if a participant is a member of every group required to access an object. For example, a collaborative product has been set up between your company and two others: Company A and Company B. A user must be a member of both the NDA group for Company A and the NDA group for Company B to be able to access an object in the collaborative product. The object in the product has a custom security label applied called Third Party Proprietary with the value of CompanyA,CompanyB. Custom security label values are entered as text strings in a text box provided in the user interface by users who are able to modify the security label value. Custom security labels can also be set using object initialization rules.
 |
The security label could have been defined as a standard label with pre-defined values CompanyA, CompanyB, and CompanyA-CompanyB. However if your company works with many companies and the list of companies changes, it may not be practical to pre-define all of the companies and combinations of NDAs that could apply to a particular object.
|
The authorized participants for the Third Party Proprietary custom security label are determined using a custom evaluator class. When a user tries to access an object with the Third Party Proprietary label applied, the custom evaluator class searches to find out if the user is a member of the appropriate groups associated with the security label value applied and then returns either a true or false value to specify if the user is cleared for the security label and can subsequently access the object.
The custom evaluator class can also be used to determine which participants are able to modify the security label values applied to an object. There may be a case where a user is not familiar with the contract between your company and Company A, so you do not want that user to modify the Third Party Proprietary security label settings on an object. You may want to prevent users from changing the security label value of an object based on the life cycle state of the object. For example, you could create a custom evaluator that restricts value modification for objects in the Released state. Using the custom evaluator class on either a custom or standard security label, you can specify which participants are able to modify a particular security label’s values.
The following customizations can change how security labels work:
• Including a custom security label in the securityLabelsConfiguration.xml file.
• Converting between the external and internal custom security label values using a custom translator class.
• Specifying the participants authorized for the security label value and those who can modify the security label value using a custom evaluator class.
|
|
The custom evaluator class can be used for both standard and custom security labels.
|
 |
When implementing custom evaluator and translator classes, performance may be impacted as methods in the custom classes will be called frequently by Windchill. If you are setting up a call to an outside system, for example, you may consider caching the returned values to improve performance on subsequent method calls.
|
Information about security labels is available from the following topics: