Role-Based Access Controls | Vendia

Role-Based Access Controls

Vendia provides comprehensive role-based access controls (RBAC) to enable administrators to control the actions users are permitted to take and the resources on which they can operate.

Vendia’s RBAC system is designed to be both simple to use and highly secure. It enables system administrators to easily limit who can access their corporate data and code, constrain employee and business partner activities, and secure critical systems from accidental mishandling. Developers using Vendia’s free tier, however, can largely ignore RBAC while learning the system, because default role permissions and automatic permission boundary management automates away most of the need for explicit permissions management in typical usage scenarios.

Note: While RBAC controls who can access data, Receipts track who actually accessed data, providing comprehensive audit trails that complement your access control policies.

Scope of RBAC

RBAC modulates the interaction between Vendia users and Vendia APIs and resources. RBAC may be used to determine whether a Vendia user is permitted to access the data in a project. In addition, each project workspace possesses its own user identity and authorization mechanisms, which are outside the scope of RBAC.

Key Terms

Actions

User Actions

Vendia supports the following actions on user accounts:

Apart from USER_INVITE, user actions are typically reserved for administrators.

To comply with GDPR, CCPA, and similar regulations, every user on the Vendia system is automatically granted USER_GET and USER_SET_EMAIL for themselves; these rights cannot be removed.

Project Actions

Vendia supports the following actions on projects:

Organization Actions

Vendia supports the following actions on Organizations:

Data Actions

Vendia supports the following actions for data stored with a workspace

Resource Formats

Name Resources

Vendia users are identified by the current email address associated with their Vendia account. ’*’ may be used as a wildcard, or to indicate that no subdomain is required. Examples:

All user commands (getuser, userSetEmail, etc.) require resources using name formats.

JSON Example:

{
  "action": "USER_ALL",
  "resources": ["NameResource(*@acme.com)"] // Access to all users with the acme.com domain
}

Project Resources

Project commands can take one of several forms:

JSON Example:

{
  "action": "UNI_GET",
  "resources": [
    "VendiaResource(owned)", // Access to all projects that the user owns
    "UniResource(*.unis.acme.com)", // Access to all projects in the unis.acme.com namespace
    "UniResource(my-uni.unis.foo.com)", // Specific access to my-uni.unis.foo.com
    "UniResource(another-uni.unis.bar.com#NodeOne)" // Very specific access to a single workspace in the project another-uni.unis.bar.com
  ]
}

Data Access

Data access requires the Vendia Resource path style:

JSON Example:

{
  "action": "DATA_READ",
  "resources": [
    "VendiaResource(730c2b51-7a7a-42a2-a192-8bef734a95a1/my-uni.unis.acme.com/*)", // Access to all workspaces owned by Acme in the my-uni.acme.com Uni
    "VendiaResource(730c2b51-7a7a-42a2-a192-8bef734a95a1/another-uni.unis.acme.com/NodeOne)", // Access to only NodeOne in the another-uni.unis.acme.com Uni
    "VendiaResource(2fa4bc9d-7d62-4ad6-8d07-4b021bce762b/*)" // Access to all workspaces owned by Foo in all of Foo's Unis
  ]
}

Permission Boundaries

Vendia’s RBAC system includes a built-in permission boundary feature that prevents escalation of privileges. Permission boundaries impact administrative features, such as USER_SET_ROLE. Without a permission boundary, users would be allowed to escalate their privileges.

To prevent this from happening, the effect of calling setUserRole is required to be a subset of the role of the caller. In other words, users cannot create or alter roles to be more powerful than themselves.

As an example, an administrator with UNI_ALL: *.*.acme.com rights would be allowed to grant UNI_GET: test1.*.acme.com to another user (or themselves), but could not grant UNI_GET: test1.*.other_domain.com to any user.

Permission boundaries are enforced automatically - no user action is required.

Assigning permissions in the Vendia UI

An organization administrator with the appropriate permissions may modify other users’ roles in the Vendia UI by navigating to My Organization > Members > Select Member. The admin user may select from a list of pre-defined roles to assign to the user.

Assigning permission in the Vendia CLI

Using the Vendia CLI, an organization administrator with the appropriate permission may assign a user a custom role. For more information, visit the CLI documentation

{
  "name": "default",
  "capabilities": [
    {
      "action": "ORG_GET",
      "resources": [
        "OrganizationResource(730c2b51-7a7a-42a2-a192-8bef734a95a1)"
      ]
    },
    {
      "action": "ORG_LIST_USERS",
      "resources": [
        "OrganizationResource(730c2b51-7a7a-42a2-a192-8bef734a95a1)"
      ]
    },
    {
      "action": "UNI_JOIN",
      "resources": ["UniResource(*.unis.acme.com#*)"]
    },
    {
      "action": "UNI_CREATE",
      "resources": ["UniResource(*.unis.acme.com#*)"]
    },
    {
      "action": "UNI_GET",
      "resources": ["VendiaResource(owned)", "UniResource(*.unis.acme.com#*)"]
    },
    {
      "action": "UNI_MUTATE",
      "resources": ["VendiaResource(owned)"]
    },
    {
      "action": "UNI_EVOLVE_SCHEMA",
      "resources": ["VendiaResource(owned)"]
    },
    {
      "action": "UNI_INVITE",
      "resources": ["VendiaResource(owned)"]
    },
    {
      "action": "UNI_RESET",
      "resources": ["VendiaResource(owned)"]
    },
    {
      "action": "UNI_DELETE",
      "resources": ["VendiaResource(owned)"]
    },
    {
      "action": "UNI_DELETE_NODE",
      "resources": ["VendiaResource(owned)"]
    },
    {
      "action": "USER_INVITE",
      "resources": ["NameResource(*@*.*.*)"]
    }
  ]
}

