Importing, Restoring, and Loading Objects with Security Labels
The import and data loading actions behave the same with respect to security labels.
No additional permissions are required when importing security-labeled objects, unless the import is being performed with the Modify non-versioned attributes action. In this case, the user must have the Modify Security Labels permission for the object, and be an authorized participant for any security label values that are to be set.
 |
Before performing an import, you should know both the security labels defined on the target system, and the security labels, if any, that were defined on the system that originally exported. The import action does not make any configuration changes on the target system.
|
Security labels are imported even if the security labels feature is disabled on the target system at the time of import.
An object imported from another system has the security label values, if any, that were defined in that system. If the source system did not have any security labels configured, and the target system does have security labels configured, object initialization rules are used to populate the missing security labels. Object initialization rules are also used when both systems have security labels configured and the target system has security labels that were not defined on the source system.
When imported, null security label values remain null. If an exported file has a null value for a security label and that security label is not defined on the target system, the import action skips that label and succeeds without any warning or error messages. The label did not restrict access on the source system, and will not do so on the target system.
If an exported file has a non-null value for a security label and either the security label or the label value is not defined in the target system, the import action fails with an error message indicating that the security label or label value is undefined.
If an exported file has multiple values for a security label and if that security label is not configured to support multiple values on the target system, the import action fails with an error message indicating that the security label does not support multiple values. For the import action to succeed, the security label configuration on the target system should be updated to support multiple values or the security labels mapping should be provided.
For the import action to succeed, the security label and label value must be present in the security label configuration on the target system. Adding the security label and label value to the target system's security label configuration, but leaving it disabled, is sufficient for the import to succeed.
Data with security labels can be loaded using a spreadsheet or a CSV file, or imported using an import file. In each of these cases, the security labels are assigned using the name and value of the security label as specified in the security labels configuration file. If the standard import and data loading functionality is not sufficient for your needs, see the Javadoc for the wt.access.AccessControlManagerSvr interface, which has information on APIs you can use to perform custom loading of security labels, and the Javadoc for the wt.access.ixb.handlers.forAttributes.ExpImpForSecurityLabelsAttr class, which describes the export and import handler for the securityLabels attribute.