Credentials Access in Policies and Rules

Mono credentials enforcement in policies and rules uses the login keyword to restrict access based on the credentials of the user logged in with. Multiple sets of credentials enforcement in policies and rules restricts access based on a user role. The same user role can be defined with more than one set of access definitions.

This page discusses:

Multiple Access Definitions Per User

The user keyword lets you specify multiple access definitions for the same user in policies and rules. This lets you split access definitions using complex filter expressions into several smaller and simpler access definitions.

For example, this access definition can be defined: 

policy "VPLM_SMB"
     state "SHARED"
     user "VPLMProjectLeader"
          read,show,checkout,promote,demote,changeowner,unlock,
               toconnect,todisconnect,revise
               filter "(organization.ancestor match context.user.assignment[$CHECKEDUSER].org)
                 && (($ACCESS matchlist 'read,show,checkout' ',') ||
                 (project == context.user.assignment[$CHECKEDUSER].project))"

This filters specifies both organization and collaborative space (project) criteria for the VPLMProjectLeader user (one of the baseline behavior access roles). If a user meets both sets of criteria, then that user has access to the content. For more information, see Organization and Project-Based Access. This pseudocode shows 

filter " (organization critieria) AND ( (access criteria) OR (project criteria)
		 
		  )"

To have access to the content, the user must meet the organization criteria, and either the access criteria or the project criteria.

In this filter organization.ancestor match context.user.assignment[$CHECKEDUSER].org) instructs the app to check the organization defined by the user's credentials and determine if the user belongs in that organization or an ancestor of that organization. For example, Company Name if the user is assigned context VPLMDesign.Company Name.Engineering). If the content ownership matches the user's organization and all other criteria are met, the user has the specified access privileges to that content in that state.

The $ACCESS variable represents the access currently being checked and compares it to matchlist 'read,show,checkout'. If the access being checked is read, show, or checkout and the organization criteria is met, the user has access to this content. If a different access is being checked, the app checks the project component of the filter.

The context.user.assignment[$CHECKEDUSER].project part of the filter checks if the collaborative space (project) that owns the content matches the project component of the credentials of the user. For example, Engineering if the user is assigned context VPLMDesign.Company Name.Engineering).

The access definition can simplify the filter using an organization matching option as follows: 

policy "VPLM_SMB"
     state "SHARED"
        user "VPLMProjectLeader"
           read,show,checkout,promote,demote,changeowner,unlock,toconnect,todisconnect,revise 
              ancestor org
           filter "($ACCESS matchlist 'read,show,checkout' ',') ||
           (project == context.user.assignment[$CHECKEDUSER].project)"

For more information about matching options, see About Organization and Project-Based Access.

Because the filtering on the project of the content depends on the access being checked, you cannot use the single project matching option, so the access definition still contains the filter expression. However, you can use the key keyword to split the access definition into two as follows: 

  policy "VPLM_SMB"
     state "SHARED"
        user "VPLMProjectLeader"
           key "read"
           read,show,checkout
           descendant org
        user "VPLMProjectLeader"
           key "others"
           descendant org
           single project
           promote,demote,changeowner,unlock,toconnect,todisconnect,revise

There are now two separate access definitions for the same user VPLMProjectLeader. The first access definition contains only read, show, and checkout accesses, and only specifies a matching option on the organization. The second access definition contains the other accesses, and specifies both organization and project matching options.

This method eliminates the remaining filter expression: 

$ACCESS matchlist 'read,show,checkout' ',') || (project ==
     context.user.assignment[$CHECKEDUSER].project)

The key option indicates two distinct entries preventing the system from overwriting the first access definition with the second access definition.

Mono-Credentials Enforcement

The login keyword can be specified in policy and rule access definitions in place of the user keyword to indicate that the following definition must apply only to the credentials the user selected when connecting to the 3DEXPERIENCE Platform, the login or current credentials.

This keyword lets you specify mono-context access definitions compatible with the organization and project matching options and multiple access definition per user as described in Multiple Access Definitions Per User.

For example, the following access definition: 

policy "VPLM_SMB"
     state "WAITAPP"
     user "VPLMCreator" read,show,changeowner,checkout,toconnect,todisconnect
          filter "(organization.ancestor match
             context.role[$CHECKEDUSER].org) && (project ==
             context.role[$CHECKEDUSER].project)"

Can be implemented as follows: 

policy "VPLM_SMB"
     state "WAITAPP"
     user "VPLMCreator" read,show,changeowner,checkout,toconnect,todisconnect
          descendant org
          single project

Owner and Public Access Definitions

The owner and public policy and rule access definitions have the same capabilities as regular user-based access definitions including:

  • Filter expressions
  • Organization and project matching
  • Multiple access definitions per user
  • Revoke access