Administration > Groups > Role Permissions

Raynet One Data Hub introduces three user roles and an anonymous access for shared items. Depending on the role of a user, the user has a restricted view or no access to certain pages and functionality.

The following table provides an overview of the view, write and delete permission per view for each role. The list is not comprehensive and shows only a selection of screens and features.

Roles	Login	Tasks			Library Items
Roles	View	View	Write	Delete	View	Write	Delete	Import	Export
Admin	+	+	+	+	+	+	+	+	+
Data Admin	+	+	+	+	+	+	+	+	+
User	+	-	-	-	(Conditional)	(Conditional)	(Conditional)	-	-
Anonymous	+	-	-	-	(Shared public link)	-	-	-	-

Agents

Agent

Users

Groups

Settings

View

Write

Delete

View

Write

Delete

View

Write

Delete

View

Write

Delete

View

Granular API Access and Token Security

API keys provide a secure and flexible way to manage access to specific data sets, ensuring precise control over data retrieval. Through the admin interface, administrators can configure API key permissions with fine-grained access control,

restricting data access at both the table and row levels, as shown in the image below. This ensures that users only view relevant data based on predefined scopes, limiting access to authorized information.

Each API key must be configured with an explicit list of allowed tables to limit data access to specific sets.

For broader access, wildcards (*) can be used as a placeholder to grant access to all tables. The use of wildcards (*) should be applied cautiously to avoid unintended data exposure.

If no tables are specified for an API key, the default behavior permits access to all tables. Further details on configuring API keys and managing access rules are provided in the sections below.

Add API Key

To add an API key, navigate to Profile in the top right corner, select Profile, provide a name for the API key, choose a tenant, and then proceed to configure Permissions. Access restrictions for an API key can be configured in multiple ways, such as Table-Level Access Restrictions, Row-Level Access Restrictions, and Request-Level Filtering, with further details provided in the sections below.

Table-Level Access Restrictions:

API keys can be configured to restrict access to specific tables. For example:

•Specific tables: Catalog_v2-Software, Catalog_v2-SoftwareManufacturer

•Wildcards: Catalog_* (includes all tables starting with Catalog_, e.g., Catalog_v2-Software, Catalog_v2-SoftwareManufacturer), *(includes all tables in the system)

Row-Level Access Restrictions:

API keys can be configured with the following row filter for specific tables. For example:

•Specific Table: Catalog_v2-SoftwareManufacturer

•Row Filter: [["Name", "notcontains", "C"], "and", ["ManufacturerId", "<>", "213BA2D4-77FD-4519-9006-00B769C73E05"]]

With this configuration the API key will only return rows from the Catalog_v2-SoftwareManufacturer table that match the specified row filter conditions when accessing the specified table through resultDatabase endpoints, ensuring precise and secure data retrieval.

Request-Level Filtering:

Additional filters can be applied directly in API requests using the filter query parameter like in this image.

Combined Filtering Logic:

When configuring API key access for ResultDatabase endpoints, both row filters and request-level filters can be applied together, combining their restrictions using AND logic to ensure precise and secure data access, with further details provided below.

Complex rules can be established to combine table-level and row-level restrictions, ensuring tailored data access while preventing injection risks. For each table, a set of operators can be used to configure granular access rules, restricting data exposure to authorized sets. Available operators are detailed below:

Category	Operations
Equality checks (for numbers, strings, dates)	=, >=, >, <=, <, <>
String operators	Contains, StartsWith, EndsWith
Nullability checks	IsNull, IsNotNull
Boolean operations	And, Or

Each API key should be configured to ensure that requests targeting tables not in the allowed list are denied, returning a descriptive error message to maintain secure and predictable behavior.

API Endpoints for Secure Data Access

The following API endpoints enable secure and controlled access to data by providing specific tables or rows based on defined permissions.

Endpoint:	/v1/ResultDatabase/resultTable/paged
Description:	Get a paged table result in a format as requested in the accept header.
Documentation:	N/A

Endpoint:	/v1/ResultDatabase/table
Description:	To retrieve a list of table names available in the system, use the specified API endpoint.
Documentation:	N/A

Endpoint:	/v1/ResultDatabase/table/{tableName}
Description:	To export a complete table result as a CSV file without pagination, configure the API request with the appropriate settings.
Documentation:	N/A

Endpoint:	/v1/ResultDatabase/table/{tableName}/paged
Description:	To export the entire table result as a CSV file without pagination, set up the API request with the appropriate configuration.
Documentation:	N/A

Endpoint:	/v1/ResultDatabase/resultTable
Description:	To retrieve the complete table result in CSV format without pagination, configure the API request accordingly.
Documentation:	N/A

Data API Filtering Options

The tabular data endpoint includes a new filter parameter, enabling precise queries to retrieve only the specific data subsets required.

The image shows an example query to retrieve all software manufacturers with Micro in their names, excluding those with Service.

The following operators are available for defining data access rules in access control configurations:

Operator	Sample
= (equals)	["OrderDate", "=", "2023-01-06"]
> (greater than), >= (greater or equal)	["OrderDate", ">=", "2023-01-06"]
< (less than), <= (less or equal)	["OrderDate", "<", "2023-01-06"]
<> (not equal)	["OrderDate", "<>", "2023-01-06"]
Contains	["Name", "contains", "Microso"]
NotContains	["Name", "notcontains", "Microso"]
StartsWith	["Name", "startswith", "Micro"]
EndsWith	["Name", "endswith", "Corporation"]
IsNull	["EndOfLife", "isnull"]
IsNotNull	["EndOfLife", "isnotnull"]
And	[<condition1>, "and", <condition2>]
Or	[<condition1>, "or", <condition2>]

This feature allows accurate server-side filtering, following the access rules set for each API token. It lets users securely query only the needed data without exposing unauthorized information. It also works smoothly with other features, like pagination, for better usability.