Access Management

Introduction

Access management in SaaS applications involves regulating who can access the application and what actions they are allowed to perform. This is accomplished through roles and permissions, which bestow varying levels of access to different users.

With ROQ's access management, you can:

• Define user roles such as admin, member, customer, and more.
• Establish roles and assign them to your users.
• Utilize these permissions to determine if a user is permitted to view specific content (e.g., buttons, pages) or execute a particular action (e.g., create an entity).
• Set permissions and apply them on the application.
• Filter data displayed within the application.

The Big Picture

The entire system works in a coordinated manner to ensure seamless access management. Here's how all the components fit together:

In the ROQ Console, users configure roles and permissions. These are integral in defining user access rights and restrictions within the application.

Simultaneously, every database query within the project is supplemented with conditions derived from the user's roles and permissions. This means that each user's interaction with the database is customized based on their specific access rights, thereby ensuring a secure and controlled data environment.

To streamline the process and minimize manual intervention, the AI Assistant provides an auto-configuration feature. This advanced functionality allows for an automatic setup of roles and permissions based on predefined templates, significantly reducing the time and effort required in the initial configuration.

In essence, ROQ's access management combines the power of user-configured roles and permissions with an AI-driven automatic setup to deliver a robust, flexible, and efficient access management system.

How It Works

Roles and permissions are defined in the ROQ Console (opens in a new tab). Generally, permissions grant access to objects, e.g., a customer is allowed to make an order. You can specify the operation (read, create, update, and delete) and set the scope. The scope determines if a user has access to either all records, only the own records, or to records related to the own account (~ tenant). These permissions are automatically enforced on all UI Components and APIs of ROQ and can also be applied to the project's user interface and queries.

Technically, the access management works based on a query plan which ROQ computes based on the current user's permissions and your database tables. The SDK is caching this information locally and only refreshes it periodically. This way, your application is independent of the availability of the ROQ Platform. Furthermore, there is no need to send all your data. ROQ only needs to know the schema of your database; the actual queries will be performed on your side.

Filter Down Data of A Query

When you retrieve data from your database, you'll often need to filter it by the user's role. For example, let’s say you have a REST endpoint called /rented-cars which returns a list of rented cars. Depending on the user's role, the result will be different: an admin will see all the rented cars, while a customer will see only their rented cars. This can result in complicated WHERE conditions, especially if you have more than these two simple roles.

Roles, Permissions, and Scopes

Roles

Roles are assigned directly to users. You can easily read them in sentences like this:

• User Mary is an admin
• User Jane is a chef
• User John is a driver
• User Richard is a customer

A role is represented by its name, such as owner, member, manager, chef, driver, or customer.

Permissions

Permissions determine the access level to a specific type of object. For instance, the role manager may be granted read access to the sales orders of a restaurant management application.

Permissions involve:

• The restricted entity (like sales_order),
• An operation (read, create, update, or delete),
• And a scope (all, own, or tenant).

Access Levels

To specify access levels for your application, select an object type (e.g., salesOrder). If the required object isn't available in the dropdown, it means it wasn't declared during the initial preparation.

For each object, you can set the following access levels:

Scope

Scope determine the range of access within permission. Scope the access levels are defined similarly.

Scopes: