Release 5.42

July 2025

New in this release

Application/Resource Rule Enhancements

The Application and Resource Rule pages in the Administration Portal have been redesigned to improve usability and enhance functionality. Changes include:

• The Application pages have been redesigned to include both the application configuration and resource rules. This means that the application and associated resource rules can be managed from the same page.
• The Resource Rules page has been redesigned to use a new easy-to-use graphical editor. In this release, an option to switch to the old UI is provided but this will be removed in an upcoming release.
• The graphical resource rule editor includes a test option to simulate the resource rule for different risk results.
• When editing a resource rule, settings like Authentication Flows and Transaction Details can be managed from the resource rule page. For example, Authentication Flows can be created or modified from the Resource Rule UI.
• A resource rule now has Access Filters that determine if a user can authenticate to an application using this resource rule. Supported Access Filters include:
  • Groups – a user can authenticate using this resource rule if they are a member of specified groups.
  • Authentication Context Reference – a user can authenticate using this resource rule if the authentication request from the client contains a specified authentication context reference value. This feature allows the client to influence how the user is authenticated. This is a new capability in this release.
  • Domain-based IDP – a user can authenticate using this resource rule if they belong to a specified Domain-based IDP. This is a new capability in this release.
• The Application List page now includes search and filter capabilities to target which applications are shown.
• The Application Create page has been redesigned to show all application templates. Search and filter capabilities are available to target which application templates are shown.
• The Authorization Server page and corresponding menu have been renamed to Resource Server.
• Many improvements have been made to the Application configuration pages, including:
  • The settings have been ordered to improve usability.
  • The settings now include more detailed descriptions.
  • Settings like the SAML Signing Certificate for SAML applications and the Gateway for RADIUS applications include an option to create a new Signing Certificate or Gateway.
  • Less frequently used settings have been moved to an advanced section of the page.

Enhanced Registration Configuration

When configuring registration, an administrator can now specify the "Minimum Number of Second-factor Authenticators". This setting specifies the minimum number of authenticators the user must register. As an example, suppose an administrator wants their end users to register at least two of the authenticators, Entrust Soft Token, Passkey/FIDO2 or Face Biometric but wants the end user to decide which authenticators to register. This can be achieved by configuring these three authenticators as Optional during registration and then setting the Minimum Number of Second-factor Authenticators to 2.

Enhanced OTP Delivery Configuration

When OTP authentication is enabled in an authentication flow in a resource rule, the allowed delivery types can be configured overriding the delivery types configured in the policy. This allows an administrator to configure different delivery types for different applications. For example, use Email delivery for one application and SMS delivery for another application.

Configuration to specify which delivery types are enabled and the default order of the delivery types is now set together instead of separate settings. This improves usability. The new UI is used in both the OTP policy and per application authentication flows.

Support Administrator Password Management for Directory Managed Passwords

Administrators can now perform password reset and set passwords to require change on next use for users who have directory-managed passwords.

Allow Users to Specify Authenticator Order

End users now have the option to specify their default authenticator order. This setting allows the end user to have a default authenticator that is different from the default specified in the resource rule. For example, suppose the resource rule lists authenticators in the order TOKENPUSH, TOKEN, FIDO. If the user has an Entrust Soft Token, they will always default to TOKENPUSH and if they want to use FIDO they will need to select an alternative authenticator. Allowing the end user to select their own authenticator order allows the end user to specify FIDO as their default authenticator. Now when the user authenticates, they will default to FIDO authentication.

Only authenticators allowed in the resource rule are used for authentication. The new setting only allows the end user to select a different order of allowed authenticators.

Magic Link Enhancements

The following Magic Link enhancements have been made:

• Magic Link is now supported as an authenticator for Portal, OIDC, SAML, and Authentication API applications.
• Magic Link now supports Password Reset in addition to Registration.

The user experience of a Magic Link authentication is the following:

• The user begins authentication from their client. The client waits for authentication to complete.
• An email containing a Magic Link is sent to the end user.
• The end user clicks on the Magic Link in their email.
• The client completes authentication.

As part of these changes, the Magic Link policy page was moved from the Registration menu to the Authenticators menu.

Native Mobile Passkey Support

IDaaS has been enhanced to support Passkey tokens implemented in mobile applications using Android and iOS Passkey SDKs. The Allowed Relying Party ID Hostnames configured in IDaaS Passkey/FIDO2 settings now supports mobile application values.

Improved Web Content Accessibility Guidelines (WCAG) Compliance

Changes have been made to the IDaaS User Portal and the login pages to improve compliance with WCAG 2.2 at the AA level.

Support Import of Passwords from Entrust GetAccess

Enhancements have been made to the IDaaS password APIs to support importing passwords from Entrust GetAccess.

Administration/User Portal Enhancements

The following enhancements have been made to the Administration and User Portal UI:

