Implementing Security on VPLM Application Commands

Once connected to the console, VPLM commands can be retrieved and selected:

Access can be customized by adding or removing:

• P&O contexts, projects, roles or organizations (all these objects are stored as roles in ENOVIA V6)
• Persons.

Access can be customized in the Object Access tab of the Command editor. For instance, if you want to grant the role VPLMDESIGNER.MYCOMPANY.ENGINEERING after the installation:

• remove the access given to [All]

  
  
  

• then add to the command the role VPLMDESIGNER.MYCOMPANY.ENGINEERING which means that access is determined by the policy governing the role.

As with the Business administration console, the Export/Import command accesses can be customized using the modify command order in a MQL script.

If we take the Business administration console example, the equivalent script would be:

set context user creator;
modify command vplm::EXPORT
remove user all
add user VPLMDESIGNER.MYCOMPANY.ENGINEERING;

The keyword user used in the modify command refers to the ENOVIA V6 user. As a consequence:

• remove user all is used to remove the person ALL (equivalent to public access)
• add user VPMDESIGNER.MYCOMPANY.ENGINEERING is used to add access to the ENOVIA V6 role VPMDESIGNER.MYCOMPANY.ENGINEERING which finally corresponds to a P&O security context.

Command access is determined during the login phase according to the following logic:

Command access checking is deployed in the VPLM commands listed below.

vplm::EXPORT is deployed in the following user commands:

• 3DLive Export (for review)
• VPM Navigator Export (export briefcase, export for authoring)
• Export Batch (export briefcase)
• VPM Editor Export (igs, stp)
• Downward Compatibility Batch.

vplm::IMPORT is deployed in the following user commands:

• Import file (igs, stp and multicad dxf, prt, asm, …)
• Import CATIA File (FBDI)
• Import 3DXML (briefcase import).

From the end-user point of view, command access checking results in either a granted access, or a revoked access:

• when command access is granted to the user, no feedback is visible from the VPLM application
• when command access is not granted to the user, the following message is displayed:

  You are not allowed to do this operation. Contact your administrator.

When attempting to export or import, the message is displayed when the user clicks on the Export/Import button.

When running a batch, the message is displayed when the user executes the batch from Batch Monitor dialog box.

Access may be granted to a P&O role, organization or project directly connected to a P&O context. However, access propagation along P&O role/project/organization hierarchies to the P&O context is not supported.

For example, in the following illustration:

access to a VPLM command may be granted to:

• user1
• the VPLMDESIGNER.MYCOMPANY.STANDARD security context
• the VPLMDESIGNER role
• the MYCOMPANY organization
• the STANDARD project.

In these cases, User1 will have access to the command.

But granting access to a VPLM command to the BASIC DESIGNER role is not useful since this role is not directly connected to a context, even though it belongs to the hierarchy of the DESIGNER role.

By default, the commands are not assigned to "Public" (all users) and so they will not be available until you assign them explicitly (previously, all commands were by default assigned to "Public" (all users)).

For information, here is the table of secured commands, and the roles granted:

Note: The application server must be restarted after modifying command accesses.