Account/Tenant Management

Overview

This page details the functional and technical requirements for managing accounts/tenants, users, tokens (JWT), and handling authentication and authorization within the system. The goal is to standardize APIs, unbundle CITIZEN information from authentication and authorization (Auth&Auth), and replace user types with predefined roles.

Features & Scope

The system includes features such as

• multitenant support

• tenant creation/update/search

• tenant-level authorization

• data isolation, and configuration options for administrators

The Account/Tenant Management system will facilitate the creation, updating, and searching of tenants/accounts within the application. It will enforce tenant-level authorization to ensure data isolation and security. Configuration options will allow administrators to configure tenant-level details like login type, and data isolation approach.

Click on the below link to learn more about Tenants -

snippet

Functional Requirements

Tenant Management

Create Tenant:

Develop an API to allow the creation of new tenants. This API should accept necessary tenant details such as tenant name and contact information.

Input:

Field	Type	Required	Min Length	Max Length	Validations
Name	String	Y	4	128	Allow alphabet only
Code	String	Y	2	16	Unique check
Description	Text Area	N	2	512
isActive	Boolean	N	NA	NA	Make active after email verification
Email	String	Y	5	254	Email validation

Output: Confirmation message upon successful creation.

1. Send the OTP to the email address

2. Verify OTP

3. On successful verification create a super user for the tenant

4. Send the super user credentials to the registered email

Activate Account And Admin User:

After a user registers in the sandbox, a mail will be sent to the user to verify his email address. Once the user clicks on the link sent in the mail, the email address will be marked as verified and the user will be redirected to the Set Password page.

Open Questions:

1. Should we have an approval process to activate a newly created tenant? Or we can allow self-approval on successful email verification

Update Tenant

• Description: Ability to update existing tenant information.

• Input: Tenant ID and updated details.

• Output: Confirmation message upon successful update.

Search Tenants

• Description: Ability to search for tenants based on criteria.

• Input: Search parameters (name, code).

• Output: List of matching tenants.

Multi-tenancy

Data Isolation

Ensure data isolation between tenants to prevent unauthorized access.

Isolated Database Instances for Tenant Data:

This approach provides strong data isolation and independence between tenants. It is suitable when tenants require strict data segregation, has diverse infrastructure requirements, or when regulatory compliance demands it. Functionality:

• Provisioning: The client will provision the DB

• Configuration: The client will configure the DB details in the sandbox environment

• Connection Management: Manage database connections dynamically based on the tenant's context.

Pros:

• Strong Isolation: Provides robust isolation between tenants, minimizing the risk of data leakage or unauthorized access.

• Performance: Each database instance can be optimized independently for better performance.

Cons:

• Resource Overhead: Requires additional resources (memory, CPU, storage) to manage multiple database instances.

• Management Complexity: Administrators need to manage and monitor multiple databases, increasing operational overhead.

Tenant-Scoped Schemas within a Shared Database:

This approach strikes a balance between resource efficiency and data isolation. It is suitable for scenarios where tenants can share the same database infrastructure but still require some level of data segregation. It simplifies management compared to separate databases while providing better isolation than a single shared schema. Functionality:

• Schema Creation: Automatically create a new schema for each new tenant within the shared database.

• Schema Switching: Switch database connections to the appropriate schema based on the authenticated tenant's context.

Pros:

• Resource Efficiency: Utilizes a single database instance, reducing resource overhead compared to separate databases.

• Simplified Management: Centralized management of a single database instance simplifies administration tasks.

Cons:

• Limited Scalability: May face scalability challenges as the number of schemas grows within the shared database.

• Potential for Contention: Resource contention may occur if multiple tenants heavily utilize the shared database.

Unified Schema with Tenant-Tagged Data:

This approach optimizes resource utilization by sharing the same database schema among all tenants. It is suitable for applications where tenants have similar data access patterns and the ability to filter data based on tenant ID meets the requirements. While it simplifies management and scales well, it may introduce complexity in ensuring data isolation and may impact performance.

Configuration

Data Store Configuration

1. Default Data Scheme: Unified Schema with Tenant-Tagged Data (No config required the source details will get fetched from “Master Tenant”)

2. Schema Within Shared Datastore:

   • Configure schema name (Default schema name will be schema name)

   • Configure User Name

   • Configure Password

   • The connection URL will be fetched from the Master Tenant

3. Isolated Database:

   • Configure Connection Url

   • Configure Schema Name

   • Configure Username

   • Configure Password

Login Configuration

1. Allowed login types

   • Password

   • OTP

   • 2FA(Password+OTP)

   • Biometric

2. Login Expiry Time(in Sec)

3. Enable social login

4. Enable captcha

5. Password Policy

Sub Tenant

A root tenant admin can create sub-tenants using the Sub Tenant APIs