Project AuthenticationAccess Control
Project Authentication

Access control

Configuration reference for defining the access control architecture of a Mindbricks project, including permissions, roles, OBAC, and ABAC settings.

MPO Version: 1.3.0

Configuration chapter for defining the access control architecture of the project. Mindbricks supports multiple authorization models including role-based, user-based, object-based, and attribute-based access controls. This section enables a unified, flexible, and scalable permission system that ensures resources and operations are securely accessed based on defined authorization rules across services.

interface AccessControl = {
  permissionBasics : PermissionBasics;
  roleSettings : RBACSettings;
  permissionTypes : PermissionTypes;
  objectBasedSettings : OBACPermission;
  attributeBasedSettings : AbacPermission;
}
FieldDescription
permissionBasicsDefines the core permission vocabulary of the project, including permission groups and named permissions. These are referenced in access control logic across services.
roleSettingsSettings for Role-Based Access Control (RBAC), which defines how roles are assigned to users and how roles are mapped to permissions. This is the most common access control strategy in projects.
permissionTypesSpecifies which permission application methods are active in the project. Mindbricks supports role-based, user-based, user-group-based, object-based (OBAC), and attribute-based (ABAC) authorization models. Multiple types can be active concurrently.
objectBasedSettingsSettings related to Object-Based Access Control (OBAC). In this model, access is determined based on the user's relation to a specific object instance, such as ownership.
attributeBasedSettingsSettings for Attribute-Based Access Control (ABAC). In this model, access decisions are based on dynamic rules involving user, object, or contextual attributes.

PermissionBasics

MPO Version: 1.3.0

Defines the foundational permission model of the project. This section enables Permission-Based Access Control (PBAC) by allowing the architect to organize granular permissions into named groups. These permission groups act as the reference set for roles, users, and object-level rules throughout the project.

interface PermissionBasics = {
  pbacIsActive : Boolean;
  configuration : PermissionBasicsConfig;
}
FieldDescription
pbacIsActiveA boolean flag indicating whether Permission-Based Access Control (PBAC) is active for this project. If enabled, Mindbricks will enforce permission checks according to the defined permission model.
configurationThe configuration object for permission basics. Leave it null if pbacIsActive is false.

PermissionBasicsConfig

MPO Version: 1.3.0

Configuration details for permission basics, including permission groups.

interface PermissionBasicsConfig = {
  permissionGroups : PermissionGroup[];
}
FieldDescription
permissionGroupsAn array of PermissionGroup objects that define the named permissions of the project grouped under logical categories. These groups help structure and reuse permission definitions across services.

PermissionGroup

MPO Version: 1.3.0

Defines a group of permissions under a shared namespace. Each permission group has a unique groupName and a list of permissions that are referenced across the project using either 'groupName.permission' or standalone permission identifiers. These groups simplify permission management in large-scale projects.

interface PermissionGroup = {
  groupName : String;
  permissions : String[];
}
FieldDescription
groupNameThe unique identifier of the permission group. It is used as a namespace in the format groupName.permission when referencing permissions in roles or other rules.
permissionsA list of permission names (strings) defined under this group. These should be unique across the project to ensure consistent access rules.

RBACSettings

MPO Version: 1.3.0

Configuration for Role-Based Access Control (RBAC) within the project. When enabled, RBAC allows permissions to be assigned to named roles, which are then associated with users. This setup supports both single-role and multi-role configurations, along with custom logical roles defined by dynamic lookup conditions.

interface RBACSettings = {
  rbacIsActive : Boolean;
  configuration : RBACSettingsConfig;
}
FieldDescription
rbacIsActiveA boolean value to enable or disable role-based access control (RBAC) in the project. When enabled, access decisions can be made based on user roles.
configurationThe configuration object for RBAC settings. Leave it null if rbacIsActive is false.

RBACSettingsConfig

MPO Version: 1.3.0

Configuration details for RBAC, including roles, role ID data type, custom role lookups, and multi-role support.

interface RBACSettingsConfig = {
  roleItems : RoleItem[];
  customRoleLookups : DataMapItem[];
  usersHaveMultipleRoles : Boolean;
}
FieldDescription
roleItemsDefines the list of roles available in the project. Each role is represented as a RoleItem object with a name and a value. These roles will be used to assign permissions and will appear in session data during authentication. Note that for single tenant applications, superAdmin, admin , user roles and for multi-tenant applications superAdmin, saasAdmin, tenantOwner, tenantAdmin, tenantUser roles are defined as default system roles. And thery are active even RBAC is not active.Any role item in this roleItems array will be addtional role to these system roles.
customRoleLookupsAn optional mapping of custom logical roles and their evaluation logic. Each entry maps a role name to an MScript condition that determines whether the role is assigned to a user dynamically.
usersHaveMultipleRolesIndicates whether users can have multiple roles. If true, the roleId in the session and user model will be treated as an array of role values.

RoleItem

MPO Version: 1.3.0

Represents a role definition in the RBAC system. Each role includes a name for display and a value used in session data and permission checks.

