For multi-tenant apps check if entity has access rule with xPath leading to the current user .
Make very sure that for apps which serve multiple customers (e.g. companies) have very strict entity access so a user can only see what should be accessible for this user.
A multi-tentant app usually has a ‘tenant’ entity. The ‘tenant’ entity has an association to the user as usually stored in Administration.Account. All other entities that contain data per tentant have an xpath on the entity access rule leading to the current user via the ‘tenant’ entity. So by requiring all access rules for a certain project role to have an xpath ending with ‘tenant’ and account means requiring a good secure configuration.
As parameter, you can specifically specify what the access rule should look like, see the template:
‘<Project-Role>;<Match-operator:endsWith|equals|excludeEntity|excludeModuleRole>;<Path>; (multiple lines possible)’
Options excludeEntity and excudeModuleRole are added in v1.5 to be able to easy handle exceptions like data for all users.
Example where the role ‘User’ requires all entity access to go via Administration.Project to Administration.Account over association Administration.Account_Projects_Member :
User;endsWith;Administration.Project/Administration.Account_Projects_Member='[%CurrentUser%]']
Also allowed is direct access on Administration.Account :
User;equals;[id='[%CurrentUser%]']
So multiple lines are tried. Only one needs to match, so if none match it is a violation.
Real example : Configuration for the SMART Digital Factory itself
User;endsWith;Administration.Project/Administration.Account_Projects_Member='[%CurrentUser%]']; // via multi tenant entity
User;endsWith;_Account='[%CurrentUser%]']; // per user data
User;excludeEntity;Administration.Account,Administration.Project;// exception for Account and Project, the multi tenant entity
User;excludeModuleRole;UserGlobal; // exceptions to multi tenancy via module role named UserGlobal
So most user data goes via the first config line. Some data like user settings or temporary downloads of files go via the second config line. For Account and the multi tenant entity we make an exception. These should be check manually. Alternatively we could add config lines matching equal for them.
For data that is needed for all users, thus across tenants, we use a module role with a different name. This also brings additional clarity to the design!
Real example : Configuration for APM Manager
APMUser;endsWith;Administration.Account_EnvironmentReadPermissions='[%CurrentUser%]']; // per environment read
APMUser;endsWith;Administration.Account_EnvironmentWritePermissions='[%CurrentUser%]']; // per environment write
APMUser;endsWith;Administration.Account_EnvironmentAdminPermissions='[%CurrentUser%]']; // per environment admin
APMUser;endsWith;_Project/Administration.Project/Administration.Account_ProjectMember='[%CurrentUser%]']; // per project
APMUser;endsWith;_Account='[%CurrentUser%]']; // per user data
APMUser;excludeEntity;Administration.Account,Administration.Project;
APM has a multi tenant entity Project and within project you can configure multiple environments. So the setup is a bit more complex, but still the same principles apply.