Safewhere Identify 5.18 Release Notes

This document summarizes all new features, bug fixes, and breaking changes for version 5.18, along with notes on upgrading from previous versions.

Breaking and high-risk changes

Identify 5.18 is a significant release with important changes. While we strive to maintain backward compatibility, some major security changes might cause resource access issues in Identify tenants with complex organizational structures or OAuth2/OIDC setups. We strongly recommend thoroughly testing the upgrade on a test Identify tenant before proceeding with your production environment. These changes include:

• The newly implemented Organization-level authorization policy.
• Enhanced CORS support for high-risk endpoints.
• New changes for the REST API.

New features and improvements

Safewhere Identify

Organization-level authorization

Safewhere Identify first introduced fine-grained authorization for the REST API and the new Admin UI in version 5.14. Since then, we have continuously worked on implementing organization-level authorization (referred to as the 'org-authz' policy in this document). This feature is now fully implemented in version 5.18. In summary, this authorization model restricts user access to resources belonging to or under organizations the user has access to, as follows:

• If you are a member of the Root organization (meaning your user account is registered directly under this organization), you will have access to all organizations in the system and the resources within them.
• If you are a member of a child organization, you will not be able to see the parent organization(s) and resources located within them. You can only access resources within your organizational hierarchy.

For more information, please visit the Organization-level authorization policy document.

New scripting extensible points in the Script library

Starting with version 5.12, Identify introduced the Script library feature, which provides numerous extensible scripting points. This allows the integration of custom business logics into the Identify runtime pipeline through C# scripts.

In the latest version, Identify expands this feature by adding new extensible scripting points, completing the Script library feature set.

Scripting interceptors

Interceptors are a powerful feature in Identify, but it presents a deployment challenge: DLLs need to be deployed across multiple nodes and redeployed after each upgrade. To address this, the Scripting interceptors feature is now supported. This allows for using scripts to intercept both the upstream and downstream flows, simplifying deployment and maintenance.

Scripting Generic providers

Generic providers are another powerful feature in Identify, similar to interceptors, and faces the same deployment challenges. The new Scripting generic provider feature allows the use of scripts for credential validation within a specific Generic provider connection, offering a more flexible and efficient approach.

Scripting extension points for OAuth/OIDC application and Identity provider

In this version, Identify introduces extensible scripting points for OAuth/OIDC applications and Identity providers, enabling users to:

• Validate the authentication context class sent in authorization requests from an OAuth/OIDC client application.
• Customize the step-up behavior of an OAuth/OIDC client application.
• Select which Identity Providers an OAuth/OIDC client application can use (connection dependency customization).
• Validate the authentication context class returned from an upstream OAuth/OIDC Identity provider.
• Customize the authentication context class sent in Authorization requests to an upstream Identity provider.
• Customize authorization requests sent to an upstream OAuth/OIDC Identity provider.

For more details on this topic, please refer to the Script library

Additionally, Identify has updated the descriptions of some existing scripting points:

• "Validate authentication context class that is sent via an AuthnRequest from a Service Provider" is now "Validate authentication context class that is sent via an AuthnRequest from a SAML Service Provider".

• "Customize step-up behavior" is now "Customize step-up behavior of a SAML Service Provider".

• "Select which Identity Providers a Service Provider can use (connection dependency customization)" is now "Select which Identity Providers a SAML Service Provider can use (connection dependency customization)".

• "Validate authentication context class that is returned from an upstream Identity Provider" is now "Validate authentication context class that is returned from an upstream SAML Identity Provider".

• "Customize authentication context class that is sent via an AuthnRequest to an upstream Identity Provider" is now "Customize authentication context class that is sent via an AuthnRequest to an upstream SAML Identity Provider".

• "Customize an AuthnRequest that is sent to an upstream Identity Provider" is now "Customize an AuthnRequest that is sent to an upstream SAML Identity Provider".

OAuth 2.0 and OIDC

PrivateKeyJwt method support for Token revocation and Introspection endpoints

Identify now supports the use of the private_key_jwt authentication method for token revocation (RFC 7009) and introspection (RFC 7662) endpoints, consistent with its usage at the token endpoint.

For more details on implementing the private_key_jwt method for these endpoints, please visit this guide.

Claim mapping support to issued claims from the OIDC Generic Provider

Before Identify 5.18, by default, the OIDC Identity Provider automatically maps incoming claims to a set of predefined claims. If an incoming claim is not in the predefined list, Identify maps it to an unusable "urn:{provider name}:claimtype" format. Starting with version 5.18, we support the new Default claim mapping action setting which allows specifying the mapping action for these claims.

For more details, please refer to default claim mapping action.

OAuth 2.0 step-up authentication challenge protocol (RFC 9470)

