Identity and Access Management
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
https://qa.accelerator-platform.com/swagger/index.html
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 here
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.
Example:
Step 1. Create a new Project Admin
POST https://qa.accelerator-platform.com/api/v1/ProjectAdminSignUp
// Request Body:
{
"firstName": "John",
"lastName": "Doe",
"email": "[email protected]",
"password": "Pa$$w0rd"
}Step 2. Login to Clinic Org as a Project Admin
Response:
200
<project-admin-authtoken>
400
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 read all the fields in the object and write only to the name, address, and phoneNumber fields.
9. conditions: This is used to define the row 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.
POST https://qa.accelerator-platform.com/api/v1/CreatePolicy
b. Providers Access To Patients Data: This policy will allow the Providers to access only the Patients data that they are associated with.
POST https://qa.accelerator-platform.com/api/v1/CreatePolicy
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.
POST https://qa.accelerator-platform.com/api/v1/CreatePolicy
d. Patient’s Access to Providers: This policy will allow the Patients to access basic information of the Providers.
Roles: A Role is a collection of policies. below is a list of all the attributes of a role document.
_id: This is the readonly, unique identifier of the role. We can use this id to attach the role to a user.
name: Role name must be unique in an organization. It should be in the camelCase format.
policies: This is an array of policy ids.
Example:
Create Roles for the Provider and Patient
a. POST https://dev.accelerator-platform.com/api/v1/CreateRole
b. POST https://qa.accelerator-platform.com/api/v1/CreateRole
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
User Registration Example:
Step 5. Register Providers
POST https://dev.accelerator-platform.com/api/v1/Register
Step 6. Authorize Providers
GET https://qa.accelerator-platform.com/api/v1/[email protected]&password=S@mplePass0rd
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.
Last updated