Docs HomeInfomakerNaviga

Release notes

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

PreviousIntroductionNextAuthorization schema

Last updated