# 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](https://docs.navigaglobal.com/navigaid/access-token/using-access-tokens#filtering-access-token-permissions-using-scopes) 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` (). 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](http://infomaker.io/) or [navigacloud.com](http://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](http://infomaker.io/) or [navigacloud.com](http://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](https://docs.navigaglobal.com/navigaid/services/admin-api/routes/organizations) 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 