Implementing Security Filters

Security authorizations restrict the access to PLM instances depending on the characteristics of these instances or on those of the aggregating or aggregated references.

A number of macros implemented in default policies and rules provide a higher degree of security in the following areas:


  • relationship ownership: ownership attributes
  • multiple access.

Ownership Attributes

Relationship ownership is an enhancement to the ENOVIA V6 core software that integrates three ownership attributes:


  • owner (user)
  • altowner1 (organization)
  • altowner2 (project).

directly into relationship objects, as was already the case for business objects in earlier versions.

By taking advantage of this capability, it is it possible to define filters that are based on these ownership attributes in relationship rules, thus restricting access to PLM instances.

For instance, the default security authorizations applying to PLM instances use organization- and project-based filtering that restricts access to data belonging to the organization and project of the user, i.e. the organization and project of the security context that is assigned to the user.

This mechanism enables the VPLM administrator to distinguish between role, organization and project when setting access rights:

The explanation of the following concepts uses a consistent example:


  • Bill, as designer, must only create objects in the project he is working for (the project specified at login time)
  • Bill, as Reviewer, is not authorized to create or modify objects



The expected result is as follows:


  • Bill when using Ctx::Designer.team2.prj1 is authorized to create objects in prj1
  • Bill when using Ctx::Designer.team1.prj2 is authorized to create objects in prj2
  • Bill when using Ctx::reviewer.team1.prj3 is NOT authorized to create objects.

The enhancements to the filtering mechanism allow you to achieve this result.

List of Macros Implemented

The following examples illustrate the use of new macros in filters to provide a higher degree of security in access to PLM objects:


  • $CHECKEDUSER: the user being checked, meaning the security contexts assigned to the user matching $RULEUSER and currently used for evaluating the filter
  • $CHECKEDUSER.PRJ: the project of the user being checked
  • $CHECKEDUSER.ORG: the organization of the user being checked
  • $CHECKEDUSER.ROLE: the role of the user being checked.

The following illustration shows:


  • three security contexts to which a user is assigned
  • two filters, one applied to the Designer role, the other to the Reviewer role.

Note: The syntax of the filters in all the following illustrations has been voluntarily simplified for illustration purposes. For example, only some of the macros specified in the explanatory text appear in the filters in the illustration.



Creation Example

This is an example of how security can be implemented using the macros at creation time:



Modification Example

This example shows how modification is secured according to role and project ownership (using the altowner2 attribute):



Multiple Access

Before, because it was not possible to specify multiple accesses for a single user, all accesses were secured the same way.

For instance, object modification and ownership transfer were governed by the same security rules, which means that if a user was authorized to modify an object belonging to the project the user was working on, the user could also transfer the ownership of that object.

One might consider it safer or more sensible to only authorize ownership transfer if the user is also the owner of the object, in which case a particular check must be made for that operation.

Multiple access is an ENOVIA V6 core software security mechanism that provides the capability to specify separate access filters for each secured operation.

The keyword $ACCESS has been added to the grammar supported by filter expressions used in policies and rules: it is automatically substituted to the security access being checked (read, show, etc.) by the kernel when determining if the current user is authorized to operate on some object.

It thus makes it possible to define access-specific expressions in filter expressions, i.e. define distinct criteria for separate accesses.

As a consequence, the accesses can now be defined like this:

user VPLMDesigner

read, show, create, delete, modify, promote, demote, 
grant, revoke, changename, changeowner, changetype,
checkIn, checkOut, lock, unlock, fromconnect, 
fromdisconnect, toconnect, todisconnect

filter "(((altowner1 == '' && 'MyCompany' match 
context.role.ancestor) || altowner1.ancestor[MyCompany])
&& ((altowner2 == '' && 'Standard' match context.role.parent)
|| altowner2 == 'Standard')) && (('$ACCESS' != 'changeowner')
|| (owner == context.user))"

in order to illustrate the particular case of ownership modification presented above.

Here, an extra criterion is added in case the security access being checked is changeowner, which is the kernel security access used to secure ownership transfer: the current user must be the owner of the object being checked; if the access is anything other than changeowner, the criterion is ignored.

Note: in order to be interpreted correctly by the security infrastructure, keyword $ACCESS must be enclosed in single or double quotes.