share auth role set ./policy.json --user test@acme.com

Types of Users and Default Roles

Often, Vendia users are referred to as “normal” or “administrator” depending on their privileges. However, the privileges of individual users may vary from company to company and even among accounts. For instance, an administrator for acme.com may decide that its users should not be permitted to call destroy or reset, because these actions potentially cause loss of data. Other companies may grant their users both privileges, or grant it only for projects in a development subdomain but not in the production subdomain.

Default users operating in the Vendia free tier have access to only the default namespace, *.unis.vendia.com. Up to the available (per-user) limits, they can create new projects and workspaces in this namespace and have access to call any API on the projects in which they own at least one workspace. Free tier users do not possess any user privileges except for the “built-in” right to view and update their own user account information and invite other free tier users to join their projects.

The privileges of a default user operating under an enterprise agreement varies depending on the setup requested by the company’s Vendia account administrator. The initial user account created for enterprise agreements is typically an administrator account, with full permission to create new users and roles in one or more corporate-owned namespaces. For more information on enterprise configuration, contact Vendia sales or email support@vendia.net.

Role Based Row Level Security for Reads

NOTE: Available in SQL-Enabled Projects Only

Vendia supports role based row-level security (RLS), also known as conditional_roles for reading data via GraphQL in SQL-Enabled projects. RLS allows you to restrict read access to rows in an entity based on the role characteristics of the user executing a query.

Usage

To implement RLS, add conditions to the DATA_ALL or DATA_READ policy definition in the role. These conditions complement existing permissions by adding an additional layer of filtering to restrict access based on specific criteria. They do not override other permissions but work in conjunction with them to refine access control.

{
  "DATA_ALL": {
    "action": "DATA_ALL",
    "resources": ["NameResource(*@acme.com)"],
    "conditions": [
      {
        "entityName": "Inventory",
        "operation": "EQ",
        "key": "itemName",
        "value": "test_1"
      }
    ]
  },
  "DATA_READ": {
    "action": "DATA_READ",
    "resources": ["NameResource(*@acme.com)"],
    "conditions": [
      {
        "entityName": "Inventory",
        "operation": "EQ",
        "key": "itemName",
        "value": "test_1"
      }
    ]
  }
}

Parameters

Warning: If the value of the entityName in the conditions definition does not correctly match the entity in the system (e.g., due to a typo), the conditional_role will be ignored, and the user will receive unfiltered data.

This behavior will not generate any error or warning in the logs. Users must carefully verify their entityName values to avoid unintended access.

The above condition will restrict the user to only read rows in the Inventory entity where the itemName is test_1.

Users can create filters on multiple fields of the same entity, and this will result in itemName == test_1 AND color == black.

{
  "DATA_ALL": {
    "action": "DATA_ALL",
    "resources": ["NameResource(*@acme.com)"],
    "conditions": [
      {
        "entityName": "Inventory",
        "operation": "EQ",
        "key": "itemName",
        "value": "test_1"
      },
      {
        "entityName": "Inventory",
        "operation": "EQ",
        "key": "color",
        "value": "black"
      }
    ]
  }
}

Note: Refer to the warning above regarding typos in entityName values.

Limitations

User Deactivation

When a user account is deactivated, the user will no longer be able to log in to Vendia. However, any data or resources owned by the user will remain intact and accessible to other users with the appropriate permissions.

Required Permissions for User Deactivation

{
  "USER_ALL": {
    "action": "USER_ALL",
    "resources": ["NameResource(*@acme.com)"],
    "conditions": []
  },
  "USER_DEACTIVATE": {
    "action": "USER_DEACTIVATE",
    "resources": ["OrganizationResource(730c2b51-7a7a-42a2-a192-8bef734a95a1)"],
    "conditions": []
  }
}

Steps to Deactivate a User from the Vendia UI

  1. Navigate to the My Organization page.
  2. On the Members overview page, click the member you want to deactivate.
  3. Click the Deactivate Member button at the bottom of the User overview page of the user selected in the previous step.

Note: The Deactivate Member button is visible only if the selected member is an active member. It will be hidden for inactive members or for users who lack the USER_ALL or USER_DEACTIVATE permissions.

  1. You will be prompted to confirm the deactivation. Type the email address of the member and click Deactivate to proceed.

Important: Users cannot deactivate themselves even if they have the required permissions.

Steps to View Deactivated Users

Viewing deactivated users can help administrators manage user accounts effectively by identifying inactive members and ensuring proper access control.

  1. Navigate to the My Organization page.
  2. On the Members overview page, any user with USER_ALL or USER_DEACTIVATE permissions can view deactivated users by clicking the Show deactivated members checkbox.

Note: The checkbox is only visible if the current user has USER_ALL or USER_DEACTIVATE permissions.

User Reactivation

To reactivate a user, please contact Vendia support via support case or via email support@vendia.net. Include the user’s email address, organization ID, and a brief description of the reason for reactivation to expedite the process.