Resources for Controlling Access to Content

Policies, rules, filters, and expressions are types of security data that define who can access content. You can customize and create security data, including object-specific access, access grouping, and access inheritance.

You can define additional security data using these tools:

VPLMPosImport batch administration tool (to import data)
MQL commands (to author security data)

MQL is the recommended tool to author security data.

This page discusses:

Policies
Rules
Filters
Expressions

Policies

Policies define the rules that govern business objects, such as who has access to an object, what levels of access are available, and when access is permitted. Policies define the lifecycle of objects and the conditions required to move through the stages of its life. The 3DEXPERIENCE platform installs the policies that govern all types of content.


	Name	Description
Policies that govern objects	Web-app specific policies	Policies that govern each business object type.
	VPLM Project Template	Governs Project Template objects
	VPLM_PRIVATE	Governs private PLM types
	VPLM_PosResourceRef	Governs P&O Resource reference objects
	VPLM_PosResourceRep	Governs P&O Resource representation objects
	VPLM_Replication	Governs replication objects
	VPLM_SMB_VS_ActivateDeactivate	Governs configuration dictionary object
	VPLM_SMB_WorkspaceRootRef	Governs Design Workspace root reference object
	VPLM_SR	Governs Semantic Relationship objects
	VPLM_UNSECURED_CX	Governs unsecured connection objects
Policies that govern rules	VPLM_SMB_INSTANCE	Sample custom instance objects
	VPLM_UNSECURED_REL	Unsecured relationships
	VPLM_SMB_UNSECURED_INSTANCE	Unsecured instance objects
	VPLM_SMB_DocumentCheck	Attribute "V_CheckedOutUser"

These policies govern PLM types defined in the PLM model can be used as is and require no further customization:

PLM Connection
PLM Product
PLM Representation
PLM Port

These rules govern PLM instances:

PLM Representation Instance
PLM Product Instance

The policies listed above do not enforce strict locking. Unlock is secured as all other accesses: no check is made to prevent users from unlocking data they did not lock themselves.

You can implement strict locking by adding this expression to the relevant policy filters:

('$ACCESS' != 'unlock') || (lockedby ==context.user)

This expression tests that the lock user is the same as the current user when trying to unlock an object.

Rules

The installation loads a default rule: VPLM_SMB_INSTANCE. This rule contains several filters for role and key combinations and can be viewed using MQL. Other rules are also installed.

Filters provide the principal credentials and define the security for access to instances for all states. If you create new roles, you need to add the role to any approrpriate rules. For example, rule VPLM_SMB_DocumentCheck should be modified for a new role VPLMManager as follows:

modify rule "VPLM_SMB_DocumentCheck"
user "VPLM_SMB_DocumentCheck"
all;

Filters

Macros defined in policies and rules provide specific security based on the relationship ownership of objects. You can define different filters for different access operations (multiple access control).

Ownership Attributes

Relationship ownership integrates three ownership attributes:

owner (person)
altowner1 (organization)
altowner2 (collaborative space)

You can define filters based on these ownership attributes in relationship rules to restrict access to instances. The credentials (role-organization-collaborative space) assigned to a user determines that user's access to instances. The administrator can distinguish between role, organization and project when setting access rights.

For example, Bill is assigned these sets of credentials:

Ctx::Designer.team2.CollabSpace1
Ctx::Designer.team1.CollabSpace2
Ctx::Reviewer.team1.CollabSpace3

This table shows Bill's access based on his login credentials:


Login Credentials	Create Access
`Ctx::Designer.team2.CollabSpace1`	Bill can create objects in `CollabSpace1`
`Ctx::Designer.team1.CollabSpace2`	Bill can only create objects in `CollabSpace2`
`Ctx::Reviewer.team1.CollabSpace3`	Bill cannot create objects in any collaborative space

Macros

You can use these macros in filters to define access:


Macro	Description
`$CHECKEDUSER`	The credentials assigned to the user matching `$RULEUSER`
`$CHECKEDUSER.PRJ`	The collaborative space of the user
`$CHECKEDUSER.ORG`	The organization of the user
`$CHECKEDUSER.ROLE`	The role of the user

Continuing the example, Bill is assigned these sets of credentials:

Ctx::Designer.team2.CollabSpace1
Ctx::Designer.team1.CollabSpace2
Ctx::Reviewer.team1.CollabSpace3

This rule is defined for the Designer role:

user Designer read,show,create
filter $CHECKEDUSER.PRJ match context ...

This rule means that a person with the Designer role can read, show, or create the content type, if they meet the criteria of the filter. The filter compares the collaborative space they logged into (indicated by the PRJ) with the collaborative space where they're trying to execute the command.

This rule is defined for the Reviewer role:

user Reviewer read,show

If Bill logs in using the Ctx::Designer.team2.CollabSpace1 credentials, he can create content in CollabSpace1 but not CollabSpace2, because the filter requires that the collaborative space in the credentials must match the collaborative space where the content is being created.

Similarly, if Bill logs in using the Ctx::Designer.team1.CollabSpace2 credentials, he can create content in CollabSpace2 but not CollabSpace1.

If Bill logs in using the Ctx::Reviewer.team1.CollabSpace3 credentials, he cannot create content in any collaborative space, because the Reviewer role can only read and show content.

Multiple Access Control

Filters let you specify different access rights for specific operations. For example, a user could have access to edit content, but not transfer the ownership of that object.

Filter expressions for policies and rules can use the $ACCESS keyword to determine if the current user is authorized to operate on the object. For example:

user Designer

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))"

The ('$ACCESS' != 'changeowner') part of the filter grants access to the command (as long as all other criteria are met) except for changeowner.

The $ACCESS keyword must be enclosed in single or double quotes.

Expressions

This table lists the expressions that can be used as security filter expressions in policies and rules.


Expression name	Description
`MyData`	Users can access their own data.
`MyOrganizationData`	Uses can access data owned by organizations of their assigned credentials.
`MyProjectData`	Users can access data owned by collaborative spaces of their assigned credentials.