About Security Masks

For any content, users need to perform the operations in the table below. The apps use views to execute the operations. You can define masks that define additional access controls for the content for specific operation views. For example, a field can be editable in the create view, but not the edit view.

Masks define access to attributes for an entity for operation views, where the entity is the type of content. Masks are associated to credentials, roles, collaborative spaces, or organizations. Masks also let you customize attribute characteristics such as default values and authorized or help values.

The DEFAULT mask meets the majority of security purposes. This mask is not associated with any set of credentials. The DEFAULT mask lists the entities (objects) controlled by the mask. It is always active, it cannot be replaced by another mask, and it MUST NOT be deleted.

Any entity not defined in this mask are not masked: all their attributes are visible and accessible. You can create additional masks as required for your business processes.

When you define masks, create a separate mask for each entity type to make maintaining the masks easier.

You can create masks for these pre-defined access operations on attributes:

• Create
• Query
• EZQuery
• Read
• Write
• Tree

You can use these tools to generate your own masks:

• VPLMPosMaskGenerator: generates a .mask file from metadata files and inherited mask files.
• VPLMPosMaskCompiler: compiles mask files and generate a .SecurityMask file.

Use a .mask file to define the mask. The VPLMPosMaskGenerator tool *** and the VPLMPosMaskCompiler tool converts the human-readable .mask files into .SecurityMask files used by the apps, store in the server installation directory path.

The static model describes entities, attributes and relationships. Data structures are defined by metadata files, and are complemented by public mask definitions. Masks definitions perform these functions:

• Set default values
• Set authorized values
• Override structure characteristics (mandatory)

A security mask extends the static model by adding or overriding attribute definitions.

The dynamic model describes behavioral aspects. A security mask manages entity attributes usage (the attribute is visible or not) and access (the attribute is modifiable or not). The dynamic model includes a policy that implements these items:

• Lifecycle specification, with states and branches
• Security specifications with object accesses, depending on states
• Additional characteristics such as Store, Version sequence, formats, and so on

This diagram describes the inheritance tree of a customized entity MyCustoProductRef (defined in MYCUSTO metadata file) up to the common base entity PLMEntity (defined in PLMABSTRACT metadata file) going through the modeler (here PRODUCT) and PLMCORE layers:

Security masks can be defined for the entities and attributes of the:

• Modeler layer
• Customization layer
• Applicative extension layer

A security mask on customized metadata is required since there is mask inheritance at runtime. No mask is defined on the upper layers.

A security mask on modeler metadata is useful for these items:

• Modeler entities that are not customizable (not CAA_Derivable and not Abstract in metadata) but can either be extensible or not.
• Any extensions of such non-customizable modeler entities. A security mask defined on an extension only affects the attributes of that extension and not the attributes of the extended modeler entity. The app combines the two masks to display the views for an extension.
• Modeler entities that are "usable" types (as compared to "authoring" types) in an environment, using the READ, QUERY, and EZQUERY operations.
• Any customized entities. You can incorporate the mask defined on the inherited modeler attributes when using the VPLMPosMaskGenerator mask file generator tool.

The client runtime can use any new (customized) entities even if no mask is defined. A mask is computed on the fly on the client side for each new entity, as if a mask had been generated and compiled using the mask tools on the server side. The client-side mask concatenates the parent entity's mask (if it exists) with a mask computed from the entity's own attributes according to their IP Protection. For the Tree mask, the resulting mask is the parent's Tree mask (if it exists).

You can define a mask for an entity to inherit the definition from a parent entity. This mask definition is completed at runtime by the mask defined on the parent entity. This runtime computation is done on the fly on the client side when necessary.

In all views defined by the mask, the attributes are ordered according to the entity hierarchy, beginning with the top most entity (for example, attributes of entity P will appear before attributes of entity T in all views).

Use the @Inherits annotation with the ENTITY command to specify that this particular entity inherits from its parent entity's mask. The inheritance capability applies at the entity level inside the corresponding package (the source mask file) for all the defined views. When the mask definition of an inheriting entity T is used on the client side, the mask of its parent entity P, is searched to complete this mask definition.

By default, a mask stands on its own (no inheritance) unless you add the @Inherits annotation to the entity definition. A local mask includes the mask for the specific entity, and its parent entities. Specifically:

For local mask definitions, add the @Inherits annotation at the end of the ENTITY declaration line and remove all attribute declarations ATTR/FATTR referring to an inherited attribute. Any ATTR/FATTR declarations for an inherited attribute override the ones defined in the parent's mask (except for the order).