Implementing Security on Instances

The basic P&O and Security scheme has been extended to enable VPLM access control on PLM instances (which were previously totally unsecured) to complement access control provided on PLM References.

PLM instances are implemented as ENOVIA V6 relationships. As such, they can only be secured using ENOVIA V6 rules - as opposed to other PLM types, such as references or connections that are implemented as ENOVIA V6 business objects and are thus secured using ENOVIA V6 policies.

The only main difference between policies and rules is that the latter do not support state-specific security - which isn't a problem since PLM instances have no life-cycle. However, rules make it possible to define user-, role- or security context-specific privileges, conditioned by filters that can be based on either the current user (e.g. identifier and/or assigned security context) or the PLM data itself (e.g. ownership attributes).

The mechanism is implemented via ENOVIA V6 rules on ENOVIA V6 types/relationships/interfaces mapped to VPLM instances, to allow the following access control types on VPLM instances:


  • Read
  • Expand
  • Create
  • Modify
  • Delete.

Generally speaking, the privileges associated to a PLM instance are the same as those associated to the aggregating reference, i.e. a user is authorized to expand a PLM part and read the properties of aggregated instances if that user is authorized to read that part, and to modify and/or delete the assembly and instance properties if that user is authorized to modify and/or delete the part.

The security of PLM instances is coupled to the aggregating PLM reference: the set of available accesses to an instance depend on the lifecycle state of the reference it is aggregated by.

For instance, a reference with state SHARED can only be read but not modified, so an instance aggregated by such a reference cannot be modified either.

Note: Access create can not be conditioned by the state of the parent reference, as is the case for all other accesses, because at the time the access check is performed, the relationship object has no "from" object yet.

The following diagrams illustrate how a skateboard, modelled in the VPLM world, is mapped to the ENOVIA V6 types/relationships/interfaces model.

VPLM World

This is the VPLM view of the skateboard:



ENOVIA V6 World

And this is how the same VPLM instance is represented in the ENOVIA V6 types/relationships/interfaces model:



From the following diagram, we can see how the overall security mechanisms all fit together:


  • policies govern access to PLM References
  • rules govern access control to PLM Instances via ENOVIA V6 relationships/interfaces



A Simple Example: Expand Operation

For illustration purposes, the following diagram concentrates on one instance and shows how a typical access control rule is expressed first of all using a natural VPLM language, then in the language used in ENOVIA V6 rules.

Warning: the syntax of the rule in this diagram is for illustration purposes only.

The PLM instance to be expanded is Instance left wheel.

Expressed in natural VPLM language, expand access for the different roles could be something like this:

Expand access to the left wheel is granted:


  • to Designers working for project Standard, if:

    wheel reference.V_maturity = PRIVATE and 
left wheel instance.owner = current user and 
left wheel instance.V_project = ‘Standard’

    or:

    wheel reference.V_maturity in 
{IN_WORK,WAITPP,SHARED} and left wheel 
instance.V_project = ‘Standard’

  • to Leaders working for project Standard if:

    left wheel instance.V_project = ‘Standard’

  • to Reviewers working for project Standard if:

    wheel reference.V_maturity = SHARED and 
left wheel instance.V_project = ‘Standard’

Expressed in the form of a rule in ENOVIA V6 language, expand access for the different roles could be something like this:

add rule VPLM_EXPAND

 user VPLMDesigner

   Read,Show

   filter “((to.current == ‘PRIVATE’) && (owner == 
   context.user) && (attribute[V_project] == ‘Standard’)) || 
   (((to.current == ‘IN_WORK’) || (to.current == ‘WAITAPP’)
   || (to.current == ‘SHARED’)) && (attribute[V_project] == ‘Standard’))“

 user VPLMLeader

   Read,Show
      
   filter "attribute[V_project] == ‘Standard’"

 user VPLMReviewer

   Read,Show

   filter “(to.current == ‘SHARED’) && (attribute[V_project] == ‘Standard’))“