Developer Pages

# Managing roles and permissions

We offer IAM (Identity and Access Management) control to allow you to manage user accounts by assigning roles. You can administer who has access to the Signicat Dashboard and what permissions they have. This is relevant to you if you are the Dashboard administrator.

Page contents

# About roles and permissions

Roles are sets of permissions that you can assign to users or machine clients (we call these principals).

Permissions allow principals to perform specific actions on Signicat resources, such as the ability to access an API or to invite other users. To make permissions available to principals, you grant roles to the principals.

We divide roles into the following basic types:

  • Viewer
  • Writer
  • Editor

A role contains one or more permissions, which offer a granular way of specifying rights. There can be multiple roles with the same permissions.

Organisation and Account Admin

An Organisation Admin has all the permissions for the organisation, and all the accounts belonging to that organisation.

An Account Admin has all the permissions for a given account but not for the overlying organisation.

Some roles apply for a particular product or service, whereas the Organisation Admin role has access to all products on Signicat's platform.

# Grant access

The ability to access and manage resources is granted by assigning specific roles to principals, including users and machine clients, in your organisation.

You can assign or remove roles to an existing principal (user or machine client) in the Signicat Dashboard.

To grant access to a principal:

  1. Log in to the Signicat Dashboard (opens new window).
  2. Browse to IAM > Permissions (opens new window) and select Grant access.
  3. In the "Grant access" form, configure:
    Attribute Description
    Scope Required. The organisation or account that the changes apply to.
    Principals Required. The user, domain or machine client for which you want to change access rights.
    Roles Required. Browse available roles in the "Recommended", "By category" or "All available" tabs. Select at least one role.
  4. Click Save to apply the changes.

Note

Users must log in again to view and use a new role.

# Which roles to assign

You control users access to resources with roles. In the following table, you can find some recommendations for common scenarios.

User type Role Details
Business owner Organisation Admin Access to create/update/delete accounts and configurations. Can invite/edit/delete users on the Organisation and child accounts. Gives billing rights to purchase products on Signicat Marketplace.
Technical owner Organisation Admin Same rights as Business owner.
Financial owner Usage Viewer Access to view usage and invoices.
Developer/Technical consultant Account Admin Access to update account and account configurations. Allowed to invite users and remove users not inherited from parent Organisation.

# Usage guidelines

In the Dashboard (opens new window), you can sort and filter roles, for example by product or service.

To view, sort and filter roles:

  1. Log in to the Signicat Dashboard (opens new window).
  2. Go to IAM > Roles (opens new window). You can then filter the list, search for roles and view details and descriptions for individual roles.

# Remove access

To remove access for a principal:

  1. Log in to the Signicat Dashboard (opens new window).
  2. Browse to IAM > Permissions (opens new window).
  3. Hover over the row of the principal you want to remove access for and click Edit.
  4. In the "Edit access" overview, click Remove access. On the confirmation dialog, approve the changes to remove all the roles assigned to the principal.

# Advanced information

# Roles hierarchy

Assigning a role to a user for a specific account or organisation impacts the way a user can access resources at the account or organisation level.

Imagine you have configured the following in the Dashboard:

Example configuration

  • Organisation 1
    • Account A
    • Account B
  • Organisation 2
    • Account C

Scenario 1
If a user is assigned role X on Organisation 1, they will also receive the same role for any sub-level, such as Account A and Account B. The user will not receive any role on Organisation 2 or Account C.

Scenario 2
If a user is assigned role X on Account A, they will not receive the same role for Organisation 1 and Account B.

Granting access at the account level limits user access to the resources of the account.

# Naming conventions

We have established naming conventions for our basic roles. Our naming conventions cover about 90% of possible roles and allow you to create only the access your users need.

The following naming conventions apply:

  • <something> Viewer (GET) (Exceptions are secrets and auditlog)
    • Permissions for read-only actions that do not affect state, such as viewing (but not modifying) existing resources or data.
  • <something> Writer (POST)
    • Permissions for write-only actions, but not read or update. An example for this is in Digital Evidence Management (DEM), where a service can create DEM records but not update, delete or read them.
  • <something> Editor (PUT/CREATE/DELETE).
    • All viewer permissions, plus permissions for actions that modify state, such as changing existing resources.
  • <something> Admin (Editor + invite users).
    • All editor permissions, plus permission to invite, remove and grant access to users.
Last updated: 11/04/2024 07:47 UTC

← Managing users →