The Identity and Access Management (IAM) APIs allow developers to manage users, roles, and policies. Based on user roles and policies, These APIs offer row-level and field-level security features to limit data access. In the Accelerator Platform, We can create multiple Projects, Each Project consists of two MongoDB Clusters, One for storing Organization Databases and another for the Authentication Database
Use-case: To understand the functionalities of the Accelerator Platform, We will be implementing the following use case.
We have a organization called Clinic.
There are two type of user Providers and Patients.
Providers can invite a Patients
After Register and Login, users can insert and update their personal information.
Providers can view only those Patients that they are associated with.
Patients can view all the Providers in the Clinic.
The see access the APIs use the following link
In this documentation, I will describe the steps to implement the above use case.
To proceed with the tutorial, you can easily create the necessary Organization and Objects by clicking on the provided link
Project Admins: Project Admins are the users who can create and manage the projects. They can create new projects, organizations, objects, and manage the roles and policies of the projects.
//
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
"title": "One or more validation errors occurred.",
"status": 400,
"traceId": "00-d8e7cef64a92d286849ae53583ab4775-c0cabf25d7ac41cb-00",
"errors": { ... }
}
401
Unauthorized
Policy: In Accelerator Platform, We can create multiple policies. Each policy is a MongoDB document in the 'policies' collection inside the 'auth' database. below is a list of all the attributes of a policy document.
_id: This is the readonly, 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 hvaing 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.
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:
Step 3. Create Policies for the Provider and Patient role
a. Provider Data Access Policy: This policy will allow the Providers to access only their own data from the Providers object.
Note: While getting Items from Patients Object, The above condition will return those Patients data where the provider field is equal to the id of the logged-in user.
c. Patient Data Access Policy: This policy will allow the Patients to access only their own data from the Patients object.
User Invitation: Project admins, along with Users who have the 'sendInvite' flag set to true, have the ability to send invitations to other users for the organization they are currently logged into. The InviteUser API Endpoints allow sending an Invitation code to a user's email, which can be used during their organization registration process
Example:
Step 4. Invite Providers who can invite Patients to "Clinic" organization
Note: Using the auth token of the Provider, It is possible to insert an Item to the Provider Object. Do the same for the Patients Object. Check out the IAM documentation to know more.