Using multi-tenancy via multiple private states
Use multi-tenancy via multiple private states (MPS) to allow multiple tenants to use the same GoQuorum node, with each tenant having its own private state(s).
Configure multi-tenancy via multiple private states
- Tessera version
21.4.0or later installed
- GoQuorum version
21.4.2or later installed
If running an earlier GoQuorum or Tessera version, upgrade your existing nodes to enable MPS and multi-tenancy using the migration guide.
configitem of the GoQuorum genesis file.MPS configuration
There can be a mix of MPS-enabled and non-MPS-enabled nodes in a network.
Configure the JSON-RPC security plugin. This requires configuring an authorization server. View examples of configuring the plugin to work with different OAuth2 authorization servers.
truein the Tessera configuration file. The default is
GoQuorum can't start if
truein the GoQuorum configuration and
falsein the Tessera configuration.
GoQuorum runs as a non-MPS-enabled node if
residentGroupsin the Tessera configuration file.
Run GoQuorum with the
--multitenancycommand line option.
geth [OPTIONS] --multitenancy --plugins file:///<path>/<to>/plugins.json
In the command,
plugins.jsonis the plugin settings file that contains the JSON-RPC Security plugin definition.
For example, if you use quorum-security-plugin-enterprise,
plugins.jsonlooks like the following:plugins.json
Configure custom scopes
A network operator must configure scope values for each user in an authorization server, for each tenant.
This example network contains four nodes. Multi-tenant
Node1 is shared between tenant
isMPS=true) and single-tenant
Node2 is used by tenant
D alone (
A node consists of a GoQuorum client and Tessera private transaction manager. We name privacy manager key pairs for easy referencing, for example:
G_K1. In reality, their values are the pubic keys used in the
Tenants are assigned to multi-tenant nodes as follows:
J_K2, and its tenancy is on
G_K2, and its tenancy is on
D_K1, and its tenancy is on
J Organization and
G Organization may decide to allocate keys to their departments, therefore the security model may be as follows:
J Investmenthas access to
Jtenancy using any self-managed Ethereum accounts.
J Settlementhas access to
Jtenancy using node-managed Ethereum account
J_ACC1and a self-managed
G Investmenthas access to
Gtenancy using any self-managed Ethereum accounts.
G Settlementhas access to
Gtenancy using node-managed Ethereum account
Each authorization server has its own configuration steps and client onboarding process. A network operator's responsibility is to implement this security model in the authorization server by defining custom scopes and granting them to target clients.
A custom scope representing
J Investment is:
A custom scope representing
G Settlement is:
Clients must also be granted scopes which specify access to the JSON-RPC APIs:
Refer to the JSON-RPC security plugin documentation for more information.
Add a new tenant to multi-tenant node
Use the following steps to add a new tenant to a multi-tenant node:
The network administrator executes Tessera keygen to generate a new key.
Update the Tessera configuration file to include the new key in a resident group.
Restart Tessera to load the new key. Startup fails if the new key is generated but not added to a resident group.
Make updates to the authorization server to provide the new tenant access to the private state defined in the resident groups configuration.
eth_getMPS JSON-RPC API method to get the private state the user is operating on.