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.

Access Token: 2.5.0

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.

IMSG: 17.8.3

2022-09-09

• Upgrade internal dependencies

IMSG: 17.8.2

2022-06-28

• Upgrade internal dependencies

Access Token: 2.4.2

2022-06-28

• Upgrade internal dependencies

IMSG: 17.8.1

2022-06-22

• Upgrade internal dependencies

Access Token: 2.4.1

2022-06-22

• Upgrade internal dependencies

Access Token: 2.4.0

2022-06-16

• Wildcard unit scope puts permissions into units if not allowed in org

Consider the following permissions:

{
  org: []
  units: {
    unit1: [
      writer:access
      dashboard:access
    ],
    unit2: [
      writer:access
    ],
    unit3: [
      dashboard:access
    ]
  }
}

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:

{
  org: []
  units: {
    unit1: [
      writer:access
    ],
    unit2: [
      writer:access
    ],
    unit3: []
  }
}

Access Token: 2.3.0

2022-04-28

• Cache private keys to avoid exceeding SSM limit

IMSG: 17.8.0

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.

IMSG: 17.7.1

2022-03-28

• Internal maintenance

IMSG: 17.7.0

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.

IMSG: 17.6.1

2021-05-07

• Internal maintenance release. No changes to service.

IMSG: 17.6.0

2021-05-07

• Upgrade of Node from 10 to 14.

• Upgrade of dependencies

Access Token: 1.4.0

2021-03-01

• Access tokens obtained through client credentials are now counted as internal access in the billing API

IMSG: 17.5.1

2021-02-04

• Bugfix: validate IMSG service callback against correct cookie domain when using full URL in service callback

IMSG: 17.5.0

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.

IMSG: 17.4.0

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.

IMSG: 17.3.0

2020-12-17

Legacy mode feature flag for units

IMSG now supports a legacy mode where only units with explicit permission mappings are included in the service token. This is required for the current version of the unit-selector (in writer and dashboard) to function properly. To enable legacy mode, set the "short-and-to-the-point" env variable LEGACY_MODE_ONLY_INCLUDE_UNITS_WITH_EXPLICITLY_MAPPED_PERMISSIONS_IN_SERVICE_TOKEN to true.

Security fix

The redirect option in the /callback endpoint now only accepts full URLs if the URL is hosted under the cookie domain env variable (infomaker.io or navigacloud.com)

Preparations for improved refresh flow

IMSG now supports the rta (refresh token after) claim which soon will be included in all ID-tokens (browser cookie tokens). The rta claim is the future way to centrally control when refresh is to be performed. Refresh backoff support. In certain situations when an IMSG is unable to refresh a token after rta has passed, or if IMAS responds with a 429 status code during refresh, IMSG will backoff and not try to refresh the token for a given time period. The other parts of the new refresh flow is implemented in IMAS and will be deployed starting January 2021. The changes will be rolled out in three steps, as described below.

1. The ID-token's exp (expiry) claim will be increased to several days (from today's 1h). This means that as long as the user is logged in to Naviga ID, they will continue to be so even if their organization's IdProvider goes down. This would for example have minimized the impact of Google's outage the other day quite a bit.

2. Refresh of ID-tokens will be limited to once per token. This is the current expected behavior, so there won't be any impacts for users in all normal scenarios. However, in the event that an ID-token is stolen from a user, we can identify that if more than one refresh is triggered. In the initial roll out, the only action taken is to log and alarm. When we are confident we have no false-positives, we'll deploy step 3.

3. If a token is used for refresh more than once, we will invalidate all issued tokens for that user. This will lead to both the legitimate user and the intruder to be logged out from Naviga ID. The legitimate user will be able log in again while the intruder no longer has access.

Access Token: 1.3.0

2020-12-15

• Internal access tokens now have an ntt claim of internal_access_token

Access Token: 1.2.0

2020-10-12

• Cache client credentials

Admin App: 1.2.0

2020-10-12

• Make deploy environment configurable via environment variable

IMSG: 17.2.0

2020-09-11

• Pre-expire refresh of tokens. Tokens will now be refreshed around 10 minutes before they expire.

• New /v1/units endpoint to fetch all units a user belongs to. The response contains the unit display names.

