Policies in IAM

One of the most important feature that Accelerator Platform provides is the capability to expand itself in the way the root users defines. You can create your role and permissions specific to your use case. You can start by creating policies and then add those policies to different roles.

Policies

In Accelerator platform a policy refers to the permissions that are assigned to users, applications, or other entities within the product. Policies define what actions a user or entity is allowed to perform within the product, such as creating or modifying resources, accessing data, or executing scripts.

Policies can be managed and organized using various tools and features within the product, such as roles and permissions. By defining policies and assigning them to users or entities, Accelerator platform helps to ensure that access to resources and data is properly controlled and managed, and that data security and integrity are maintained.

Accelerator platform offers two types of policies such as

Policy Type	Description
Object Control	This type of policies allow protecting access to the objects
API Control	This type of policies allow access to accelerator endpoints / services that are protected

There are multiple attributes offered by the platform to help you create wide range of policies. Here is a list of all the attributes of a policy

Field	Description
_id	This is the read-only, unique identifier of the policy. We can use this id to attach the policy to a role.
name	Policy name must be unique in an organization. It should be in the camelCase format.
label	Policy label is used to display the policy name in the UI.
description	To describe the policy.
version	Policy version is use determine which PolicyChecker to use to validate the policy. For now it is a constant having the value "2023-01".
type	Currently, we have one type of policy which is "ObjectControl" policy. This policy is used to control the access to the items in an object.
object	This is the name of the object to which the policy is applied.
fields	This is use to define the fields level access control. "fields": { "read": "*", "write": ["name", "address", "phoneNumber"] } In the above example, We are allowing the users to read all the fields in the object and write only to the name, address, and phoneNumber fields.
conditions	This is use to define the row level access control. "conditions": { "stringEquals": { "email": "{{user.email}}" } } In the above example, We are allowing the users to access only those items in the object where the email field is equal to the email of the logged-in user. note: We can also use the {{user.id}} variable if needed.

Example 1 of Policy name "StudentProfileAccess" for Student Management System giving access to "read" and "write" to "firstName", "lastName" and "dob" of object "Students"

// Example Policy document that allows access to an object named "Students" 
// Allows Read Access to all fields 
// write access to the fields - firstName, lastName and dob
// with a condition that if the logged in user email is same as the row.email
{
  "name": "StudentProfileAccess",
  "label": "Student Profile Access",
  "version": "2023-01",
  "type": "ObjectControl",
  "object": "Students",
  "fields": {
    "read": "*",
    "write": ["firstName","lastName","dob"]
  },
  "condition": {
    "stringEquals": {
      "email": "{{user.email}}"
    }
  }
}

Example 2 of Policy name "Access all objects" for a System giving access to "read" and "write" all fields of object "all".

// Example Policy document that allows access to all objects and all fields
{
  "name": "Access all objects",
  "label": "Access all objects",
  "version": "2023-01",
  "type": "ObjectControl",
  "object": "*",
  "fields": {
    "read": "*",
    "write":"*",
  }
}