skip to main content
Administering Hybrid Data Pipeline : Tenant architectures : Multitenant environment : System-level tenant administration
  

Try Now
System-level tenant administration
A system administrator may want to delegate or share user provisioning and other administrative tasks with a tenant administrator such that the tenant administrator can manage user accounts and enable supported features across multiple tenants. The following operations show how to set up a multitenant environment and provision a user at the system level to administer the tenants.
Note: The administration of tenants either from the system tenant or from within a tenant itself is not mutually exclusive. For example, a system administrator might want to delegate and isolate the administration of tenants, but also provision support personnel to work with resources across multiple tenants.
*Creating tenants with the Tenant API
*Retrieving roles with the Roles API
*Provisioning a user at the system level with the Tenant Administrator role
*Granting administrative access to the tenant with the Users API
*Granting administrative access to the tenant with the Tenant API
*Creating users and roles at the tenant level

Creating tenants with the Tenant API

In this example, a system administrator creates TenantA, TenantB, and TenantC using the Tenant API. The User (2) role has been specified as an imported role. As new tenants are created, the imported role becomes unique and is given a new ID.
Request to create TenantA
POST https://MyServer:8443/api/admin/tenants
Request Payload
{
"name": "TenantA",
"description": "This is the HDP tenant for organization A.",
"parentTenant": 1,
"status": 1,
"importedRoles": [
2
]
}
Response Payload
{
"id": 61,
"name": "TenantA",
"description": "This is the HDP tenant for organization A.",
"parentTenant": 1,
"status": 1,
"roles": [
81
]
}
Request to create TenantB
POST https://MyServer:8443/api/admin/tenants
Request Payload
{
"name": "TenantB",
"description": "This is the HDP tenant for organization B.",
"parentTenant": 1,
"status": 1,
"importedRoles": [
2
]
}
Response Payload
{
"id": 62,
"name": "TenantB",
"description": "This is the HDP tenant for organization B.",
"parentTenant": 1,
"status": 1,
"roles": [
82
]
}
Request to create TenantC
POST https://MyServer:8443/api/admin/tenants
Request Payload
{
"name": "TenantC",
"description": "This is the HDP tenant for organization C.",
"parentTenant": 1,
"status": 1,
"importedRoles": [
2
]
}
Response Payload
{
"id": 63,
"name": "TenantC",
"description": "This is the HDP tenant for organization C.",
"parentTenant": 1,
"status": 1,
"roles": [
83
]
}

Retrieving roles with the Roles API

The system administrator must have the role ID to create a user with the Tenant Administrator role. The following GET operation retrieves the roles across the system.
Request
GET https://MyServer:8443/api/admin/roles
Response Payload
The first three roles in the payload are roles tied to the system tenant ("tenantId": 1). The remaining roles are the roles copied to the new tenants.
{
"roles": [
{
"id": 1,
"name": "System Administrator",
"tenantId": 1,
"description": "This role has all permissions. This role cannot be
modified or deleted."
},
{
"id": 2,
"name": "User",
"tenantId": 1,
"description": "This role has the default permissions that a normal
user will be expected to have."
},
{
"id": 3,
"name": "Tenant Administrator",
"tenantId": 1,
"description": "This role has all the tenant administrator
permissions."
},
{
"id": 81,
"name": "User",
"tenantId": 61,
"description": "This role has the default permissions that a normal
user will be expected to have."
},
{
"id": 82,
"name": "User",
"tenantId": 62,
"description": "This role has the default permissions that a normal
user will be expected to have."
},
{
"id": 83,
"name": "User",
"tenantId": 63,
"description": "This role has the default permissions that a normal
user will be expected to have."
}
]
}

Creating a user at the system level with the Tenant Administrator role

With the following User API operation, the system administrator creates a user at the system level with the Tenant Administrator role. The tenant administrator must then be given administrative access to the tenant either through the Users API or the Tenant API, as described below.
Request
POST https://MyServer:8443/api/admin/users
Request Payload
{
"userName": "SysTenantAdmin",
"tenantId": 1,
"statusInfo": {
"status": 1,
"accountLocked": false
},
"passwordInfo": {
"password": "TempWord",
"passwordStatus": 1,
"passwordExpiration": null
},
"permissions": {
"roles": [
3
]
}
}
Response Payload
{
"id": 1001,
"userName": "SysTenantAdmin",
"tenantId": 1,
"statusInfo": {
"status": 1,
"accountLocked": false
},
"passwordInfo": {
"passwordStatus": 1,
"passwordExpiration": null
},
"permissions": {
"roles": [
3
]
},
"authenticationInfo": {
"authUsers": [
{
"authUserName": "SysTenantAdmin",
"authServiceId": 1
}
]
}
}

Granting administrative access to the tenant with the Users API

In addition to user management permissions, a tenant administrator must be granted administrative access to the tenant. This can be done either through the Users API or the Tenant API. The following Users API request grants user account 2001 administrative access to the OrgA tenant (71).
Request
PUT https://MyServer:8443/api/admin/users/2001/tenantsadministered
Request Payload
{
"tenantsAdministered": [
71
]
}
Response Payload
{
"tenantsAdministered": [
71
]
}

Granting administrative access to the tenant with the Tenant API

In addition to user management permissions, a tenant administrator must be granted administrative access to the tenant. This can be done either through the Users API or the Tenant API. The following Tenant API request adds user account 2001 to the list of administrators who can administer the OrgA tenant (71).
PUT https://MyServer:8443/api/admin/tenants/71
Request Payload
{
"admins": [
391,
502,
2001
]
}
Response Payload
{
"admins": [
391,
502,
2001
]
}

Creating users and roles at the tenant level

The new system-level tenant administrator (SysTenantAdmin) can now provision users and create roles for TenantA, TenantB, and TenantC. The first request creates a new user in TenantA (61). The second request creates a new role in TenantA.
Request to create user in TenantA
POST https://MyServer:8443/api/admin/users
Request Payload
{
"userName": "User1A",
"tenantId": 61,
"statusInfo": {
"status": 1,
"accountLocked": false
},
"passwordInfo": {
"password": "TempWord",
"passwordStatus": 1,
"passwordExpiration": null
},
"permissions": {
"roles": [
81
]
}
}
Response Payload
{
"id": 2601,
"userName": "User1A",
"tenantId": 1,
"statusInfo": {
"status": 1,
"accountLocked": false
},
"passwordInfo": {
"passwordStatus": 1,
"passwordExpiration": null
},
"permissions": {
"roles": [
81
]
},
"authenticationInfo": {
"authUsers": [
{
"authUserName": "SysTenantAdmin",
"authServiceId": 1
}
]
}
}
POST operation to create new role
With the following POST request, a new role is created in TenantA (61) for OData-only access to data sources. No user is specified in this example, but a user can subsequently be assigned the new role either through the Roles API or the Users API.
Request to create role in TenantA
POST https://MyServer:8443/api/admin/roles
Request Payload
{
"name": "ODataOnly",
"tenantId": 61,
"description": "This role allows only OData access.",
"permissions": [7],
"users": []
}
Response Payload
{
"id": 102,
"name": "ODataOnly",
"tenantId": 61,
"description": "This role allows only OData access.",
"permissions": [
7
],
"users": []
}