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.
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 TenantA (61).
Request
PUT https://MyServer:8443/api/admin/users/2001/tenantsadministered
Request Payload
{
"tenantsAdministered": [
61
]
}
Response Payload
{
"tenantsAdministered": [
61
]
}
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 TenantA (61).
PUT https://MyServer:8443/api/admin/tenants/61
Request Payload
{
"admins": [
391,
502,
2001
]
}
Response Payload
{
"admins": [
391,
502,
2001
]
}
Setting system configurations and limits
Setting a system configuration
The following PUT operation disables IP address whitelists across all tenants. The number 8 is the ID of the IP address whitelist feature.
PUT https://MyServer:8443/api/admin/configurations/8
{
"value":"false"
}
Setting a system limit
The following POST creates a limit of 50000 concurrent OData queries across all tenants. The number 6 is the ID of the ODataMaxConcurrentQueries limit. The payload passes 50000 as the value for this limit.
POST https://MyServer:8443/api/admin/limits/system/6
{
"value": 50000
}
Setting tenant limits
The following POST creates a limit of 10000 concurrent OData queries on TenantA. The number 61 is the ID of TenantA, and the number 6 is the ID of the ODataMaxConcurrentQueries limit. This tenant limit will override the system limit.
POST https://MyServer:8443/api/admin/limits/tenants/61/6
{
"value": 10000
}
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.
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": []
}
