Skip to main content

Tenant

Purpose​

A Tenant represents the primary identity, security, and data isolation boundary within Chilarai.

A Tenant is not a business entity. The primary business entity of the platform is the School.

The Tenant exists primarily to support:

  • Authentication
  • Authorization
  • Data Isolation
  • Configuration Isolation
  • Identity Provider Integration

Most users of the platform should not interact directly with the Tenant concept.

Business Context​

A School is the primary customer-facing entity within Chilarai.

When a customer is onboarded:

  1. A Tenant is created.
  2. An initial School is created within that Tenant.
  3. The Tenant provides the isolated security and commercial boundary for its Schools.

The MVP provisioning workflow creates one School per Tenant. The durable model supports multiple Schools per Tenant so the relationship can expand without a schema redesign.

Relationships​

Tenant to School​

  • One Tenant contains one or more Schools.
  • One School is associated with exactly one Tenant.

Tenant to User​

  • A Tenant contains many Users.
  • Users may belong to multiple Schools.
  • Users may exist across multiple Tenant contexts.

Key Design Decisions​

Tenant is a Technical Concept​

Tenant should be treated as:

  • Security Boundary
  • Authentication Boundary
  • Authorization Boundary
  • Data Isolation Boundary

Tenant should not be treated as:

  • Customer-facing Business Entity

Schools remain the customer-facing operational entities. Tenant-level commercial agreements may cover one or more Schools.

School is the Business Entity​

The School represents:

  • Branding
  • Academic Operations
  • Reporting

The Tenant owns subscription and licensing state.

Users primarily interact with Schools, not Tenants.

User Membership Model​

Users can belong to multiple Schools.

Examples:

  • A Parent may have children studying in multiple Schools.
  • A Teacher may teach in multiple Schools.
  • A User may be a Parent in one School and a School Administrator in another.

This is considered a first-class supported scenario.

Roles are Membership Based​

Roles are not assigned directly to Users.

Roles are assigned through School Memberships.

Examples of membership roles:

  • School Admin
  • Teacher
  • Parent
  • Student
  • Accountant
  • Receptionist
  • Principal

A single User may have different Roles in different Schools.

Examples:

  • User A -> Teacher in School A
  • User A -> Parent in School B
  • User A -> School Admin in School C

Users may also have multiple roles within the same School.

Examples:

  • Parent + Teacher
  • Parent + School Admin
  • Teacher + Principal
  • Teacher + Accountant

The membership model must support multiple roles per membership.

Data Isolation Strategy​

Chilarai will use:

  • Shared Database
  • Shared Schema
  • Tenant Identifier Based Isolation

All tenant-owned data should contain a tenant identifier.

Benefits:

  • Operational Simplicity
  • Lower Infrastructure Cost
  • Easier Management
  • Sufficient Isolation for Current Requirements

Identity Strategy​

Chilarai will use:

  • Single Keycloak Realm

Reasons:

  • Simpler Onboarding
  • Easier Administration
  • Supports Users Belonging to Multiple Schools
  • Supports Multiple Memberships Per User
  • Reduces Operational Overhead

Multiple realms may be considered in the future if specific enterprise requirements emerge.

Platform Roles​

Platform roles exist outside School Memberships.

Examples:

  • Platform Administrator
  • Platform Support

Platform roles are intended for Ujan Labs personnel responsible for operating and supporting the platform.

Attributes​

Identity​

  • TenantId
  • TenantCode

Status​

  • Status

Possible values:

  • Active
  • Suspended
  • Archived

Audit​

  • CreatedAt
  • CreatedBy
  • UpdatedAt
  • UpdatedBy

Lifecycle​

Created​

Automatically created when a School is onboarded.

Active​

School is operational and accessible.

Suspended​

School access is temporarily restricted.

Archived​

School is no longer active but retained for historical purposes.

Future Considerations​

The following decisions may be revisited as the platform evolves:

  • Realm-per-Tenant Identity Model
  • Additional Tenant-Level Configuration
  • Enterprise Federation Requirements
  • Advanced Isolation Strategies

These capabilities are intentionally deferred to keep the platform simple.

Summary​

Core decisions:

  • Tenant is a technical isolation concept.
  • School is the primary business entity.
  • Tenant and School have a 1:1 relationship.
  • Users may belong to multiple Schools.
  • Users may belong to multiple Tenants.
  • Roles are membership-based, not user-based.
  • Users can have multiple roles within the same School.
  • Shared database with tenant-based isolation.
  • Single Keycloak realm.
  • Platform administration is separate from School administration.