0

Hi Mendix Experts,I am working on a Demo Project where we need to implement a centralized authorization model based on Microsoft Entra ID attributes and would like to understand the best approach using Entity Access and XPath Constraints.RequirementUsers authenticate through SSO (Microsoft Entra ID). During login, we store the following attributes in the User entity:DepartmentCompanyCompany CodeCountryRegionThe application already contains 5 functional user roles that control business permissions and module access.In addition, we are planning to introduce the following add-on access roles:AccessRegion → Extends visibility to all data within the user's region.AccessAll → Extends visibility to all data across all companies and regions.InfraRead → Read/export access for infrastructure-related data.These add-on roles can be assigned together with any of the existing application roles and should only influence data visibility/scope, not the functional permissions of the user.Domain ModelMost business entities contain the following attributes:ResponsibleContact (User reference)DepartmentCompanyCompanyCodeRegionExamples:ServersDatabasesDNS AliasesApplicationsInterfacesCompaniesSitesPermissions/FileSharesVendorsUsersWhen the Responsible Contact changes, these attributes are automatically updated from the selected user's profile.Required Access LogicView AccessBy default, users should only see records belonging to their own company.Users with AccessRegion should see all records in their region.Users with AccessAll should see all records regardless of company or region.Users with InfraRead should be able to view and export infrastructure-related entities.Edit AccessEdit permissions will be module-specific.Some entities should only be editable by AccessAll users.Functional permissions remain controlled by the existing application roles.Current ImplementationCurrently, the visibility rules are enforced in microflows while retrieving data. Based on the logged-in user's Company, Region, and assigned access roles, the microflow applies the required filtering before returning the objects.While this approach is working functionally, I have concerns about maintainability and security because the filtering logic must be implemented and maintained across multiple retrieval microflows.I am therefore exploring whether this can be moved to the Domain Security level using Entity Access and XPath Constraints, so that access restrictions are enforced consistently across the application regardless of how the data is retrieved.My goal is to implement the visibility rules as close to the data layer as possible and avoid relying on individual microflows to enforce security.Current Role ModelThe application already has five functional roles (for example):AdministratorEditorContributorReaderAuditorUsers can also receive one of the add-on scope roles:AccessRegionAccessAllExamples:Reader + AccessRegionEditor + AccessRegionContributor + AccessAllAuditor + AccessAllThe functional role determines what actions a user can perform, while the add-on role determines which records the user can see through XPath security.My QuestionsWhat is the recommended Mendix approach to implement this using Entity Access and XPath Constraints?Given that I currently enforce visibility through retrieval microflows, would moving the logic to Entity Access + XPath Constraints be considered a best practice from a security and maintainability perspective?Should company and region filtering be implemented directly in Entity Access XPath constraints?How would you design the XPath constraints for:Own company accessRegion-wide accessGlobal accessSince AccessRegion and AccessAll are add-on roles, what is the best way to combine them with existing application roles without creating a large number of role combinations?Is it better to:Create separate user roles with different XPath constraints, orContinue using microflows/nanoflows for dynamic filtering?How would you handle entities that require the same visibility rules (Company → Region → Global) across many modules without duplicating security rules everywhere?Are there any performance or maintenance concerns when applying XPath constraints to a large number of entities?ExampleFor a user with:Company = Demo CompanyRegion = APACExpected visibility:Role CombinationVisible DataReaderOnly Demo Company recordsReader + AccessRegionAll APAC recordsReader + AccessAllAll recordsEditor + AccessRegionAll APAC recordsAuditor + AccessAllAll recordsI would appreciate any recommendations, best practices, domain model patterns, security design approaches, or sample XPath implementations for this type of authorization model.Thanks in advance!

asked 2026-08-10

2 answers