IMSG 17.2.1 (2020-10-12)

• IMSG now handles userinfo from access tokens correctly, fixing a bug where service tokens would contain no userinfo

Admin App 1.1.0

2020-09-11

• Add missing config options for Azure LFE

  • useFullGroupsEndpoint

  • useTransitiveGroupMemberships

Admin API 19.2.0

2020-09-11

• Two new endpoints for import/export of organization units and group mappings. See Admin API docs for details.

  • GET /v1/organizations.export

  • POST /v1/organizations.import

Admin API 19.2.1 (2020-10-12)

• Fix bug where only admins could create credentials for organization applications

IMSG 17.1.0

2020-08-21

• All organization units are now included in the service token whether the user has any permissions in it or not. Units the user does not belong to will have no permissions in it.

IMSG 17.1.1 (2020-08-21)

• Dependency upgrades

IMSG 17.0.0

2020-05-07

• Remove old M2M support

IMSG 17.0.1 (2020-05-12)

• Dependency downgrades

SAL 5.6.0

2020-03-02

• No longer requires environment variables IM_LOG_LEVEL and IM_LOG_NAME.

• Log level will default to info and log name to Log name not set

IMSG 16.8.0

2020-03-02

• No longer counts internal users towards billable users

• Subjects with the first name Naviga will be tagged as internal access.

IMSG 16.7.0

2020-03-02

• New env variables ONLY_ACCEPT_ID_TOKENS, INCLUDE_GROUPS_IN_SERVICE_TOKEN

• New login url /v1/login with org and callback as query params

• Do not allow refresh when using access_token

• Include exp in service-token

• Add naviga_admin as second service admin org

Prerequisites

The party that wished to integrate with Naviga Login must have an identity provider compatible with the OpenID Connect 1.0 Core specification.

Specifically, the identity provider must support the OpenID Connect Authorization Code Flow.

Information for Infomaker

Information we need to integrate your OIDC application:

• URL to your OpenID provider metadata file (.well-known/openid-configuration)

• Client ID

• Client secret

Information for the integrating party

Allowed callback URLs

The following URLs must be added to the integrating party’s Whitelisted Callback URLs or equivalent:

• http://localhost:9091/v1/org/{orgName}/login-callback

• https://imas.imid.infomaker.io/v1/org/{orgName}/login-callback

• https://imas.stage.imid.infomaker.io/v1/org/{orgName}/login-callback

Allowed web origins

The following URLs must be added to the integrating party’s Allowed Web Origins or equivalent:

• http://localhost:9091

• https://imas.imid.infomaker.io

• https://imas.stage.imid.infomaker.io

Prerequisites

The following steps in this document requires that you have a working G Suite directory .

Generate a Client ID and Client Secret

1. Login to your Google account and go to the

2. Click on Select a project dropdown and choose that project you want to use or create a new one.

3. Click on Create credentials and select the OAuth client ID

4. Google show a banner saying "To create an OAuth client ID, you must first set a product name on the consent screen". Click on Configure consent screen

5. Type the Product Name that will be shown to the users when they log in through GSuite, add infomaker.io as an Authorised domain and click Save.

6. Now we will fill in information about the app. Start with selecting Web application and provide a name for your app.

8. Under Restrictions, fill in following information:

• Authorized JavaScript origins: https://imas.imid.infomaker.io, https://imas.stage.imid.infomaker.io

• Authorized redirect URI: https://imas.stage.imid.infomaker.io/v1/org/<OrganizationName>/login-callback, https://imas.imid.infomaker.io/v1/org/<OrganizationName>/login-callback

9. Click on Create and your Client ID and Client Secret will now be displayed.

Enable the API access

2. Check the Enable API access box.

3. Click save.

Enable Admin SDK

2. Search for Admin SDK

3. Click on Admin SDK and click on Enable

Create a Service Account for Fetching User Groups

If you want Naviga Login to be able to fetch groups for the logged in user, a service account is required.

The following scopes are required to fetch user groups: https://www.googleapis.com/auth/admin.directory.group.readonly

Access to the G Suite Admin SDK requires impersonating a user with access to the Directory API:

