---
title: "Cluster - User Access Management · RUAL Documentation"
description: "Within your cluster, you have the capability to create various types of users, each specifically tailored for roles such as developers, customers, or visitors."
canonical: https://docs.rual.nl/cluster/user-access-management
language: en
---

# User Access Management (UCM)

Create and manage cluster users in RUAL Studio: accounts, permissions, user groups, security settings, and auditing.

Within your cluster, you have the capability to create various types of users, each specifically tailored for roles such as developers, customers, or visitors. This guide covers the full account lifecycle: creating users, assigning permissions, organizing user groups, securing accounts, and auditing access. It is written for cluster administrators. If you need an account yourself, start with [Getting Access](https://docs.rual.nl/cluster/getting-access). For a deeper look at how roles and permissions fit together. See [User Roles Explained](https://docs.rual.nl/cluster/user-roles-explained).

### Users Overview

In the [RUAL Studio](https://docs.rual.nl/interfaces/rual-studio), when you access the `All users` section from the left-side menu, you will find a comprehensive list of all active users within your cluster. Users marked with a `*` (star) symbol possess full access to all resources within the cluster, subject to any specific settings enabled or disabled on their accounts.

### Creating a User

RUAL clusters have no public sign-up. Every account is created by an administrator. Creating and editing users requires the `Manage User Permissions` permission or full (`*`) access.

- Open [RUAL Studio](https://docs.rual.nl/interfaces/rual-studio), select your cluster, and go to `All users` in the cluster settings section of the left-side menu.

- Click `Create user` to open the create dialog.

- Fill in the user details: a **username** and a **password**, plus any profile fields your cluster uses. Share the credentials with the user privately: [Getting Access](https://docs.rual.nl/cluster/getting-access) describes what a new user needs for their first login.

- Save the user. The account is created immediately and appears in the `All users` list.

- Open the new user from the list to fine-tune the account: enable [permissions](#permissions), set [account settings](#settings), add [custom scopes](#giving-user-permission), or assign [user groups](#user-groups).

Every user is stored as a document in the cluster, so anything you can set in the dialog can also be managed from blueprints or through the [cluster APIs](https://docs.rual.nl/cluster/api).

### Permissions

This section details each permission available in the RUAL Studio and its specific function.

- `Cluster Admin`: This permission is typically granted to a select few who require complete access to all resources within the cluster.

- `Blueprints: All Access`: Grants the ability to view and remove any blueprint. This permission is exclusively available to developers.

- `Wildcard Scope`: Provides comprehensive access to any Cluster, custom API, and custom page created in RUAL. This is essential for developers to create new resources.

- `Staging Developer`: Enables a developer to view, modify, and simulate blueprints.

- `Production Developer`: Allows a developer to view, modify, and deploy blueprints to production.

- `Blueprints: Production Run`: Controls the `Run: Production` feature in play mode within blueprints.

- `Blueprints: Activate Blueprints`: Grants access to activate or deactivate blueprints.

- `Blueprints: Remove Blueprints`: Enables users to remove blueprints, with all actions recorded in the audit log.

- `Blueprints: Deploy Blueprints`: Enables users to deploy blueprints to production.

- `Manage User Permissions`: Required to manage other users' permissions. Users without this cannot modify accounts with higher permissions.

- `Manage System Settings`: Allows users to modify, view, and create system settings. Access to secured system settings is logged.

- `Manage Storages`: Permits users to create, update, or delete storages within blueprints.

- `Manage Domains`: Enables users to create, update, or delete domains within the cluster.

- `Manage Custom Components`: Enables users to create, update, or delete React Components within the cluster.

- `View Cluster Statistics:`: Enables users to view statistics for this cluster on the cluster statistics page or request them with API.

#### Permission matrix

The same permissions grouped by area, with what they allow and the user type each is typically granted to:

| Area | Permission | What it allows | Typical user type |
| --- | --- | --- | --- |
| Blueprint editing | `Wildcard Scope` | Access to any cluster, custom API, and custom page created in RUAL; required to create new resources | Every developer |
| `Staging Developer` | View, modify, and simulate blueprints | Developer |  |
| `Blueprints: All Access` | View and remove any blueprint | Lead developer |  |
| `Manage Storages` | Create, update, or delete storages within blueprints | Developer |  |
| `Manage Custom Components` | Create, update, or delete React Components | Frontend developer |  |
| Production | `Production Developer` | View, modify, and deploy blueprints to production | Senior developer / release manager |
| `Blueprints: Production Run` | Use `Run: Production` in play mode | Developer debugging against live data |  |
| `Blueprints: Activate Blueprints` | Activate or deactivate blueprints | Developer |  |
| `Blueprints: Deploy Blueprints` | Deploy blueprints to production | Release manager |  |
| `Blueprints: Remove Blueprints` | Remove blueprints (recorded in the audit log) | Lead developer |  |
| User management | `Manage User Permissions` | Create and edit users and manage their permissions; cannot modify accounts with higher permissions | Administrator |
| Security & cluster | `Cluster Admin` | Complete access to all resources within the cluster | Cluster owner |
| `Manage System Settings` | Modify, view, and create system settings; access to secured settings is logged | Administrator |  |
| `Manage Domains` | Create, update, or delete domains within the cluster | Administrator |  |
| `View Cluster Statistics` | View the cluster statistics page or request statistics through the API | Operations / viewer |  |

### Example Access Levels

Most accounts fall into one of a few typical access levels. Use these as a starting point and adjust to your team:

| Access level | Typical setup | What the user can do |
| --- | --- | --- |
| **Full-access administrator** | Starred (`*`) account with `Cluster Admin` and the `is_root_user` setting enabled | Everything: blueprints, deployment, user management, and system settings. Reserve for one or two cluster owners. |
| **Production developer** | `Wildcard Scope`, `Staging Developer`, `Production Developer`, `Blueprints: Activate Blueprints`, `Blueprints: Deploy Blueprints`: without `Manage User Permissions` | Edit and save blueprints and deploy them to production, but cannot manage users or security settings. |
| **Read-only viewer** | No developer or manage permissions; only view scopes through `custom_scopes` (optionally `View Cluster Statistics`) | Sign in and view the pages, APIs, and statistics their scopes allow, without modifying anything. |
| **API-only integration user** | A regular account with only the `custom_scopes` of the endpoints it needs to call | Authenticates through the login APIs and calls cluster APIs with an `access_token`. Never intended for RUAL Studio work. See [Getting Access](https://docs.rual.nl/cluster/getting-access#development-environment) and [Cluster APIs](https://docs.rual.nl/cluster/api). |

### Giving user a permission

To assign a permission to a user, add the permission name as a value in the `custom_scopes` array field within the user's document. This enables the user to access the associated pages or APIs as defined by the scope.

Example of a user granted two scopes:

```
{
  "custom_scopes": [
    "view_customers",
    "create_orders"
  ],
  "username": "john.doe"
}
```

### User Groups

User groups provide a convenient way to manage permissions for multiple users by organizing them into logical groups. Instead of assigning scopes to each user individually, you can create groups with predefined scopes and assign users to these groups.

#### Creating User Groups

User groups are stored in the `usergroups` database. Each group contains:

- `name`: A descriptive name for the group (e.g., "Sales", "Finance", "Support")

- `scope`: An array of scope values that define all permissions for users in this group

Example of a user group document stored in the `usergroups` database:

```
{
  "name": "Sales",
  "scope": [
    "view_customers",
    "create_orders",
    "view_reports"
  ]
}
```

#### Assigning Users to Groups

To assign a user to one or more groups, add the group GUIDs to the `groups_guid` array field in the user's document. When a user is assigned to multiple groups, they receive all unique scopes from all groups they belong to.

#### Example Use Cases

| Group Name | Example Scopes | Use Case |
| --- | --- | --- |
| `Sales` | `view_customers`, `create_orders`, `view_reports` | Sales team members who need access to customer data and order creation |
| `Finance` | `view_reports`, `manage_invoices`, `view_payments` | Finance team members who need access to financial data and reports |
| `Support` | `view_customers`, `view_tickets`, `create_notes` | Support team members who need to help customers and manage tickets |

Example of a user assigned to both Sales and Finance groups:

```
{
  "custom_scopes": [],
  "groups_guid": [
    "94ad734891564818888bea7e2519aedd",
    "1c5bfaf8fb034f8498d204c5072b554e"
  ],
  "username": "john.doe"
}
```

In this example, the user will receive all unique scopes from both the Sales and Finance groups, plus any individual scopes defined in their own `custom_scopes` field.

### Account Settings

Settings in RUAL provide fine-grained control and customization options for various user accounts. While some settings align with permissions discussed earlier, there are some distinct ones worth noting.

| Key | Description |
| --- | --- |
| `allow_login_as_user` | When this setting is enabled `on`, it grants the ability to utilize the [user signin as](https://docs.rual.nl/block-types/users/function_user_signin_as) function for user accounts. If this setting is not enabled for an account, you won't be able to employ the [user signin as](https://docs.rual.nl/block-types/users/function_user_signin_as) function within blueprints for that account. Please note that this setting cannot be enabled for accounts with the `is_root_user` setting enabled. |
| `is_root_user` | This setting is enabled for user accounts designated as cluster administrators. Such accounts enjoy additional security measures against login attacks, password forget requests, and sign-in functionality. |
| `setting_manage_users` | User accounts with this setting set to `on` have the authority to configure the `allow_login_as_user` setting for other accounts. If the target account already exists, only users with this setting enabled can configure it. |

Example object of settings data

```
{
  "settings": [
    {
      "key": "allow_login_as_user",
      "value": "off"
    },
    {
      "key": "is_root_user",
      "value": "on"
    }
  ]
}
```

### Editing, Resetting, and Removing Users

Click any user in the `All users` list to open their detail page, where you can change permissions, settings, custom scopes, and group membership, then save. Keep in mind that users without `Manage User Permissions` cannot modify accounts with higher permissions than their own.

Each row in the users table also has quick actions:

- `Activity`: opens the [User Activity](#auditing) page for that account, so you can review what the user has been doing in the cluster.

- `Reset`: resets the failed login attempt counter. RUAL blocks repeated unsuccessful authentication attempts, so use this to unlock a user who was locked out after too many wrong passwords.

- `Delete`: permanently removes the account and revokes the user's access to the cluster. Use this when someone leaves the project. It cannot be undone.

### Requesting Access

If you need access to a cluster, you cannot create an account yourself. An administrator of that cluster must create one for you.

- **You know an administrator:** send them your name and the role you need. [Getting Access](https://docs.rual.nl/cluster/getting-access) walks you through receiving credentials and your first login.

- **You don't know who manages the cluster:** ask the person or team that invited you to the project. They can point you to the cluster owner.

- **You are the administrator and locked out by a broken custom login page:** append `?studio=request` to the cluster URL to reach the default login page. See [Overwrite Default Pages](https://docs.rual.nl/interfaces/overwrite-default-pages).

### Security Best Practices

- **Least privilege**: grant only the permissions a user needs for their role, preferably through [user groups](#user-groups) instead of individual scopes.

- **Limit full-access accounts**: keep the number of starred (`*`) users small, and enable `is_root_user` on them for additional protection against login attacks, password forget requests, and sign-in abuse.

- **Be careful with `allow_login_as_user`**: it lets blueprints sign in as that account through the [user signin as](https://docs.rual.nl/block-types/users/function_user_signin_as) function. Enable it only for accounts that genuinely need impersonation (for example support flows), and control who may enable it with `setting_manage_users`. It can never be enabled on `is_root_user` accounts.

- **Review access regularly**: delete accounts of people who left the project, and unlock legitimate users with the `Reset` action instead of sharing accounts.

### Auditing User Access

The **User Activity** page shows what an individual account has been doing in the cluster. Open it through the `Activity` action on a user in the `All users` table. Activity data is also available through the cluster APIs with the `user_activity_view` scope, for example to feed an external monitoring tool.

Sensitive cluster actions are recorded in the audit log as well. Every blueprint modification and removal, and every access to a secured system setting. Review the audit log after incidents and on a regular schedule; see [Audit log navigation](https://docs.rual.nl/troubleshooting/debugging#audit-log) for where to find it.

### Next Steps

### Frequently asked

**How do I create a user in RUAL?**

In RUAL Studio, open the Users section under cluster settings and use Create User. You set the account details and then assign the permissions or user group that fits the person's role.

**How do I reset a user's access in RUAL?**

The users table has a Reset action per row, next to Activity and Delete. Use Activity to see what that account has been doing before you change or remove access.