Starting from version 5.13, Identify has supported the step-up feature for OIDC applications via the acr_values and max_age parameters in authorization requests. However, the acr and auth_time claims were only included in the ID token.

Identify now includes both the acr and auth_time claims in the access token. When the Introspection endpoint is called with this access token, these claims are also returned in the introspection response.

Add the Use PKCE option in Generic OIDC Provider and social media connections

OAuth 2.0 public clients using the Authorization Code Grant are susceptible to the authorization code interception attack. As an Identity provider, the Identify's OAuth 2 implementation fully supports Authorization code grant (PKCE) which can mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy").

However, as an application connecting to an upstream Identity provider, Identify did not previously support PKCE. In this version, we have introduced the Use PKCE option in Generic OIDC Provider and social media connections. When enabled, Identify uses the Authorization Code flow with PKCE to federate with the upstream Identity provider:

• The authorization request from Identify to its upstream Identity provider now includes a hased code_challenge and code_challenge_method.
• code_challenge_method uses the S256 hashing algorithm.
• After receving the authorization code, the token request from Identify to its upstream Identity provider contains the code_verifier parameter.

Enhanced CORS support for high-risk endpoints

Starting with Identify version 5.18, we've enhanced the security and flexibility of Identify by introducing support for subdomain wildcard matching in the Access-Control-Allow-Origin header for CORS (Cross-Origin Resource Sharing). This new feature allows trusted subdomains to access endpoints securely, minimizing potential security risks.

For more details on this new support, please refer to this topic.

Identify configurator

Display a warning for version mismatch in the Tenant reconfigure wizard

Identify now displays a warning in the Tenant reconfigure wizard if the selected Identify tenant's version differs from the Identify Configurator version. This helps prevent unexpected misconfiguration issues by ensuring that the tenant's version matches the Configurator version before performing reconfiguration actions.

Additionally, if you select any of the following actions:

• Change signing certificate
• Deploy Safewhere Admin
• Enable multi-subnet failover
• Change security settings

a confirmation dialog will appear to notify you of the version mismatch again.

Precompile Identify's admin and runtime resources

When installing a new Identify tenant or upgrading an existing one, there are noticeably slow steps in the process. One of the slow step is caused by ASP.NET compiling text resource files into DLLs when the Identify application starts for the first time. For customers upgrading hundreds of tenants, this delay adds up and becomes a major performance issue.

This topic explains how to precompile text resources before upgrading tenants, which can significantly speed up the upgrade process.

Identify Admin redeployment for all Identify tenants

Previously, we provided a solution to redeploy a failed Admin portal upgrade for a specific tenant.

In this version, we have introduced a new action in the Identify Configurator (IC) and Command-Line Interface (CLI) that allows you to redeploy Identify Admin across all tenants simultaneously. This significantly reduces the time and effort required for large-scale deployments.

For more details, please refer to this topic.

Extend Audit issue claim logging for OAuth 2.0/OIDC service provider

Identify now logs claims issued during user logins to OAuth 2.0/OIDC service providers. These logs are accessible in the Audit issued claim view under Audit Logs.

Identify Admin and IdentifyMe

Purge all in use expired certificates

Identify now supports the functionality to purge all in use expired certificates in an Identify tenant. This cleanup improves performance when loading certificates in the certificate list.

Set up text resource containers

Previously, Identify only provided the ability to provision text resource containers through the REST API.

Now, Identify offers a user-friendly interface for customizing containers in Identify Admin.

For more details, please visit this topic.

Generate REST API keys with selective roles

Identify Admin now allows you to generate access tokens with selective roles in the My REST API key page:

For more details, please visit this topic

Username & Password login metrics report

Identify now offers an overview of key metrics related to username logins, assisting administrators and security professionals in understanding login patterns, detecting potential security threats, and enhancing overall system security. The report includes data on successful and failed login attempts, as well as user account lockouts.

For more details, please visit this topic.

Configuration data export in Identify Admin

Identify now allows exporting the current configuration of Identify resources directly within Identify Admin. To do so, navigate to any of the following resource lists:

• Claim transformations
• Applications
• Identity providers

Hover over a resource and select the option to export its data:

A JSON file containing the resource's current configuration will be generated. This export feature assists administrators in sharing configurations with support teams, aiding in the analysis of login patterns and the identification of potential issues.

Note: Be sure to sanitize any sensitive data in the exported configuration file before sending it outside your organization.

Easily create and edit custom hosted forms

In previous versions, the Hosted forms UI only supported built-in views. Features like scripting HRDs, scripting interceptors, and scripting Generic providers often require custom hosted forms, which previously could only be created through the REST API.

