@sourceloop/ctrl-plane-tenant-management-service / Exports
tenant-management-service¶
This is the primary service of the control plane responsible for onboarding a tenant and triggering it's provisioning.
Overview¶
A Microservice for handling tenant management operations. It provides -
- lead creation and verification
- Tenant Onboarding of both pooled and silo tenants
- Billing and Invoicing
- Provisioning of resources for silo and pooled tenants
- IDP - confgure identity provider
work flow¶
Installation¶
Install Tenant Management Service using npm;
Usage¶
- Create a new Loopback4 Application (If you don't have one already)
lb4 testapp - Install the tenant management service
npm i @sourceloop/ctrl-plane-tenant-management-service - Set the environment variables.
- Run the migrations.
- Add the
TenantManagementServiceComponentto your Loopback4 Application (inapplication.ts). - Set up a Loopback4 Datasource with
dataSourceNameproperty set toTenantManagementDB. You can see an example datasource here. - Bind any of the custom providers you need.
Onboarding a tenant¶
- The onboarding process starts through a concept of a
Lead. ALeadis a prospective client who may or may not end being a tenant in our system. - The overall flow could be something like this -

- The
Leadis created through POST/leadsendpoint, which creates a Lead and sends an email to verify the email address of the lead - The mail has a link which should direct to a front end application, which in turn would call the upcoming api's using a temporary authorization code included in the mail.
- The front end application first calls the
/leads/{id}/verifywhich updates the validated status of the lead in the DB and returns a new JWT Token that can be used for subsequent calls - If the token is validated in the previous step, the UI should call the
/leads/{id}/tenantsendpoint with the necessary payload(as per swagger documentation). - This endpoint would onboard the tenant in the DB, and the facade is then supposed to trigger the relevant events using the
/tenants/{id}/provisionendpoint. - The provisioning endpoint will invoke the publish method on the
EventConnector. This connector's purpose is to provide a place for consumer to write the event publishing logic. And your custom service can be bound to the keyEventConnectorBindingexported by the service. Refer the example with Amazon EventBridge implementation in the sandbox.
IDP - Identity Provider¶
The IDP (Identity Provider) Controller provides an endpoint to manage identity provider configurations for tenants. It supports multiple identity providers, such as Keycloak and Auth0, and ensures secure handling of identity provider setup requests through rate-limiting, authorization, and input validation.
Features¶
Multi-IDP Support:¶
- Supports Keycloak and Auth0 as identity providers.
- Extensible for additional providers like Cognito.
Bindings:¶
TenantManagementServiceBindings.IDP_KEYCLOAK - Provides Keycloak configuration handler.
TenantManagementServiceBindings.IDP_AUTH0 - Provides Auth0 configuration handler.
This switch statement selects the appropriate identity provider (IDP) configuration based on the identityProvider value in the request payload.
- AUTH0: Calls idpAuth0Provider to configure Auth0.
- KEYCLOAK: Calls idpKeycloakProvider to configure Keycloak.
Finally, it returns the response (res) from the selected provider.
authId is the id of the user created over identity provider.
Bind your required provider as below
- For Keycloak
- For Auth0
Webhook Integration¶
- A webhook endpoint is available in the service that is supposed to update the status of a tenant based on the updates from the third-party responsible for actual provisioning of resources
- To add Webhook configuration in your application, add the
WebhookTenantManagementServiceComponentto your Loopback4 Application (inapplication.ts). - To test this from local, ensure that your local service is exposed through a tool like ngrok or localtunne
- Your third-party tool is responsible for hitting this endpoint with the expected payload and a signature and timestamp in headers
x-signatureandx-timestamprespectively. - The signature is derived using the following logic (written in Node.js but could be implemented in any other language) -
The identity provider and its related providers are also a part of the 'WebhookTenantManagementServiceComponent' since we expect it to be invoked separately once the tenant provisioning is completed via the orchestrator or any other medium preferred.
Environment Variables¶
| Name | Required | Description | Default Value |
|---|---|---|---|
| NODE_ENV | Y | Node environment value, i.e. `dev`, `test`, `prod | |
| LOG_LEVEL | Y | Log level value, i.e. `error`, `warn`, `info`, `verbose`, `debug` | |
| DB_HOST | Y | Hostname for the database server. | |
| DB_PORT | Y | Port for the database server. | |
| DB_USER | Y | User for the database. | |
| DB_PASSWORD | Y | Password for the database user. | |
| DB_DATABASE | Y | Database to connect to on the database server. | |
| DB_SCHEMA | Y | Database schema used for the data source. In PostgreSQL, this will be `public` unless a schema is made explicitly for the service. | |
| REDIS_HOST | Y | Hostname of the Redis server. | |
| REDIS_PORT | Y | Port to connect to the Redis server over. | |
| REDIS_URL | Y | Fully composed URL for Redis connection. Used instead of other settings if set. | |
| REDIS_PASSWORD | Y | Password for Redis if authentication is enabled. | |
| REDIS_DATABASE | Y | Database within Redis to connect to. | |
| JWT_SECRET | Y | Symmetric signing key of the JWT token. | |
| JWT_ISSUER | Y | Issuer of the JWT token. | |
| SYSTEM_USER_ID | Y | system user id. | |
| FROM_EMAIL | Y | email to send notification. | |
| APP_NAME | Y | app name. | |
| APP_VALIDATE_URL | Y | frontend url to validate. | |
| APP_LOGIN_URL | Y | control plane url. | |
| VALIDATION_TOKEN_EXPIRY | Y | expiry time for token. | |
| AWS_REGION | Y | aws region. | |
| PUBLIC_API_MAX_ATTEMPTS | Y | number of attempts for public api. | |
| WEBHOOK_API_MAX_ATTEMPTS | Y | number of attempts for webhook api. | |
| WEBHOOK_SECRET_EXPIRY | Y | expiry time for webhook secret. | |
| LEAD_TOKEN_EXPIRY | Y | expiry time for lead token. | |
| SILOED_PIPELINE | Y | pipeline key for soloed. | |
| POOLED_PIPELINE | Y | pipeline key for pooled. | |
| LEAD_KEY_LENGTH | Y | lenght of random key for lead. |
Setting up a DataSource¶
Here is a sample Implementation DataSource implementation using environment variables and PostgreSQL as the data source.
create one more datasource with redis as connector and db name 'TenantManagementCacheDB' that is used for cache
Migrations¶
The migrations required for this service can be copied from the service. You can customize or cherry-pick the migrations in the copied files according to your specific requirements and then apply them to the DB.
Database Schema¶

The major tables in the schema are briefly described below -
Address - this model represents the address of a company or lead
Contact - this model represents contacts belonging to a tenant
Invoice - this model represents an invoice with the amount and period generated for a tenant in the system
Leads - this model represents a lead that could eventually be a tenant in the system
Tenants - main model of the service that represents a tenant in the system, either pooled or siloed
-@2x.png)