Access Rights Can Originate From Multiple Contexts

To guarantee multi-tenancy, in other words, water-tight data ownership and hence IP asset protection from one P&O ecosystem to another, a person must be set up in a specific manner.

A person:

• does not belong to a specific solution (Team (RACE) or VPM) when created
• may be assigned to one or more security contexts defined for a given role, organization and project, represented by a sphere in the following illustration
• originally, always worked within a P&O ecosystem computed from all the access rights which were derived from all the security contexts to which the person is assigned, irrespective of the solution
• can work on PLM objects belonging to only one sphere at a given time
• may use all access rights via assignment at any time.

A user can be assigned by the ENOVIA V6 administrator to more than one security context. When this is the case, originally, the access rights of the user were based on the total of all access rights granted by all the different security contexts to which the user was assigned, as illustrated below:

The coexistence of Team and VPM solutions means that access rights granted have evolved: the solution (Team or VPM) associated to the current security context determines which logic is used.

When a user connects using a security context for the Team solution, only the secured commands that are granted to the current security context or one of its components (role, organization or project, role being the only case in practice for Team) are authorized.

Secured commands granted to the user via other security contexts, roles, organizations and project, whatever their solution, are NOT authorized. This includes commands granted to other Team security contexts with separate roles, organisation and project, as well as VPM security contexts.

For example, let's suppose you create User1 and assign this user to the following security contexts:

VPLMDesigner.Company Name.Engineering (VPM solution)
VPLMCreator.Company Name.DemoDesign (Team solution)
VPLMProjectLeader.Company Name.DemoDesign (Team solution)

User1 then connects to the rich client using security context VPLMCreator.Company Name.DemoDesign applicable to the Team solution, and selects the command PLM Access > Import > 3D XML....

Access is denied because the current security context for the Team solution does not authorize access, and the following message is displayed:

You are not allowed to performed this operation. 
Please contact your administrator.

When a user connects using a security context for the VPM solution, all secured commands that are granted via all the security contexts to which the user is assigned, as well as their components (role, organization or project) are authorized, but those granted to roles belonging to the Team solution are NOT authorized.

Note: This applies only to rich client applications, not to web (CBP) applications.

For example, let's suppose you create User2 and assign this user to the following security contexts:

VPLMReviewer.Company Name.Engineering (VPM solution)
VPLMProjectLeader.Company Name.DemoDesign (Team solution)

User2 then connects to the rich client using security context VPLMReviewer.Company Name.Engineering applicable to the VPM solution, and selects the command PLM Access > Import > 3D XML....

Access is denied because the selected command is only available for the Team solution security context: only secured commands that are granted on VPM security contexts are available when connecting to solution VPM, and the following message is displayed:

You are not allowed to performed this operation. 
Please contact your administrator.

But in the following example, access will be authorized. Let's suppose you create User3 and assign this user to the following security contexts:

VPLMReviewer.Company Name.Engineering (VPM solution)
VPLMDesigner.Company Name.DemoDesign (VPM solution)

User3 then connects to the rich client using security context VPLMReviewer.Company Name.Engineering, and selects the command PLM Access > Import > 3D XML....

This time, access to the command is granted because secured commands that are granted to all VPM security contexts are available when connecting to solution VPM.

In the following illustration, the person J.Doe (1) may work as designer as member of team3 on the project ship. The assigned P&O working ecosystem (2) will allow the usage of granted PLM applications and resources (3) required to perform tasks and assigns to John Doe the access rights (4) to query and author PLM data and functions within the ship (5):

Note: in the Resource section (3) of the illustration, only the PRM (Project Resource Management) component is supported in this release.

The top row of the table represents all the different security contexts.

The left column of the table presents the ownership vector, based on the Projectid and Orgid attributes.

The corresponding box in the table presents all the operations that can be performed, depending on the data ownership attributes.

For example, a user who logs on using the security context:

VPLMLeader.MyCompany.Standard

where:

Projectid=Standard
Orgid=MyCompany

can perform all the operations in the box in red in the table partially illustrated below:

The figure below presents a simplified view of the different roles and specifies which type of data access is applicable to each role:

The above illustration demonstrates that:

• a person using the Administrator role is granted access to all functions and all data
• a person using the VPLMDesigner role is granted access to data owned by the current project
• a person using the VPLMLeader role is granted access to data owned by the current project, and to the person’s own data
• a person using the VPLMReviewer role is granted access to data owned by the current project, and to the shared (approved) project data.

The type of access to the data is governed by the policy according to the state in which the data is.