Note: Only users with access to the Admin APIs can access the Admin SDK Directory API, therefore your service account needs to impersonate one of those users to access the Admin SDK Directory API. Additionally, the user must have logged in at least once and accepted the G Suite Terms of Service.

Gather The Required Information and Speak With Your Naviga Contact

Prerequisites

The following steps in this document requires that you have a working Active Directory within Microsoft Azure. It can be a federation with a local Active Directory or your main Active Directory. Read more about how to Deploying Active Directory Federation Services in Azure

Setting up an Azure Active Directory app to work with Naviga Login

1. Login to and click on Azure Active Directory and the on App registrations (Preview)

2. Click on New registration

   • Name: <Your choice of name> Proposal: Naviga Login

   • Supported account types: Accounts in this organizational directory only (Standardkatalog)

   • Redirect URI (optional): Web /

3. Go to Authentication within your new created app and then following URLs under Redirect URIs as Web types (organization name will be provide to you by Infomaker/Newscycle):

   https://imas.stage.imid.infomaker.io/v1/org/<OrganizationName>/login-callback

   https://imas.imid.infomaker.io/v1/org/<OrganizationName>/login-callback

4. Go to API permissions and enable the following:

   • openid

   • email

   • offline_access

   • profile

1. Go to Certificates & secrets and add a new Client secret

   • Description: client_secret

   • Expires: Your choice. But remember that you need to provide Naviga with a new Client Secret before the expiry date runs out otherwise your users will not be able to login with Naviga ID after the expiry date.

3. Go to Manifest and replace the following items:

This will include user groups in tokens

This will include given name and last name in tokens

You are now done with configuration

Add permissions for Naviga ID to read group names

By default, Azure AD only provides group IDs in the token and in order for Naviga ID to fetch the names of those groups, additional configuration is required.

Under API permissions add the following delegated permission:

• GroupMember.Read.All

This allows Naviga ID to list groups, read basic group properties and read membership of all groups the signed-in user has access to.

Gather The Required Information and Speak With Your Naviga Contact

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 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.

‌‌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.

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.

Retaining subject IDs in Naviga ID

Moving to a new identity provider will, most of the time, involve a new subject ID for the user, resulting in a new subject ID in Naviga ID as well. To retain the users Naviga ID subject ID, the http://infomaker.io/originalSubject claim can be added to the organization token. This claim should consist of the subject ID the user had in the previous identity provider.

When encountering the http://infomaker.io/originalSubject claim, Naviga ID will replace the previous subject ID stored internally with the subject ID found in the sub claim.

/roles.get

GET https://admin-api.imid.infomaker.io/v1/roles.get

Get role by id

Query Parameters

/roles.list

GET https://admin-api.imid.infomaker.io/v1/roles.list

List roles

Path Parameters

/roles.listMappedGroups

GET https://admin-api.imid.infomaker.io/v1/roles.listMappedGroups

List all mapped groups by role id

Query Parameters

/roles.assignToGroup

POST https://admin-api.imid.infomaker.io/v1/roles.assignToGroup

Add group to role mapping

Request Body

/roles.create

POST https://admin-api.imid.infomaker.io/v1/roles.create

Create role

Request Body

/roles.delete

POST https://admin-api.imid.infomaker.io/v1/roles.delete

Delete role by id

Request Body

/roles.mapPermission

POST https://admin-api.imid.infomaker.io/v1/roles.mapPermission

Map permissision to role

Request Body

/roles.setDescription

POST https://admin-api.imid.infomaker.io/v1/roles.setDescription

Set role description by id

Request Body

/roles.setName

POST https://admin-api.imid.infomaker.io/v1/roles.setName

Set role name by id

Request Body

/roles.setParentRole

POST https://admin-api.imid.infomaker.io/v1/roles.setParentRole

Set role parent role by id

Request Body

/roles.unassignFromGroup

POST https://admin-api.imid.infomaker.io/v1/roles.unassignFromGroup

Delete group to role mapping

Request Body

/roles.unmapPermission

POST https://admin-api.imid.infomaker.io/v1/roles.unmapPermission

Unmap permission from role

Request Body

/health

GET https://admin-api.imid.infomaker.io/v1/health

Health

