Access Control in Clumio

At Clumio, we recognize that Authentication and Authorization are critical requirements for enterprise companies. Enterprises have multiple business units, each with their own employees, data, workloads and data protection needs. Clumio offers robust mechanisms that our customers can use for safeguarding against unauthorized access.

Simply put, Access Control is the mechanism that controls access to resources and the actions users can perform on those resources.

Administrators leveraging the Clumio SaaS platform can make use of two features — Organizational Units and Roles to achieve Access Control.

Administrators can group the resources created in Clumio into Organizational Units (OUs). Resources include, but aren’t limited to, AWS Accounts and M365 domains.

OUs form a tree-like hierarchy with the Global Organizational Unit at its root. Administrators can further create descendant OUs for their Business Units or Departments to have the resources isolated from one another.

Assigning OUs to users will effectively control which resources they have access to. On the Clumio portal, a user has the option to choose which OU context they want to operate in. At any given time, the Clumio portal shows resources present in the chosen OU and all its descendants.

As in the above illustration, a user with access to Accounting OU can only see and use the assets in that OU – AWS-account-1 and M365-domain-1, and nothing from the R&D OU.

Role based access control (RBAC) is a widely used mechanism for controlling access to resources. The Role determines what actions the user can perform on the resources.

Clumio offers several predefined Roles with certain permissions for an exhaustive RBAC configuration.

The Access Control framework identifies the OUs to control which resources users can access, and the Role permissions to allow or deny actions on those resources.

As shown in the diagram, a user may belong to multiple OUs and can have exactly one Role. These mappings are stored in the backend databases and also cached appropriately for quick access.

Clumio uses an API Gateway as a unified entry-point for external clients to access the services via REST APIs. Check out a previous blog — Leveraging AWS API gateway in Clumio — to dive deeper into that.

The access control validation begins right at the API Gateway. All the incoming REST API requests are authenticated to ensure only registered user identities are accessing the Clumio SaaS platform. This is done by virtue of a JSON Web Token (JWT) in the Authorization HTTP header. A failed authentication would result in a 401 Unauthorized HTTP status code in the response.

After authentication at the API Gateway has succeeded, the incoming requests go through a middleware which implements authorization to validate OU and Role memberships for the user.

A user may belong to multiple OUs. The HTTP API request identifies the user’s current OU. The middleware validates that the user has access to this OU. If not, the API fails with a 403 Access Denied HTTP error code.

Using the user’s ID and the OU ID, we fetch the corresponding Role from the backend services. The Role determines whether they have the requisite permissions to make this API request in the first place.

There are three constructs that are used together to achieve Role based Access Control:

• Role
• Permission set for the Role
• API operation ID

Every API endpoint is assigned a unique operation ID. A Permission set is a collection of these operation IDs like below. The Policy Management permission set has two categories – Full and Partial. In most cases, partial only includes the read-only operations.

A Role is then mapped to a group of Permission sets. Effectively, a Role is mapped to a group of API operation IDs. The Permission set construct offers a simple way for each software developer to make use of the Access Control framework.

For each API request, the middleware checks if the Role contains the operation ID. If not, the request fails with a 403 HTTP error code. However, if both validations succeed, the API request continues and the request goes ahead to downstream services. All details about the user, including the OU and Role details are injected into the request before forwarding it, so that the downstream services can make use of them readily.

The Clumio portal adapts to the current user’s level of access. For example, a Super Admin has more permissions than Backup Admin. If a user attempts to perform an action they aren’t allowed to, the operation fails with an error. For a seamless user experience, the Clumio portal proactively blocks the user from performing such actions in the first place. This is primarily done by hiding or greying out action buttons/links, hiding pages etc with appropriate tooltips.

How does an API client know what to show or hide?

The answer — HATEOAS links. HATEOAS is a standard REST API practice and Clumio makes use of it extensively.

In a nutshell, REST API responses contain HATEOAS links, which specify what further actions can be made by the user on the current state of this resource. For example, the response of GET /policies/definitions/ could have the following links.

The presence of these links indicate that the current user is permitted to make these API requests, and thus the portal allows the user to do so. If the response does not have the "delete-policy-definition" link, the portal greys out the delete action button, to prevent the user from attempting to delete it. The API response from the server encapsulates all the required details around what to allow or deny, and the portal relies on it to deliver an elegant user experience.

Enterprise customers expect data protection platforms such as Clumio to have access control features that are comprehensive, robust and easy to use. The combined use of Organizational Units and Roles helps administrators configure users’ access as per their specific needs.

Administrators can invite users to the Clumio platform with the appropriate Role and OU access specified. In addition, customers who use Single Sign-On (SSO) can also integrate their Identity Provider with Clumio and leverage Clumio’s Auto User Provisioning feature to automate the Access Control configuration across users.