To simplify this, Identify Admin now supports creating and editing custom hosted forms directly within the Admin UI.

For more information, please refer to this link.

Use of nonce parameter in authorization requests from Identify Admin to Identify Runtime

Authorization requests from Identify Admin now include the nonce parameter, enhancing security by preventing attackers from guessing request values.

Sign Out support on Identify Admin when error page displays

Identify Admin now offers a **Sign Out** functionality when an error occurs in Identify Admin immediately after authentication, such as on the Access denied page

Clicking this link allows the user to log out of their account and initiate a new login.

Add support for the External ID setting for Identify users

The External ID field has been added to the Create/Edit user page, allowing you to store an ID from an external system if available.

Support for Transfer Scoping to Upstream Identity Provider in SAML2 Identity Provider

Identify Admin now includes the Transfer Scoping to Upstream Identity Provider setting in the SAML2 Identity Provider. This enables forwarding the Scoping element of an AuthnRequest from a Service Provider - containing the IdpList - to an upstream Identity Provider.

Add support for custom SQL command timeout

By default, the SQL client command timeout is set to 30 seconds. This means that if the system runs a slow query - such as deleting a large dataset of users with a large page size or querying users with a very large page size - the query may encounter a timeout error.

Identify now enables system administrators to adjust the SQL command timeout for all database queries and commands through the SQL Command Timeout setting on the Setting page.

Control default status of the Send password email to user setting on new user form

Previously, the default for the Send password email to user setting on the new user form was No.

Identify now enables system administrators to control the default for this setting through the new Send password email to user setting on the Setting page.

For more details, please visit this topic.

Update the configuring of IdentifyMe

Due to organization-level authorization requirements, IdentifyMe's system token can no longer access the REST API, as it lacks a user ID within the system token. To resolve this, we need to configure specific resources to allow the system token to be issued with a user ID.

For more details on setting up these resources, please refer to the Set up IdentifyMe connection topic.

UX enhancement to the Single Sign On service setting in SAML 2.0 applications

Previously, Identify Admin displayed only the assertionConsumerService with the urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST binding in the Single Sign On service setting for SAML 2.0 applications, as this is the most commonly used option.

Identify now supports configuring multiple bindings for the Single Sign On service setting.

Display a warning when enabling Intercept login flow without selecting Interceptor type name in connection configuration change

Identify Admin now displays a warning when the Intercept login flow option is enabled without selecting an Interceptor type name during Application or Identity Provider configuration changes.

This warning helps administrators stay aware of potential misconfigurations.

Note: The Application or Identity Provider change will still be applied successfully, regardless of this warning.

Other improvements

New SEC event log for SAML request received from service provider or sent to upstream identity provider

SAML request messages received from the service provider or sent to the upstream identity provider are now recorded (EventId 5518) in the Identify logging. This enhancement logs additional parameters in this SAML request received by Identify or sent from Identify, aiding in troubleshooting.

You can find this new event ID in the security logging example section.

Security events to message queue

Identify now supports publish logs to message buses like Azure Service Bus or RabbitMQ beside publishing domain events to messsage buses about changes made to its domain objects.

Common error message for unregistered or unfound users in WebAuthn Authentication

When authenticating with WebAuthn as the first factor, if errors occur such as the user not being found or not being registered, Safewhere Identify returns a null allowCredentials and a common error message "Either your username does not exist or you have not registered a WebAuthn authenticator".

Removal of NemID Identity provider

Following the shutdown of NemID services, the plugin is no longer operational. As a result, the NemID authentication connection has been deprecated from both the Identify REST API and the Identify Admin interface.

Using Application Insights to collect security metrics

We have added a new guideline for using Azure Application Insights to monitor key security metrics related to user authentication and authorization activities.

REST API: Filter users by group, organization, and externalId

The REST API now supports filtering users by their group, organization, and externalId. For more details, please refer to this topic.

REST API: Sort users by userName, externalId, and user claims

The REST API now supports sorting users by their userName, externalId, and claims. For more details about the changes, please refer to the Safewhere Identify 5.18 REST API Release Notes.

Improving validation for unconfigured post_logout_redirect_uri in the OIDC logout request

Identify now has improved the error handling for cases where the post_logout_redirect_uri value in the OIDC logout request has not been configured in the connection. Users can view the error details in the URI:

https://identify01.identify.safewhere.com/runtime/plugin/malformedrequest?error=invalid_request&error_description=Invalid post_logout_redirect_uri. Registered: https://oidcwebappnetcore1.sp.safewhere.com/signout-callback-oidc. Specified in the request: https://oidcwebappnetcore1.sp.safewhere.com/undeclare

Resolving the 405 error caused by the WebDAV Publishing feature on Windows Server