• An option to Show/Hide the authentication response has been added to the Login UI response fields for all the authenticators.
• Leading and trailing whitespace is now trimmed from OTP responses in the Login UI. This addresses issues encountered when copying and pasting values from Emails or SMS messages.
• Vertical tabs in pages in the administration portal are now left justified and sorted alphabetically. The following pages were changed:
  • Security -> Resource Servers
  • Resources -> Certificate Authorities
  • Configuration -> Knowledge-based Authentications
  • Policies -> Registration
  • Policies -> Authenticators
  • Policies -> Risk-based Authentications
  • Policies -> Soft Token SDK
  • Policies -> User Portal Portal
• The administration portal menu search now supports keywords. For example, both otp and one time password will find the OTP settings page.

Fixed or changed in this release

1. The maximum length of a SCIM API key has been changed from 500 characters to 2000 characters. (39341)
2. The IDaaS JWT grant type now supports ACR values. (38918)
3. Updating a RADIUS application fails if the shared secret was not updated. (35469)
4. Improve error message displayed for an invalid phone number entered when editing delivery contact. (37328)
5. Include IP location information in push notifications sent for IDaaS authentication API applications including integrations like Entrust Desktop Credential Provider. (37677)
6. Selecting an External Risk Engine in a resource rule is not saved. (37930)
7. Deleting a claim value from an OIDC application returns success even though the claim is not deleted. (38430)
8. Updating Passkey/FIDO2 registration level setting with an invalid value causes HTTP 500 error. (38735)
9. Updating Passkey/FIDO2 settings with an invalid hostname value should not be allowed. (38736)
10. Remove semicolon appearing on Entrust Soft Token SDK settings page. (38807)
11. API to update Organization does not support removing description value. (38857)
12. Administration role value selected by group policy is displayed with non-English locale. (38895)
13. Improved documentation of required Entra ID Read/Write permissions. (38995)
14. The org_id claim is not returned when using the OIDC JWT IDaaS grant type. (39008)
15. OIDC Regenerate Client Secret dialog shows Shared Secret instead of Client Secret. (37274)
16. Failed Passkey authentication is not generating an audit. (39164)
17. OIDC Pre-authorized Code grant type should only be shown for OIDC4VC applications. (39260)
18. When a managed tenant of a service provider is deleted, the associated Identity Provider application should be removed. (39274)
19. Device verification fails in some scenarios when the JWT is expired. (39385)
20. Support deflate encoding for SAML requests. (39501)
21. The subject of a Service Provider IDP login audit should not be clickable. (39563)
22. The resource name of a Service Provider IDP login audit should be Admin Portal not User Portal. (39588)
23. IDaaS now rejects requests with an Origin value of null. (39607, 39614)
24. The ACS and Logout URL hostnames of a SAML IDP are now added to the SAML CORs list. (39678)
25. Refresh of tenant list in Service Provider portal generates browser console error. (38869)
26. Header value returned in API rate limiting error contains value in milliseconds instead of seconds. (39960)

Changes to Identity as a Service (IDaaS) APIs

Authentication API

The following changes have been made to support Magic Link as a new authenticator in the Authentication API.

• The value MAGICLINK can be specified where ever an authenticator type is specified.
• The field magicLinkType has been added to the model AuthenticatedResponse returned from the challenge and authenticate APIs. It specifies the type of Magic Link being used for authentication.

The following changes have been made to existing models in the Authentication API:

• The field requestAcrs has been added to UserAuthenticateParameters, UserAuthenticateQueryParameters, and UserChallengeParameters. This field allows an application to pass an ACR value to IDaaS that will be used when evaluating the ACR access filter of a resource rule.
• The field authRequestKey has been added to UserChallengeParameters. This field allows the request key of an authentication request using the IDaaS JWT grant type. This allows authorization request parameters, such as the requested ACR, to be used when processing authentication challenge.
• The field origin has been added to UserAuthenticateParameters. This value allows the client to specify the origin when performing Passkey/FIDO2 authentication which allows IDaaS to select the appropriate Passkey/FIDO2 tokens for authentication.

Administration API

The following changes were made to the Administration API to manage Magic Links.

• The method GET /api/web/v1/users/{userid}/magiclink (getMagicLinkUsingGET) has been added. This method returns the Magic Link for the specified user if one has been created.
• The model MagicLink has been added. It contains information about an outstanding Magic Link.
• the field type has been added to the model MagicLinkCreateParms. Since different types of Magic Links can be created, this field specifies the type of Magic Link being created.
• The value MAGICLINK has been added to the list of second-factor authenticators and is included where ever it is specified such as the list of second-factor authenticators specified in an Authentication Flow.

The following changes were made to the Administration API to manage ACR values. An ACR object defines an Authentication Context Resource value that can be defined as an access filter in a resource rule.