Path Parameters

/organizations.export

GET https://admin-api.imid.infomaker.io/v1/organizations.export

Get organization by id

Query Parameters

{}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.get

GET https://admin-api.imid.infomaker.io/v1/organizations.get

Get organization by id

Query Parameters

{
  "id": "Organization id",
  "name": "infomaker",
  "displayName": "Infomaker Scandinavia AB",
  "wellKnownConfigUrl": "http://example.com/.well-known.json",
  "scope": "openid profile email",
  "clientId": "foobarbaz",
  "responseMode": "query",
  "groupsClaim": "Groups",
  "whitelistCallbackUrls": "[\"infomaker.io\", \"infomaker-test.io\"]",
  "sanitizedClientSecret": "null",
  "forceLoginPrompt": false,
  "useUserinfoEndpoint": false,
  "blocked": false,
  "updatedBySub": "infomaker_b8b9373b-a30d-459d-a44d-f270afb5e581"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.list

GET https://admin-api.imid.infomaker.io/v1/organizations.list

List organizations

Path Parameters

[
  {
    "id": "Organization id",
    "name": "infomaker",
    "displayName": "Infomaker Scandinavia AB",
    "wellKnownConfigUrl": "http://example.com/.well-known.json",
    "scope": "openid profile email",
    "clientId": "foobarbaz",
    "responseMode": "query",
    "groupsClaim": "Groups",
    "whitelistCallbackUrls": "[\"infomaker.io\", \"infomaker-test.io\"]",
    "sanitizedClientSecret": "null",
    "forceLoginPrompt": false,
    "useUserinfoEndpoint": false,
    "blocked": false,
    "updatedBySub": "infomaker_b8b9373b-a30d-459d-a44d-f270afb5e581"
  }
]

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.listGroupToRoleMappings

GET https://admin-api.imid.infomaker.io/v1/organizations.listGroupToRoleMappings

List group to service role mappings by organization id

Query Parameters

[
  {
    "roleId": "Role id",
    "unitId": "Unit id",
    "organizationId": "Organization id",
    "group": "Auth team"
  }
]

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.block

POST https://admin-api.imid.infomaker.io/v1/organizations.block

Block organization by id

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.create

POST https://admin-api.imid.infomaker.io/v1/organizations.create

Create organization

Request Body

{
  "id": "Organization id",
  "name": "infomaker",
  "displayName": "Infomaker Scandinavia AB",
  "wellKnownConfigUrl": "http://example.com/.well-known.json",
  "scope": "openid profile email",
  "clientId": "foobarbaz",
  "responseMode": "query",
  "groupsClaim": "Groups",
  "whitelistCallbackUrls": "[\"infomaker.io\", \"infomaker-test.io\"]",
  "sanitizedClientSecret": "null",
  "forceLoginPrompt": false,
  "useUserinfoEndpoint": false,
  "blocked": false,
  "updatedBySub": "infomaker_b8b9373b-a30d-459d-a44d-f270afb5e581"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.delete

POST https://admin-api.imid.infomaker.io/v1/organizations.delete

Delete organization by id

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.import

POST https://admin-api.imid.infomaker.io/v1/organizations.import

Get organization by id

Request Body

{}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.logout

POST https://admin-api.imid.infomaker.io/v1/organizations.logout

Logout organization by id

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setClientId

POST https://admin-api.imid.infomaker.io/v1/organizations.setClientId

Set organization clientId

Request Body

{
  "clientId": "foobarbaz"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setClientSecret

POST https://admin-api.imid.infomaker.io/v1/organizations.setClientSecret

Update org client secret

Request Body

{
  "sanitizedClientSecret": "foobarbaz"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setDisplayName

POST https://admin-api.imid.infomaker.io/v1/organizations.setDisplayName

Set organization display name

Request Body

{
  "name": "Infomaker Scandinavia AB"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setForceLoginPrompt

POST https://admin-api.imid.infomaker.io/v1/organizations.setForceLoginPrompt

Set organization forceLoginPrompt

Request Body

{
  "forceLoginPrompt": false
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setGroupsClaim

POST https://admin-api.imid.infomaker.io/v1/organizations.setGroupsClaim

Set organization groupsClaim

Request Body

{
  "groupsClaim": "Groups"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setName

POST https://admin-api.imid.infomaker.io/v1/organizations.setName

Set organization name

Request Body

{
  "name": "infomaker"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setResponseMode

POST https://admin-api.imid.infomaker.io/v1/organizations.setResponseMode

Set organization responseMode

Request Body

{
  "responseMode": "query"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setScope

POST https://admin-api.imid.infomaker.io/v1/organizations.setScope

Set organization scope

Request Body

{
  "scope": "openid profile email"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setUseUserinfoEndpoint

POST https://admin-api.imid.infomaker.io/v1/organizations.setUseUserinfoEndpoint

Set organization useUserinfoEndpoint

Request Body

{
  "useUserinfoEndpoint": false
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setWellKnownConfigUrl

POST https://admin-api.imid.infomaker.io/v1/organizations.setWellKnownConfigUrl

Set organization wellKnownConfigUrl

Request Body

{
  "wellKnownConfigUrl": "http://example.com/.well-known.json"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.setWhitelistCallbackUrls

POST https://admin-api.imid.infomaker.io/v1/organizations.setWhitelistCallbackUrls

Set organization whitelistCallbackUrls

Request Body

{
  "whitelistCallbackUrls": "[\"infomaker.io\", \"infomaker-test.io\"]"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizations.unblock

POST https://admin-api.imid.infomaker.io/v1/organizations.unblock

Unblock organization by id

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/units.get

GET https://admin-api.imid.infomaker.io/v1/units.get

Get unit by id

Query Parameters

{
  "id": "Unit id",
  "organizationId": "Organization id",
  "name": "barometern",
  "displayName": "Barometern OT",
  "description": "Description of speicific part xxx",
  "updatedBySub": "infomaker_b8b9373b-a30d-459d-a44d-f270afb5e581"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/units.list

GET https://admin-api.imid.infomaker.io/v1/units.list

List units

Query Parameters

[
  {
    "id": "Unit id",
    "organizationId": "Organization id",
    "name": "barometern",
    "displayName": "Barometern OT",
    "description": "Description of speicific part xxx",
    "updatedBySub": "infomaker_b8b9373b-a30d-459d-a44d-f270afb5e581"
  }
]

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/units.create

POST https://admin-api.imid.infomaker.io/v1/units.create

Create unit

Request Body

{
  "id": "Unit id",
  "organizationId": "Organization id",
  "name": "barometern",
  "displayName": "Barometern OT",
  "description": "Description of speicific part xxx",
  "updatedBySub": "infomaker_b8b9373b-a30d-459d-a44d-f270afb5e581"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/units.delete

POST https://admin-api.imid.infomaker.io/v1/units.delete

Delete unit by id

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/units.setDescription

POST https://admin-api.imid.infomaker.io/v1/units.setDescription

Set unit description by id

Request Body

{
  "description": "Description of speicific part xxx"
}

"errors.api.BHadRequestError"

"errors.api.InternalServerError"

/units.setDisplayName

POST https://admin-api.imid.infomaker.io/v1/units.setDisplayName

Set unit display name by id

Request Body

{
  "displayName": "Barometern OT"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/units.setName

POST https://admin-api.imid.infomaker.io/v1/units.setName

Set unit name by id

Request Body

{
  "name": "barometern"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

Headers added by IMSG

/organizationApplications.get

GET https://admin-api.imid.infomaker.io/v1/organizationApplications.get

Get organization application

Query Parameters

{
  "id": "Organization application ID",
  "organizationId": "Organization id",
  "name": "my-organization-application",
  "description": "Description of speicific part xxx"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizationApplications.list

GET https://admin-api.imid.infomaker.io/v1/organizationApplications.list

List organization applications

Path Parameters

[
  {
    "id": "Organization application ID",
    "organizationId": "Organization id",
    "name": "my-organization-application",
    "description": "Description of speicific part xxx"
  }
]

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizationApplications.create

POST https://admin-api.imid.infomaker.io/v1/organizationApplications.create

Create organization application

Request Body

{
  "id": "Organization application ID",
  "organizationId": "Organization id",
  "name": "my-organization-application",
  "description": "Description of speicific part xxx"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizationApplications.createCredential

POST https://admin-api.imid.infomaker.io/v1/organizationApplications.createCredential

Create organization application credentials

Request Body

{
  "id": "Organization application credential ID",
  "clientSecret": "xxxxxx",
  "sanitizedClientSecret": "x*****x"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizationApplications.delete

POST https://admin-api.imid.infomaker.io/v1/organizationApplications.delete

Delete organization application

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizationApplications.deleteCredential

POST https://admin-api.imid.infomaker.io/v1/organizationApplications.deleteCredential

Delete organization application credential

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/organizationApplications.modify

POST https://admin-api.imid.infomaker.io/v1/organizationApplications.modify

Modify organization application

Request Body

{
  "id": "Organization application ID",
  "organizationId": "Organization id",
  "name": "my-organization-application",
  "description": "Description of speicific part xxx"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.get

GET https://admin-api.imid.infomaker.io/v1/subjects.get

Get subject by id

Query Parameters

{
  "id": "Subject id",
  "organizationId": "Organization id",
  "organizationSubject": "user@infomaker.se",
  "blocked": false,
  "updatedBySub": "infomaker_b8b9373b-a30d-459d-a44d-f270afb5e581"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.list

GET https://admin-api.imid.infomaker.io/v1/subjects.list

List subjects by id

Path Parameters

[
  {
    "id": "Subject id",
    "organizationId": "Organization id",
    "organizationSubject": "user@infomaker.se",
    "blocked": false,
    "updatedBySub": "infomaker_b8b9373b-a30d-459d-a44d-f270afb5e581"
  }
]

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.me

GET https://admin-api.imid.infomaker.io/v1/subjects.me

View data of currently logged in subject

Path Parameters

{
  "org": "infomaker",
  "sub": "user@infomaker.se"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.block

POST https://admin-api.imid.infomaker.io/v1/subjects.block

Block subject

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.create

POST https://admin-api.imid.infomaker.io/v1/subjects.create

Create subject

Request Body

{
  "id": "Subject id",
  "organizationId": "Organization id",
  "organizationSubject": "user@infomaker.se",
  "blocked": false,
  "updatedBySub": "infomaker_b8b9373b-a30d-459d-a44d-f270afb5e581"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.delete

POST https://admin-api.imid.infomaker.io/v1/subjects.delete

Delete subject by id

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.login

POST https://admin-api.imid.infomaker.io/v1/subjects.login

Login subject

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.logout

POST https://admin-api.imid.infomaker.io/v1/subjects.logout

Logout subject

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.setOrganizationSubject

POST https://admin-api.imid.infomaker.io/v1/subjects.setOrganizationSubject

Set subject organization subject by id

Request Body

{
  "organizationSubject": "user@infomaker.se"
}

"errors.api.BadRequestError"

"errors.api.InternalServerError"

/subjects.unblock

POST https://admin-api.imid.infomaker.io/v1/subjects.unblock

Unblock subject

Request Body

""

"errors.api.BadRequestError"

"errors.api.InternalServerError"

Integration of an Identity Provider in Naviga ID using OpenID Connect requires some setup in the Identity Provider. Here you can find instructions for the most common providers and how to configure them to support Naviga ID.

HttpTestServer{#HttpTestServer}

HttpTestServer{#HttpTestServer}

Http server to help the systemtest visualize http calls.

new HttpTestServer(params)

start()

Start the http server.

Listening on specified port.

stop()

Stop the Http server.

Checks if there are any http calls left to respond to or endpoints waiting for calls, responds to these endpoints and then stops the server.

Throws errror if there are leftover calls not handled before shutdown.

getServerHost() {#getServerHost}⇒ string

Gets the server host.

Returns: string - networkInterfaceAddress - A string with the address for the eth0 network

waitForCall(endpoint, [params]) {#waitForCall}⇒ Promise.<Object>

Gets an endpoint to handle. Checks if an endpoint is waiting for an answer and resolves an answer to it.

Or puts the endpoint on a queue to be handled when a request for that endpoints comes in.

Returns: Promise.<Object> - Promise object represents the object with resolve, reject and params to resolve the incoming http call