In our continuous effort to improve Restcomm functionalities, we have introduced multi-tenancy as part of Restcomm 7.4.0. Multi tenancy support provides a set of rules that improve user information management and control who can gain access to specific accounts. This set of rules will be also applied by the upcoming OAuth support, so they both OAuth and Multi-tenancy Support will handle this consistency together. The information below will provide an overview of how multi-tenancy is applied to Restcomm.
Restcomm REST API access control is managed by two main entities, credentials and accounts. To better understand how it works, we’ll assume the following diagram as the account hierarchy, where each account and sub account has its own information.
Considering that Primary and Secondary accounts represents different Restcomm users, they will not be able to manage information from each other. So if Primary Account tries to access the REST API using its own credentials but requesting for the list of DIDs of the Secondary Account, the response will be a HTTP 401 error. The 'curl' command below represents the given situation.
curl -X GET https://<accountSid>:<authToken>@cloud.restcomm.com/restcomm/2012-04-24/Accounts/[secondarySid]/IncomingPhoneNumbers.json
As mentioned above, there are more possible combinations between credentials and accounts used to request information through the API. But instead list all those possibilities, we can assume the pattern used by the API to control access in a general way, grouped by the result obtained from the API:
Request information about the same account used as credential
Request information about a sub account of the account used as credential
Request information about the parent account of the account used as credential
Request information about a account of the same level of the account used as credential
Request information about a sub account different than the ones from the account used as credential
To understand this rules based on the hierarchy presented by the diagram above, we can assume the following for each account:
Primary Account can view and manage Primary Application, DID P, DID A and DID B only.
Subaccount A can view and manage Application A and DID A only.
Subaccount B can view and manage Application B and DID B only.
Secondary Account can view and manage Application S, DID S, DID C and DID D only.
Subaccount C can view and manage Application C and DID C only.
Subaccount D can view and manage Application D and DID D only.
|The Applications API has a different access control, and allows the accounts to manage its own applications only. So, if a request is made to this API using a credential different than the account, the response will be a HTTP 401 error.|
The user interface follows a similar behaviour to the API. Is known that the AdminUI currently shows only info related to the logged user, but now the local applications displayed under the 'Restcomm Apps' option were adjusted to follow the same behaviour. This filter is also applied to the available applications when configuring a DID, as shown by the images below.
This is the way that multi tenancy support provides access control between accounts, ensuring that only authorized accounts will be able to see and manage another accounts info.
If the hostname of the request doesn’t match the organization domain name of the provided account credential Restcomm-Connect will not allow access.
For example, if trying to login to 'https://wonderland.restcomm.com' using account credentials that belong to organization 'https://alice.restcomm.com', Restcomm-Connect will drop the request.
Same is true for accessing organization/account resources using REST API. If the hostname of the REST API request doesn’t match the domain name of the organization that the account credentials belong, Restcomm-Connect will drop the request.