Authorization schema

Introduction

Naviga ID has a role based authorization schema. Each role in Naviga ID corresponds to one or more permissions. Roles are set up by Naviga.

When a user logs into Naviga ID, the groups a user belongs to in the organization's identity provider are imported into Naviga ID.

Via Naviga ID's Admin service, organization administrators can configure the mappings between org groups and one or more service roles. Mappings can also include a unit, and will in that case limit the resolved permissions to only be applied to that unit. A unit can be viewed as a sub-organization within an organization. A mapping can also be created without including a unit, in that case the resulting permissions will be global for the organization, meaning they are valid in all units.

Organization

Every user belongs to an organization, for example "the media group".

The organisation "mediagroup"

The name of the organization is also part of your Dashboard domain name (for example https://mediagroup.dashboard.infomaker.io)‌

Use case Content Creation: Content access can be based, depending on your needs, to have everything open to the entire organization or be based on unites (see below). Some rights are also role based, such as publish flow possibilities (from Writer 6.0).

In some Dashboard applications, it is also possible to share specified content with the entire organization. This way it is possible to make concepts available to everyone, or only specific units. As a user creates or modifies content, that content is automatically labelled with the user organization.

Unit

A unit is defined by the publication that the user is part of, for example "South News" or "North News" within the organization.

The unit "South News"

‌‌Use case Content Creation: Content access is based on all the user units. For example in an application such as Dashboard Article Search, a user that belongs to two units will see articles from both these units (filtering using suggest search on channels or units possible with configuration).

Access control is unit wide which means that everyone within a unit can see the same content, and everyone with the right to edit content can edit all content within a unit.

A user can belong to one or many units, but only one unit can be "active" at the time. As a user creates content, that content is automatically "labelled" with the active unit. In our recommended setup, this will also make the content access right set to that unit. If a user modifies content, the object will contain this information but the access right will not be modified.

With some Dashboard applications it is also possible to share content with all or any of the units the user belongs to.

It is also good to know that all Dashboard configurations are made per unit (installed and available apps, specific app configuration, workspaces etc).

Group

A group is defined by the working task that people are working with in the organization, for example reporters, editors etc. Groups are configured in the organization's identity provider.

The group "editor"

Service Roles

Service Roles define the privileges for a specified service, for example what a Dashboard user can do. It could be power user, admin or read-only mode etc. Service Roles are global roles and defined by Naviga.

How roles are used is configured by your administrator: who can create, edit and delete concepts, who can create and edit lists, who can plan articles within the Publication Planner.

Use case Content Creation: In addition to defining privileges to specific functions, roles can also be used for setting workflow statuses (from Writer 6.0). This means that it is possible to allow internal journalists to publish without prior approval but contributors cannot publish directly for example. These workflow steps are fully customizable.

Service roles are not used for content access control.

The Service Role "dashboard:powerUser"

Below is a schematic sketch of the difference between groups and service roles.