› › › › Safewhere Identify 5.9 Release Notes

Products

Safewhere Identify 5.9 Release Notes

May 20, 2024

Safewhere Identify 5.9 Release Notes

This document summarizes all new features and bug fixes for version 5.9 as well as breaking changes when being upgraded from previous versions.

New features and improvements

.NET framework and third party packages upgrade

In this release, we performed our annual upgrade cycle of .NET framework and third party packages to their latest versions. The more important upgrades are:

  • Microsoft packages: Microsoft.xxx and System.xxx, EntityFramework, MSTests
  • jQuery 3.5.0
  • MongoSharpDriver
  • OWIN 4.1.1: an important security patch
  • Safewhere Admin: upgrade to .NET framework 4.8 and .Net Core 3.1 which is a long-term support version

Identify Runtime

Support WHR parameter on authorization requests

We have added support for WHR parameter on the authorization request. You can refer to WHR parameter section for more details.

You can also include WHR parameter in a request object in an authorization request to Identify.

Claim transformation support on OAuth 2.0 client credential flow

You can now apply claim transformations to OAuth 2.0 applications that use the client credential flow. The returned access token contains the claims coming from the transformation. You can find a list of supported transformations and examples in our guideline.

OIOSAML 3.0 support

Safewhere Identify has full support for the new OIOSAML 3.0 profile and the NSIS 2.0 specification. This document shows you how to set your Identify instance up to fully comply with those profiles.

Generic OIDC Identity Provider support

The generic OIDC Identity Provider allows you to connect to any OIDC-compliant Identity Provider such as Azure AD. You can refer to our guideline to learn how to set up a generic OIDC Identity Provider.

When the JWS algorithm is None or RSASigning, the symmetric signing key is not required

The symmetric signing key is only used to sign JWT when the HMACSymmetric JWS algorithm is chosen, but is always required in earlier versions. From this version, when the JWS algorithm is None or RSASigning, the symmetric signing key is not required.

Better error message when relaystate is missing

Per the SAML specification, when Identify sends an AuthnRequest with a relaystate parameter to an upstream Identity Provider, the upstream Identity Provider is obliged to return it to Identify.
However, some Identity Providers do not implement the behavior correctly which causes an error in Identify.
We have improved error handling of Identify to report a better error message when this issue happens.
New error handling code only works when responses use X509Data KeyInfo though.

Rework SLO

Single sign-on (SSO) allows a user to sign on with one set of credentials and at once gain access to multiple Service Providers (SP). Given the user has logged in to multiple Service Providers using one or more Identity Providers (aka "participants"), when the user logs out of one participant, the expected behavior is that the user is also logged out of all other participants (SLO - Single Log Out). In order to do that, Identify must maintain a list of all SSO participants for the current logged-on session.

Previously, Identify stored the participant list in either cookies or in the SQL database and maintained other information in an ASP.Net session state. However, there are some limitations with that approach at SLO-time, and we have received many requests from our customers to improve the SLO experience. Therefore, we have redesigned the SLO module. You can read this post for more details.

Identify Configurator

Azure Key Vault support

Traditionally, Safewhere Identify stores its signing certificate in the Windows certificate store and has direct access to the private key.
In order to do cryptographic operations, Identify needs to read the private key into its memory.
Identify now can offer an option to store the signing certificate in Azure Key Vault.
The first advantage of using an HSM-backed certificate store (actually, a key store) is that Identify can no longer access the private key or read it into memory.
Another advantage is that auditing, access management, and key management are also much easier to do.

A small limitation in version 5.9 is that when you reconfigure an existing instance from Windows Certificate store to Azure Key Vault or when you reconfigure a certificate in Azure Key Vault to a new one, you need to add its public key to the Windows Certificate's LocalMachine\TrustedPeople store. We will fix this limitation in version 5.10.

As a side note, we will add support for Azure Managed HSM in version 1.0.

The Safewhere Admin portal is deployed by default

In version 5.9, we enforce deployment of the new Admin portal when you deploy a new Identify instance or upgrade from a previous version. This marks another important step on our roadmap to retire the old Admin portal. The Also deploy Safewhere Admin option has therefore now been removed from the Identify configurator.

Identify REST API

Text resources must be added to either built-in containers or the GlobalTextResources container

We have removed the ability to create containers with custom names. The rule is now much simpler:

  • If you want to add a new language for existing text resources, use the built-in containers.
  • If you want to override content of existing text resources, use the built-in containers.
  • If you want to add new text resources, use the GlobalTextResources container.

You can go to here to see the list of all built-in containers.

Safewhere Admin

User's password change triggers a PasswordUpdated event

Identify now raises a PasswordUpdated event when a user's password is changed by Safewhere Admin or REST API as follows:

  • When updating a user without changing the user's password, an Updated event is fired. This has been supported before.
  • When updating a user with changing the user's password, a PasswordUpdated event is raised in addition to an Updated event.
  • When updating a user's password only, a PasswordUpdated event is raised in addition to an Updated event.

Audit log viewers for user claims, claim definitions, and claim transformations

