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. For a deeper look at how roles and permissions fit together. See User Roles Explained.

Users Overview

In the 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.

uam step 1

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.

1. Open RUAL Studio, select your cluster, and go to All users in the cluster settings section of the left-side menu.
2. Click Create user to open the create dialog.

uam step 2

3. 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 describes what a new user needs for their first login.
4. Save the user. The account is created immediately and appears in the All users list.
5. Open the new user from the list to fine-tune the account: enable permissions, set account settings, add custom scopes, or assign user groups.

uam step 3

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.

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:

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:

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

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.

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 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.

uam user actions

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 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.

Security Best Practices

• Least privilege: grant only the permissions a user needs for their role, preferably through 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 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.

uam activity

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 for where to find it.

Next Steps

Was this page helpful? Tell us what to improve · RUAL Docs is an integral component of the RUAL ecosystem