Previously, when the WebDAV Publishing feature was enabled on Windows Server, the 405 error would occur when updating an Identify resource, displaying the message: 405 - HTTP verb used to access this page is not allowed.. As a workaround, the WebDAV Publishing feature had to be removed from Windows Server.

Identify's web.config is now configured to ignore the WebDAV module by default, so the error no longer occurs.

Fetching the correct WS-Federation authentication sign off endpoint for the SignOut reply endpoint

Previously, when importing WS-Federation metadata from another Identify tenant to WS-Federation applications, the SignOut reply endpoint defaulted to /runtime/wsfedauth/consume.idp. This caused the logout process to fail when attempting to sign out from the WS-Federation application.

Identify now corrects this by fetching the correct sign-off endpoint, /runtime/wsfedauth/signoff.idp, for the SignOut reply endpoint.

InUseCertificate logic enhancement

Identify has extended the In use validation check for certificates to include the following certificate settings:

• OAuth/OIDC applications: Bootstrap token trusted issuers, Received security token encryption certificate
• Settings: Secondary signing certificate

5.18 Known issues

You can find the known issues of version 5.18 here.

Bug fixes

• Fixed: #115657 [OpenId Connect Discovery Endpoint] The tls_client_certificate_bound_access_tokens value was not in boolean format
• Fixed: #112083 [OAuth] The client_secret was required when calling the token endpoint for active flows using the private_key_jwt authentication
• Fixed: #112114 [OAuth][Bearer] The error description in the error response contained an encoded value in assertion's subject when it included special characters and did not match any Identify user.
• Fixed: #114862 [SPML] Exception details: Castle.MicroKernel.Handlers.HandlerException: Cannot create component 'DefaultSpmlService' due to unsatisfied dependencies is returned when sending an SPML request
• Fixed: #116761 [MariaDB] Tenants using the MariaDB provider occasionally experienced random hangs when accessing the new/edit user page
• Fixed: #116054 [OTP] Data corresponding to the "Do not ask again for x days" option in the [UserSecondFactorDeviceRegistration] table was not cleared when the associated second factor was reset
• Fixed: #115904 [Runtime] The system was sending notification emails to users about changes to their registered authenticators when they had asked to do TOTP authentication and selected the "Do not ask again for X days" option.
• Fixed: #115589 [IdentifyAdmin] "Analysis" setting status displayed as Active even after being changed to 'Not active'
• Fixed: #114183 [IdentifyAdmin] Attribute consuming service information was not added to the SAML 2.0 application
• Fixed: #114179 [IdentifyAdmin] New entity IDs in the extra entity IDs field were not added to the WS-Federation/WS-Trust application
• Fixed: #110613 [IdentifyAdmin] The display name of existing Scope information was not allowed to be changed in the OAuth2/OIDC application
• Fixed: #112769 [IdentifyAdmin] An error message was returned when updating the claim type value on its edit page and then refreshing the page
• Fixed: #112810 [IdentifyAdmin] HTML errors in the RecoveryCode hosted form and the AuthenticationList hosted form
• Fixed: #113086 [IdentifyAdmin] Duplicate Show the link to return to the selector page setting in the connection tab of the LDAP identity provider page
• Fixed: #116041 [IdentifyAdmin] The maximum number of certificate records in the "Select Certificate" dialog limited to 1000
• Fixed: #116697 [IdentifyAdmin] The previously selected second factor was included in the Identity provider update after resolving the The second factor authentication connection is not found error
• Fixed: #113766 [Logging] Errors were not logged when the upstream IdP sent a logout request with SAMLResponse content to Identify
• Fixed: #114465 [Logging] Log entries were not sent to Application Insights when enabled on the Logging page without an IIS reset
• Fixed: #110126 [Logging] Missing detailed logs for messages that Identify sends to the service bus
• Fixed: #116852 [Logging] Enhanced revision logs for data change during connection/certificate/logging update
• Fixed: #116801 [Logging] Identify continued logging to Application Insights if its Instrumentation Key or connection string is not empty, regardless of its log target being disabled
• Fixed: #114671 [RESTAPI] promoteSecondaryCertificateToPrimaryAt value was not set to null when calling the PUT method to update it in System Setup without secondarySigningCertificate information
• Fixed: #113908 [RESTAPI] An incorrect default value for pageSize was applied to the auditlogs endpoints
• Fixed: #110669 [RESTAPI] An incorrect status code returned when calling the endpoint: DELETE api/rest/v2/organizations/many
• Fixed: #116288 [RESTAPI] Identify API did not support the Authorization header value with the "Bearer" scheme
• Fixed: #116779 [Swagger] The Enabled parameter requirement for the admin/api/rest/v2/users/.batchStatus API was incorrectly set to True