In version 5.9, you can view audit logs of user claims, claim definitions, and claim transformations using Safewhere Admin or REST API. On the Audit Logs tab, you can now view the following:

  • Audit User Claim: You can view detail of changes of a user's claims when a user is created or updated.
  • Audit Claim Definition: You can view the details of changes made to claim definitions that are created or updated.
  • Audit Claim Transformation: You can view the details of changes made to claim transformations when they are created or updated.

Other improvements

  • Claim page: When you create a new claim definition or update an existing one, you can now assign a variable name for that claim definition.
  • We have replaced the Show/Hide toggle button with +/- signs to collapse/expand its inner content. The feedback from our users is that the Show/Hide design, while looking good, has caused too much confusion.
  • We have removed the TokenValidationParameters parameter as well as its IssuerSigningKey parameter from the appsettings.json file because they are longer needed.
  • Identity Providers list: we have added support for the Generic Authentication Provider connectors.
  • Applications list: we have added support for Attribute Service connectors.

Bug fixes

  • Fixed: #72224 Improve certificate validation.
  • Fixed: #73340 [Identify configurator] SQL user's password is not replaced by * at step "Install Entity Framework Edmx action" on Identify log file.
  • Fixed: #73245 [Identify configurator] Identify log file contains dictation mistakes when creating or updating an Identify instance.
  • Fixed: #71159 [Identify configurator] The authentication connections using second factor authentication context method class configuration cannot be imported to an Identify instance.
  • Fixed: #72074 [Identify configurator] After you open the Identify Admin application on the new Admin interface and save it, the Configurator's Update new signing certificate reconfiguration functionality fails.
  • Fixed: #73525 [Identify configurator] Host of audit log on Identify instance which uses CosmosDB or MongoDB is overwritten by SQLServer information after enabling MultiSubnetFailover.
  • Fixed: #73162 [Identify configurator] Reconfigure - The Identify application pool is stopped right after doing: update another certificate and enable MultiSubnetFailover.
  • Fixed: #73155 [Identify configurator] NETWORK SERVICE is granted permission to the Safewhere Admin folder after upgrading an instance that in fact is using Window authentication.
  • Fixed: #73298 [Identify configurator] The multiSubnetFailover is set to False after upgrading, even though its current value is True.
  • Fixed: #70110 [Safewhere Admin] The text None displays at the display name field of the newly created LDAP attribute definition page.
  • Fixed: #69993 [Safewhere Admin] The description text on the Settings tab of the LDAP claim transformation uses the explanation of the Add Value claim transformation.
  • Fixed: #70443 [Safewhere Admin] The Act as service URI field of the User page is vulnerable to XSS attack.
  • Fixed: #68139 [Safewhere Admin] The default value of the Refresh token expiration setting is not two years when creating a new client.
  • Fixed: #73389 [HostedForm][OS2faktor Device Registration] A contextID error displays after registering an OS2faktor device.
  • Fixed: #73399 [RecoveryCode] Recovery code is not generated when user onboards an Authenticator from My Profile.
  • Fixed: #73417 [MyProfile][EditUser] Information of certificate is not displayed after certificate upload.
  • Fixed: #73448 [Claims] Claims that have friendly name whose value is null are not displayed on Edit user page / Claim transformation page / Edit group page / Claim set page.
  • Fixed: #73494 [Safewhere Admin] You cannot search any application/identity provider via its provider type's friendly name in search field.
  • Fixed: #72500 [Safewhere Admin] Store name information of a manually added certificate on SAML2.0 application or SAML2.0 Identity provider is incorrect.
  • Fixed: #72497 [Safewhere Admin] Error message displays when creating a new user with "set password manually" on Manually update user password and empty Name claim.
  • Fixed: #72176 [Safewhere Admin] Selected options of "Choose the HRD rules and the order that you want them to run" setting on HRD tab of an application are displayed alphabetically, not their index.
  • Fixed: #72092 [Safewhere Admin] All records on AuditUserRequest view are returned when inputting a text value which is not audit user request Id on the search field of the Advanced search.
  • Fixed: #71039 [Safewhere Admin/IdentifyAdmin] Access token exchange throws an error when client secrect on connection "Identify OAuth2 Token for REST APIs" contains special character "+".
  • Fixed: #71778 [AuditUserRequest] User request event Id 305 is duplicated with confused AuthenticationSucceeded information when you login via Username & password identity provider.
  • Fixed: #72328 [Safewhere Admin] Option Identify-initiated common domain cookie on extra HRD rule is not removed on UI when user removes it on a SAML2.0 application, then Save button.
  • Fixed: #72796 [SAML2.0] An error "The private key is not present in the X.509 certificate." throws at idpinitiated flow after repeating login, then logs out many times with an Identity provider where the signature on its SAMLResponse to Identify does not have KeyInfo.

Breaking changes

When upgrading an Identify instance from a previous version, you may experience the following changes in behavior:

  • When updating a user with a new password, a PasswordUpdated event is raised in addition to an Updated event.
  • ASP.NET Core Runtime 3.1.x is now required. You must install the Hosting Bundle package prior to install the Safewhere Identify 5.9 and you should use the latest 3.1.x release. At the time of writing, the latest release is 3.1.10.