interface RoleItem = {
  name : String;
  value : Any;
}
FieldDescription
nameThe display name of the role (e.g., 'grpAdmin', 'editor'). This name will be used for reference in the code and documentation purposes. Please ensure that it is one word with no special characters. For multiple words use camleCase.
valueThe internal value of the role, which will be stored in the roleId field of the user or session data. This value is used during authorization checks and should be a string. Make it same as the name to prevent confusion unless you have a reason. When you use a role reference in any authorization configuration, write donw this value not the name.

PermissionTypes

MPO Version: 1.3.0

Defines the active permission mechanisms in the project. Mindbricks supports multiple types of permission strategies including role-based (RBAC), user-specific overrides, user group-level permissions, object-level (OBAC), and tenant-specific rules. This configuration determines which of these models are enabled for the access control logic.

interface PermissionTypes = {
  roleBasedPermissionsIsActive : Boolean;
  userBasedPermissionsIsActive : Boolean;
  userGroupBasedPermissionsIsActive : Boolean;
  objectBasedPermissionsIsActive : Boolean;
  tenantBasedPermissionsIsActive : Boolean;
}
FieldDescription
roleBasedPermissionsIsActiveEnables Role-Based Access Control (RBAC) for the project. When active, permissions can be assigned to roles, and users inherit access through their roles.
userBasedPermissionsIsActiveEnables user-specific permission overrides. When active, admins can assign custom permissions directly to individual users regardless of their roles or groups.
userGroupBasedPermissionsIsActiveEnables permission control via user groups. When active, permissions can be assigned to defined user groups and inherited by all members.
objectBasedPermissionsIsActiveEnables Object-Based Access Control (OBAC). When active, permission rules can be defined per individual data object (e.g., per record) and evaluated dynamically based on the object's relation to the user.
tenantBasedPermissionsIsActiveActivates tenant-specific permission logic. In multi-tenant projects, this allows SaaS administrators to define custom permission profiles per tenant, enabling isolated authorization policies.

OBACPermission

MPO Version: 1.3.0

Configuration for Object-Based Access Control (OBAC), which restricts access to specific data objects based on object ownership or association. If your system requires permissions that vary per object instance (e.g., 'only the creator can edit this record'), OBAC should be enabled and the relevant data objects listed.

interface OBACPermission = {
  objectBasedPermissionsIsActive : Boolean;
  dataObjects : DataObjectName[];
}
FieldDescription
objectBasedPermissionsIsActiveA boolean value that enables object-level permission checks. When true, permissions can be enforced per record based on ownership or related fields.
dataObjectsAn array of data object names to which object-level permissions will apply. These are the models for which individual access control should be enforced.

DataObjectName

MPO Version: 1.3.0

Represents a reference to a data object within the project. The value can be either a simple object name or a qualified reference in the format 'serviceName:objectName'. When using the qualified format, the part before the ':' specifies the service name, and the part after specifies the object name within that service. If only a single name is provided (without ':'), the system first searches for the object in the current service, then searches across other services in the project. As a best practice, when referencing data objects from other services, always fully qualified 'serviceName:objectName' format should be used to avoid potential naming conflicts.

interface DataObjectName = {
}
FieldDescription

AbacPermission

MPO Version: 1.3.0

Configuration for Attribute-Based Access Control (ABAC), allowing fine-grained permission control using attribute-level rules on data objects. ABAC evaluates access by applying custom filter conditions to each object. When a rule matches, the user session may be granted specific permissions or even dynamic roles for that object. These rules can supplement or override standard RBAC or OBAC logic.

interface AbacPermission = {
  attributeBasedPermissionsIsActive : Boolean;
  abacDefinitions : ABACDefinititon[];
}
FieldDescription
attributeBasedPermissionsIsActiveA boolean value that enables attribute-level access control. When true, data access will be filtered according to ABAC rules defined in abacDefinitions.
abacDefinitionsAn object array to define ABAC (Attribute-Based Access Control) rules. Each rule applies a conditional filter to determine which records a user can access, and grants either dynamic permissions or a role for matching records.

ABACDefinititon

MPO Version: 1.3.0

Defines a single ABAC (Attribute-Based Access Control) rule for a given data object. Each rule applies a conditional filter to determine which records a user can access, and grants either dynamic permissions or a role for matching records.

interface ABACDefinititon = {
  name : String;
  dataObject : DataObjectName;
  whereClause : MScript;
  permissions : String[];
}
FieldDescription
nameThe unique identifier for this ABAC rule. It is used in the backend logic, database, and UI for reference.
dataObjectThe name of the data object to which this ABAC rule applies.
whereClauseA JavaScript-style where clause defined using MScript syntax. This condition determines which records in the data object will match the rule and grant access.
permissionsA list of permission strings that will be granted when the ABAC rule matches a record. These permissions are context-specific and take precedence over less-specific permission types (such as role-based permissions).
Was this page helpful?
Built with Documentation.AI

Last updated today