Safewhere Identify 5.14 Release Notes

New features and improvements

Fine-grained authorization

For simplicity reasons, the new Identify Admin portal originally had only three simple roles: Administrator, Observer, and User. However, with the retirement of the old Admin UI, our customers have increasingly adopted the new Admin interface. As a result, there has been a growing demand for a more fine-grained authorization system to effectively manage user privileges. In response to this, we have introduced several new roles. Some of the most significant ones are:

  • ConfigurationContributor: This role has the ability to view and modify all resources except for Users.
  • ConfigurationObserver: This role can view all resources but does not have permission to modify them. Additionally, it does not have access to view user data.
  • UserContributor: This role has the ability to view and modify user information exclusively, without access to any other resources.

A user can have multiple roles assigned.

Implementation of the new role requires the following changes:

  • Delete the "urn:anyid:role" role claim. The role claim was used to differentiate access to the old and new Admin UI. With the retirement of the old Admin UI, the claim is no longer necessary. If you are creating users using the REST API and assigning this role to them, you need to update your code to exclude the claim. Similarly, any claims transformations issuing this role should be updated.
  • Update the "urn:identify:rest-api:role" role from a single-value discrete claim to a multiple-value claim.
  • Add many predefined role options to the "urn:identify:rest-api:role" role claim.

All the aforementioned changes are made using SQL change scripts. Please note that existing access and refresh tokens will still work after the upgrade.

The functionalities that a user can access in the Admin UI depend on the roles assigned to them. Additionally, if a user has roles that do not grant permission to view or edit their own profile, they will be redirected to the System Information page.

You can refer to Identify Admin's authorization to learn about all the new roles.

Impacted code

This feature requires code changes of the following modules:

  • REST API: Authorization code
  • Configurator: Handling of the role claims.
  • Identify Admin portal: Multiple pages where the new authorization system is applied
  • No code changes related to the Runtime module.

Identify Admin and load-balancing

Previously, the Identify Admin used ephemeral in-memory data protection keys to secure its cookies. When Identify is deployed in a redundant setup, this in-memory mode requires sticky sessions to function properly. Consequently, deployments that do not use sticky sessions and rely on SQL Session state experienced invalidated sessions when users logged in with one server but were routed to another server afterwards.

We have addressed this issue by switching from ephemeral in-memory data protection keys to storing keys in the Identify database. This change has resulted in several important updates.

Firstly, the Identify Admin now needs to read the keys from the Identify database, requiring connection strings to be configured in its appsettings.json file. For security purposes, we encrypt those connection strings using the servers' machine keys, similar to how connection strings of the Runtime application are encrypted.

Secondly, the Identify Admin utilizes Asp.Net Core's OIDC middleware, which previously operated in the in-memory SessionStore mode. In this mode, the Identify Admin only transmitted the session ID through the .AspNetCore.Session cookie key of the authentication session to the client-side. However, this approach only functioned effectively with sticky sessions since the key was used to retrieve the complete cookie data from the servers' memory. To address this limitation, we have reconfigured the system to transmit the entire content of the .AspNetCore.Session cookie to the client-side.

Before the change: AspNetCore-old.png

After the change: AspNetCore-new.png

The second change above has significant implications that led to the third change. While a session ID is just a short string, the entire content of the .AspNetCore.Session cookie is large, resulting in increased size for all Identify's cookies.

When logging in to the Identify Admin using a Username & password connection, the following cookies are sent to the Identify Admin:

identifyadmin-allcookies-before.png

As you can see, all cookies of the Identify Runtime are sent to the Identify Admin because their paths are set to the root (/) path. When the total size of these cookies exceeds a limit, users may encounter the "HTTP Error 400. The size of the request headers is too long" error.

To mitigate the potential issue above, we have updated Identify Runtime to move all its large cookies to the /runtime path. The cookies that have had their paths changed are:

  1. AuthenticationConnectionId
  2. identify_auth
  3. participants[...]
  4. OPBS_[...]
  5. _RequestVerificationToken[...]
  6. RememberChoiceTemp

cookie-new-path.png

One issue remains: for the cookies that were changed to the new path, if a browser already has those cookies set before the upgrade, there will be two cookies with the same keys. Therefore, Identify Runtime has a new guard that checks if more than one cookie with those keys is submitted, and it deletes the ones at the root path.

Impacted code

This feature requires code changes of the following modules:

  • REST API: No changes
  • Configurator: Deploy encrypted connection strings for Identify Admin.
  • Identify Admin portal: Changes in how cookies are stored and protected.
  • Identify Runtime: Changes to the path of many cookies and cleanup of old cookies.

Breaking changes

The new authorization implementation removed the "urn:anyid:role" role claim. If you are creating users using the REST API and assigning this role to them, you need to update your code to exclude the claim. Similarly, any claims transformations issuing this role should be updated.

All other changes should not be breaking changes, unless you have custom code or network setup that relies on the fact that all Identify Runtime's cookies used to be set to the root path. Regardless, those are important changes and should be tested carefully before deploying to production.