This functionality is only available with the Multi Tenancy License. Please contact Blueriq Support.
To prepare your setup for multi tenancy you will need to execute some steps per component.
Most components in a setup make use of one or more Databases (SQL and/or NoSQL). Furthermore, AMQP can be used to communicate between the components.
In order to make sure that no tenant can access data of another tenant, each tenant will need their own databases. Thus, you will need to create them for each tenant. simply use the delivered create scripts to create the dedicated databases for each tenant.
For AMQP, you should also create the neccessary queues and exchanges per tenant for each component and configure the vHost to make sure that the correct messages are being sent to the correct tenant.
Enabling Multi tenancy
To enable multi-tenancy, it is necessary to activate multi-tenancy mode and define the permitted tenants. These defined tenants will subsequently be utilized in configuring additional multi-tenancy-related properties.
Enabling multi-tenancy requires that requests include an additional X-TENANT-ID header containing the name of the desired tenant. If this header is missing or the tenant name is not on the allowed list, a message will be logged indicating that the tenant could not be identified, and an HTTP status 400 (Bad Request) will be returned.
It is possible to change the name of the header using the following property
application.properties
blueriq.multi-tenancy.http-header=http-tenant-id
We advise to set up an HTTP server (for example NGINX or Apache HTTPD) which can be configured to add this HTTP header depending on, for instance, the url from which the Runtime is called.
We only support multi-tenancy where each tenant uses the same database vendor. You are not able to mix, for example, an Oracle tenant with an Microsoft SQL Server tenant.
Error rendering macro 'excerpt-include'
No link could be created for 'Multi-tenant setup COPY'.
Authentication - OAuth2 and Keycloak
In single-tenant mode as well as in multi-tenancy mode, OAuth2 and Keycloak can be used for the authentication mechanism. The difference with multi-tenancy is that the application now expects a claim to be present in the JWT token with the claim path name "tenant" and with the tenant name as value. This claim name is customizable if the tenant is present in the JWT token with a different claim name.
Customizing the tenant path
The tenant claim can be customized using aJsonPathexpression in the same way the roles-path and username-path can be set.
User 'null' does not have permission to view the page.
Event publisher tenant configuration
Since CDS 4.4 the customerdata service supports a multi-tenant event publisher. Enabling multi-tenancy means that properties for publishing aggregate event messages to a queue can be configured for each tenant. To enable the event publisher the entity-event-publisher-amqp profile should be active.
Tenant configuration
blueriq-customerdata-odata-service-v1.yml or blueriq-customerdata-odata-service-v1.properties
GET http://localhost:8080/api/v1/Aggregates HTTP/1.1
Content-Type: application/json
Authorization: Basic Ymx1ZXJpcTp3ZWxjb21l
X-TENANT-ID: google
Example Multi-tenancy DCM Lists Service configuration
blueriq-dcm-lists.yml
blueriq:
dcm:
lists:
multi-tenancy:
enabled: true
allowed-tenants:
- google
- apple
mongodb:
tenants:
google:
host: localhost
port: 27017
database: google
apple:
host: localhost
port: 27017
database: apple
rabbitmq:
tenants:
google:
host: localhost
port: 5672
virtualHost: google
username: google
password: welcome
ssl:
enabled: false
queueNames: googleQueue
apple:
host: localhost
port: 5672
virtualHost: apple
username: apple
password: welcome
ssl:
enabled: false
queueNames: appleQueue
Authentication
To be able to use the DCM Maintenance App, the user should be authenticated. This is done through Keycloak as explained in Blueriq Gateway and OAuth2 configuration. The difference with multi-tenancy is that the application now expects a claim to be present in the JWT token with the claim path name "tenant" and with the tenant name as value. This claim name is customizable if the tenant is present in the JWT token with a different claim name.
Customizing the tenant path
The tenant claim can be customized using aJsonPathexpression in the same way the roles-path and username-path can be set.