Multi-Tenancy
Tenant isolation, RBAC, brand access control, feature flags, and subscription management.
Multi-Tenancy
Neostra is built as a multi-tenant platform where each tenant operates in an isolated environment with its own users, data, configurations, and subscription plans. A single user credential can belong to multiple tenants, and access within each tenant is controlled through a hierarchical RBAC model scoped to brands, processes, and sub-processes.
Architecture Overview
Tenant Model
Each tenant represents an isolated organization on the platform. The tenant document stores core identity and configuration fields.
Identity
Name, active status, logo URL, and associated domains used for SSO and email routing.
Communication
Sender name and sender email address used for outbound notifications and emails.
Subscription
Reference to a CustomSubscriptionPlan that defines feature limits and quotas for the tenant.
Tenant Fields
| Field | Type | Description |
|---|---|---|
name | String | Display name of the tenant organization |
active | Boolean | Whether the tenant is currently active |
domains | List<String> | Email domains associated with the tenant |
logo | String | URL to the tenant logo |
subscriptionRef | ObjectId | Reference to the tenant's subscription plan |
senderName | String | Name shown on outbound emails |
senderEmail | String | Email address used for outbound communications |
Tenant Settings
Each tenant has a TenantSetting document that controls localization, feature availability, notifications, and DSAR (Data Subject Access Request) configuration.
{
"supportedLocales": ["en", "de", "fr", "es", "pt"],
"globalLanguages": ["en", "de"]
}
Neostra supports 58 languages through its i18n system. Each tenant can configure which locales are available to their users and which languages are used for global content like consent banners and privacy notices.
{
"featureGroups": [
{
"name": "consent-management",
"features": [
{ "key": "cookie-consent", "enabled": true },
{ "key": "preference-center", "enabled": true },
{ "key": "consent-analytics", "enabled": false }
]
},
{
"name": "data-discovery",
"features": [
{ "key": "auto-scan", "enabled": true },
{ "key": "classification", "enabled": true }
]
}
]
}
Feature flags are organized into FeatureGroup containers. Each group has a name and a list of FeatureFlags with a key and enabled state. This allows toggling entire modules or individual capabilities per tenant.
{
"notificationPreferences": {
"emailOnIncident": true,
"emailOnDSAR": true,
"emailOnAssessment": false,
"digestFrequency": "weekly"
}
}
{
"dsarSettings": {
"autoAcknowledge": true,
"defaultDeadlineDays": 30,
"requireIdentityVerification": true,
"allowedRequestTypes": [
"access",
"deletion",
"rectification",
"portability"
]
}
}
Tenant Isolation
All database queries are automatically scoped to the authenticated user's tenant. The tenantId is extracted from the JWT and applied as a filter condition on every query. There is no cross-tenant data access at the application layer.
Tenant isolation is enforced at the query level. Direct database access bypasses these controls. Always use the application APIs for data access.
Role-Based Access Control (RBAC)
Brand Access Model
Within a tenant, user access is further scoped by a hierarchical model of brands, processes, and sub-processes. Each user has a BrandAccess list that defines exactly which parts of the organization they can interact with.
BrandAccess Structure
{
"brandAccess": [
{
"brandId": "brand-marketing-001",
"brandName": "Marketing",
"processes": ["email-processing", "social-media"],
"subProcesses": ["newsletter", "ad-campaigns"]
},
{
"brandId": "brand-sales-002",
"brandName": "Sales",
"processes": ["crm-processing"],
"subProcesses": ["lead-tracking", "pipeline"]
}
]
}
RBACQueryBuilder
The RBACQueryBuilder automatically applies brand, process, and sub-process filters to database queries based on the authenticated user's access list.
// Internally, RBACQueryBuilder constructs filtered queries:
Query query = RBACQueryBuilder.build(userDetails);
// Equivalent to:
// { tenantId: "tenant-abc", brandId: { $in: ["brand-marketing-001", "brand-sales-002"] } }
{
"tenantId": "tenant-abc-123",
"brandId": {
"$in": ["brand-marketing-001", "brand-sales-002"]
},
"process": {
"$in": ["email-processing", "social-media", "crm-processing"]
}
}
Admin users with full access do not have brand-level restrictions. The RBACQueryBuilder detects this and omits brand/process filters for admin roles.
Multi-Tenant User Support
A single UserCredential (email + password) can be associated with multiple tenants. During sign-in, the user receives a list of all tenants they belong to and selects one to receive a tenant-scoped JWT.
User signs in
The sign-in endpoint returns a temporary JWT and a list of all tenants associated with the credential.
Tenant selection
The user selects a tenant. A new Core JWT is issued scoped to that specific tenant, including the user's roles, permissions, and brand access for that tenant.
Switch tenants
To switch tenants, the user repeats the sign-in flow or uses the tenant selection endpoint with a valid temporary JWT.
Subscription Plans
Subscriptions control feature limits and quotas per tenant. The system uses a two-tier plan model.
Default Subscription Plans
Platform-wide templates that define baseline feature sets and limits. Managed by platform administrators.
Custom Subscription Plans
Per-tenant copies derived from a default plan. Can be customized with different limits or additional features for specific tenants.
Plan Tiers
Neostra offers five subscription tiers, each enabling different modules and feature limits.
| Feature | Startup | Basic | Growth | Enterprise | Developer |
|---|---|---|---|---|---|
| DSAR | -- | Included | Included | Included | Included |
| Consent Management | Included | Included | Included | Included | Included |
| Privacy Notices | Included | Included | Included | Included | Included |
| Assessments | -- | -- | -- | Included | Included |
| Data Discovery | -- | -- | -- | Included | Included |
| Data Mapping | -- | -- | -- | Included | Included |
| Plan | Max Requests | Basic Workflow Rules | Advanced Rules | Custom Dashboard |
|---|---|---|---|---|
| Basic | 100/month | Yes | No | No |
| Growth | 500/month | Yes | Yes | No |
| Enterprise | Unlimited | Yes | Yes | Yes |
| Developer | Unlimited | Yes | Yes | Yes |
| Plan | Max Consents | Scan URLs | Cookie Consent Writes | iFrame Blocking |
|---|---|---|---|---|
| Startup | 10,000/month | 5 | Yes | No |
| Basic | 50,000/month | 20 | Yes | No |
| Growth | 250,000/month | 100 | Yes | Yes |
| Enterprise | Unlimited | Unlimited | Yes | Yes |
| Developer | Unlimited | Unlimited | Yes | Yes |
The Developer plan is used for internal development and demos. It enables all modules with no limits and is not available to customers.
Plan Fields
| Field | Description |
|---|---|
maxUsers | Maximum number of users allowed in the tenant |
maxBrands | Maximum number of brands |
maxAssessments | Assessment quota |
featureGroups | Which feature groups are included in the plan |
storageLimit | Maximum file storage in GB |
apiRateLimit | Requests per minute |
Tenant Provisioning
New tenants are provisioned through the astra-core service, which handles the administrative control plane.
Create tenant
Use the TenantController to create a new tenant record with name, domains, and configuration.
Provision resources
The TenantProvisionController initializes the tenant's default data: roles, permissions, default settings, and subscription plan.
Invite initial user
An invitation is sent to the tenant administrator to complete registration and begin configuration.
curl -X POST https://api.neostra.io/v1/admin/tenants \
-H "Authorization: Bearer <admin_jwt>" \
-H "Content-Type: application/json" \
-d '{
"name": "New Organization",
"domains": ["neworg.com"],
"senderName": "New Org Privacy",
"senderEmail": "privacy@neworg.com",
"subscriptionPlanId": "plan-enterprise-001"
}'
curl -X POST https://api.neostra.io/v1/admin/tenants/tenant-new-001/provision \
-H "Authorization: Bearer <admin_jwt>"
The initial password provided during provisioning should be reset by the tenant administrator on first login. Never reuse provisioning passwords across tenants.
Feature Flags Reference
Last updated 1 week ago
Built with Documentation.AI