• The method GET /api/web/v1/acrs (getAcrsUsingGET) was added. This method returns all defined ACRs.
• The method POST /api/web/v1/acrs (createAcrUsingPOST) was added. This method creates an ACR.
• The method GET /api/web/v1/acrs/{id} (getAcrUsingGET) was added. This method returns a specific ACR.
• The method DELETE /api/web/v1/acrs/{id} (removeAcrUsingDELETE) was added. This method removes a specific ACR.
• The model Acr was added. This model includes information about an ACR returned from IDaaS.
• The model AcrParms was added. This model includes information about an ACR passed to IDaaS when creating one.
• The field acrFilter was added to the models ResourceRule and ResourceRuleParms. It specifies if the ACR filter is enabled and if so which ACRs it matches.
• The field acrs was added to the models ResourceRule and ResourceRuleParms. If applicable it specifies the list of ACRs the ACR filter matches.
• The field domainIdpFilter was added to the models ResourceRule and ResourceRuleParms. It specifies the Domain-based IDP filter is enabled and if so which IDPs it matches.
• the field domainIdps was added to the models ResourceRule and ResourceRuleParms. If applicable, it specifies the list of IDPs the Domain-based IDP filter matches.

The following changes have been made to support changes to how OTP Delivery preferences are defined:

• The model OTPPreferenceDetails has been added. The model defines information about an OTP Delivery type.
• The field otpDeliveryPreference has been added to the models AuthenticationFlow, AuthenticationFlowParms, and OTPAuthenticatorSettings. This attribute defines an array of OTPPreferenceDetails that lists the type of OTP delivery types that can be used. The order of these values defines the preferred order of the delivery types.
• The field overrideOtpContacts has been added to the models AuthenticationFlow and AuthenticationFlowParms. This attribute defines whether the OTP delivery configuration is defined in policy is used for this authentication flow or whether it is defined for this authentication flow.
• The fields deliveryMethods, otpEmailDefaultDeliveryAttribute, otpSmsDefaultDeliveryAttribute, otpVoiceDefaultDeliveryAttribute, otpWechatDefaultDeliveryAttribute, and otpWhatsappDefaultDeliveryAttribute in the model OTPAuthenticatorSettings have been deprecated. They have been replaced by the field otpDeliveryPreference.

The following changes have been made to support configuration of allowed relying party IDs for the Native Mobile Passkey feature:

• The method POST /api/web/v1/settings/fido/configuration/android (fetchAndroidAssociationFileUsingPOST) has been added. This method fetches the Android association file from a location specified by the relying party ID.
• The method POST /api/web/v1/settings/fido/configuration/ios (fetchAppleAssociationFileUsingPOST) has been added. This method fetches the Apple association file from a location specified by the relying party ID.
• The field androidOrigins has been added to FIDOAllowedRpId. This field specifies a list of FIDOAndroidOriginSettings defining a list of Android Relying Party IDs.
• The field iosOrigins has been added to FIDOAllowedRpId. This field specifies a list of FIDOIosOriginSettings defining a list of iOS Relying Party IDs.
• The models FIDOAndroidAssetLinks, FIDOAndroidAssetLinksTargets, FIDOAppleAppSiteAssociation, FIDOAppleAppSiteAssociationWebcredentials, and FIDOAssociationFileRequest have been added. These models defined arguments and return values for the methods described above.
• The models FIDOAndroidOriginSettings and FIDOIosOriginSettings have been added. These models define fields in FIDOAllowedRpId described above.

The field userAuthenticatorPreference has been added to the model User. This value specifies the authenticator preferences for the user.

The value GETACCESS has been added to the field passwordFormat has been added to the model UserPasswordParms. This allows an application to import GETACCESS passwords using the IDaaS APIs.

Supported TLS Ciphers

IDaaS supports the following TLS Ciphers:

TLSv1.3:

• TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519)
• TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519)
• TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519)

TLSv1.2:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519)
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519)
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519)

Clients should stop using the following TLS Ciphers. Support for them will be removed in a future release.

TLSv1.2:

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519)

Enterprise Service Gateway Deprecation

Entrust will only support the last four releases of the Enterprise Service Gateway (the current version 5.42 and the three previous releases 5.39, 5.40, and 5.41). Entrust recommends that customers always upgrade their Enterprise Service Gateway to the latest release because each release contains security updates to the Enterprise Service Gateway Operating System.

NOTE: In the 5.43 release, changes are planned that will break versions of ESG older than 5.33.

In-place upgrade of the ESG is only supported for versions 5.33 or later. Versions of ESG older than 5.33 are no longer supported. To upgrade versions of ESGs older than 5.33 to the new version, use the following procedure:

1. Download the latest Gateway OVA or Hyper-V file from IDaaS and install on a new VM instance.
2. Add a new Gateway instance to the existing Gateway in IDaaS.
3. Register the new Gateway instance with IDaaS.
4. Disable the old Gateway instance.
5. Repeat these steps to replace all the Gateway instances that use older versions of the ESG.

Once the upgrade is complete, the Gateway instances corresponding to the old ESGs can be deleted from IDaaS and the VMs for those ESG instances can also be deleted.

Entrust Identity and Entrust Windows Desktop Soft Token Deprecation

In the IDaaS 5.43 release, changes are planned that will break the following operations:

• Password reset in versions of Entrust Identity prior to 25.1.1. Customers using the SDKs are not impacted.
• Soft Token online activation in versions of Entrust Windows Desktop Soft Token prior to 3.1

Browser Deprecation

Microsoft no longer supports Internet Explorer 11. Identity as a Service ceased support for Internet Explorer 11 after May 2023.