Access control

Introduction

Kamea integrates an ABAC (Attribute Based Access Control) structure to manage access rights.

This document will walk you through the platform's main authorization concepts, with some examples along the way.

Tenants

Overview

You can find the definition of a Tenant in the concepts details.

Tenants are nested. This means that each Tenant can have child Tenants, that will have their own set of Users, Devices, Folders and so on. These parent-child relationships on Tenants will be useful for managing access rights, which we will explain in this documentation.

Examples

Example 1

We suppose that Company A wants to organize the monitoring in two of its sectors: the shipment of their product, and the equipment they have on their sites.

This company could divide up their Tenants in this way:

Company A can separate and monitor its activity into the two sectors. But the Logistics and the Equipment department do not need to interfere with it other, and the two sites don't either. The Equipment Tenant can manage the equipment on both of the sites.

Example 2

Company B could be selling their IoT product to various client companies. These client companies could be competitors of each other, so data privacy is absolutely necessary.

Company B could have insights on the client Tenants and manage their own Tenant if needed. However, each client Tenant does not even know the other clients exist.

Data segregation

The way you organize your Tenants completely depends on your needs, and how you want to organize the data inside them.

As a general rule: data goes up the Tenant tree, access rights go down.

This means that in the example of Company A, someone who can access the Production Tenant can see the Tenants of both sites 1 and 2. However, that does not give this person access to the parent Tenant Company A.

Users

Overview

You can find the definition of a User in the platform concepts.

Each User is registered in at least one Tenant, and could be registered in any number of Tenants.

The User will have one unique personal account to login and visit the various Tenants it has access to.

Example

In the following example, User U1 is registered in the root of the Tenant tree. User U1 will be listed in the Users of Company B, but not as a User of any client.

However, User U2 can only access the Tenants of client 1 and client 2. It will be listed in the Users of the client Tenants 1 and 2, but not as a User of Company B, nor of client 3.

User Groups

Overview

You can find the definition of a User Group in the platform concepts.

Each User Group is registered on one Tenant. A User Group may contain any User that is registered on the same Tenant. Users can be added to any number of User Groups.

Example

In the following example, the Reporters User Group on the Logistics Tenant includes both Users U3 and U4. The Technicians User Group on the first Equipment site only includes User U3.

This is possible if:

• the User U4 is registered at least in the Logistics Tenant
• the User U3 is registered at least in Tenants Logistics and Site 1.

Roles and Permissions

Overview

Users inherit their access rights from the User Groups they belong to.

The heart of this mechanism lies in the Role Assignments.

Each User Group has some assigned Roles, which will determine what its Users can do.

Roles

You can find the definition of Roles and Permissions in the platform concepts.

We define Roles as a list having the elements:

-> Permission       Entity Type

So we could define a Role like this one:

Name: Device Operator

-> Read            Folders
-> Update          Folders

-> Read            Devices
-> Edit metadata   Devices
-> Create          Devices
-> Update          Devices
-> Delete          Devices

For example, someone who has the Device Operator Role will be able to update Devices.

Role Assignments

Overview

A User Group gets Roles assigned to enable its Users to perform the actions of their Roles.

A Role Assignment is assigned within a scope. The scope determines exactly on which entity the Role can be performed.

The scope will either be a Tenant or a Folder.

Example

In this example, User U5 belongs to the Mechanics User Group on the Equipment Tenant.

This Mechanics User Group has two Role Assignments:

1. Folder Contributor Role on the Equipment Tenant

This Role can be used on the whole Tenant, including the child Tenants such as Site 1. If this Role allows to create Folders, the User can create Folders on both the Equipment and the Site 1 Folder.

1. Device Operator Role on Folder B of the Equipment Tenants

This Role is assigned in the scope of one Folder only. If this Role allows to create Devices, the User can create devices only in Folder B, but not anywhere else.

Scopes

Currently, Roles can only be assigned with two types of scopes: Tenants and Folders.

As said in the Tenants section, access rights go down.

This means that any Role assigned on a Tenant scope will also be valid for its child Tenants, but not on the parent Tenants.

The same happens for Folders: a Role assigned on a Folder scope will also be valid for all the other Folders inside the Folder, but not on parents or siblings.

Customization

Currently, all Roles and Permissions are built into the platform.

Users themselves are however able to create User Groups and Role Assignments as long as they have the access rights to do so.

In the future, the platform should support creating custom Roles and Permissions.