Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Naviga ID (formerly IMID) is Naviga's SSO (Single Sign-on) authentication and authorization service for all content creation tools. Built on the industry standard of JSON Web Token, Naviga ID integrates with organization's existing identity provider using OpenID Connect. OpenID Connect ensures compatibility with all major identity providers such as Google, Facebook, Azure AD and many more.
Naviga ID also supports the OAuth2 standard Client Credentials which is used to obtain access tokens for machine-to-machine communication scenarios, such as import and export of material to and from Naviga's content services.
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.
Every user belongs to an organization, for example "the media group".
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.
A unit is defined by the publication that the user is part of, for example "South News" or "North News" within the organization.
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).
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.
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.
Below is a schematic sketch of the difference between groups and service roles.
2022-09-09
Add scopes to filter access token permissions
permission-filter-include-org
permission-filter-include-unit:{unitName}
See access token documentation for details.
2022-09-09
Upgrade internal dependencies
2022-06-28
Upgrade internal dependencies
2022-06-28
Upgrade internal dependencies
2022-06-22
Upgrade internal dependencies
2022-06-22
Upgrade internal dependencies
2022-06-16
Wildcard unit scope puts permissions into units if not allowed in org
Consider the following permissions:
Before this update, requesting a token with scope permission:*:writer:access
would result in an error since writer:access
is not present in the org permissions.
Now, requesting the same scope will result in the following permissions:
2022-04-28
Cache private keys to avoid exceeding SSM limit
2022-03-28
Default to less strict validation of cookie payload
Hapi, the web server framework used by IMSG, defaults to a strict validation of cookies according to rfc6265
(https://datatracker.ietf.org/doc/html/rfc6265). This includes not allowing raw JSON as the cookie value. With this change, a less strict validation of cookies will be the default behaviour.
This will solve issues caused by other services setting cookies on infomaker.io or navigacloud.com that do not adhere to rfc6265
. The less strict validation is the default behaviour of most other servers as well as all major browsers.
Environment variable changes
This can be overridden by setting env variable STRICT_COOKIE_MODE
to true.
2022-03-28
Internal maintenance
2022-03-28
For access tokens, use the permissions claim in the token instead of resolving permissions based on groups
There are two different kind of tokens in Naviga ID that can be used to access services behind an IMSG reverse proxy.
When you log in to CCT in the browser, an ID token (sometimes called session token) is stored as a cookie in your browser. This token does not hold any permissions. Instead, the groups that you belong to are stored in the token. When you access a CCT service, the IMSG will translate the groups into permissions (based on the current latest organization configuration). The permissions are then forwarded to the service.
The second type of token is access tokens. Access-tokens are fetched from the access token service using either an ID-token or client credentials. When an access token is created, it is populated with the resolved permissions from the start. Hence there’s no need for IMSG to try to resolve them again.
Up until this release, IMSG ignored any permission claim the access tokens and only used the list of groups to resolve the permissions. With this change in place, IMSG will always use the permissions claim in access tokens and forward those permissions to the service.
2021-05-07
Internal maintenance release. No changes to service.
2021-05-07
Upgrade of Node from 10 to 14.
Upgrade of dependencies
2021-03-01
Access tokens obtained through client credentials are now counted as internal access in the billing API
2021-02-04
Bugfix: validate IMSG service callback against correct cookie domain when using full URL in service callback
2021-01-29
Support for allowing any headers during CORS requests
IMSG can now allow any headers in CORS requests. Enabling this feature reflect the value of access-control-request-headers
into the response access-control-allow-headers
. Use with care.
Environment variable changes
CORS_ALLOW_ANY_HEADERS
has been added.
Set to true
to enable.
2021-01-20
Support for multiple domains
IMSG can now serve and set cookies on multiple domains. To enable multiple domains, set the IMID_COOKIE_DOMAINS
environment variable to the domains you want to access IMSG on.
ex. IMID_COOKIE_DOMAINS="infomaker.io, navigacloud.com"
Environment variable changes
IMID_COOKIE_DOMAIN
has changed name to IMID_COOKIE_DOMAINS
and changed type from sting
to CSV
. The legacy name will continue to be supported.
2020-12-17
Legacy mode feature flag for units