X-Road v7.4.0 Release Notes

Release Info

Version number

7.4.0

Release date

21.12.2023

Supported versions

  • 7.4.0

  • 7.3.2

  • 7.2.2

Supported platforms

Central Server

  • Ubuntu 20.04 LTS

  • Ubuntu 22.04 LTS

Configuration Proxy

  • Ubuntu 20.04 LTS

  • Ubuntu 22.04 LTS

Security Server

  • Ubuntu 20.04 LTS

  • Ubuntu 22.04 LTS

  • RHEL 7

  • RHEL 8

  • Docker

Official documentation

https://github.com/nordic-institute/X-Road/tree/master/doc

Source code

https://github.com/nordic-institute/X-Road/tree/master

Software license

MIT

 

On this page:



Changes in This Release

Summary

  • Support for distributing global configuration over HTTPS.

  • Support for rotating global configuration sign keys on the Central Server without having to distribute a new version of the configuration anchor.

  • Support for changing the Security Server address in the Security Server web interface.

  • Make it possible to disable a subsystem temporarily on the Security Server.

  • Support for mapping LDAP groups to X-Road roles so that the Central Server and Security Server web interface users can be centrally managed via LDAP.

  • Configurable minimum supported communication partner Security Server version.

  • Support for enforcing new key creation when generating a certificate sign request (CSR) for authentication and signing keys on the Security Server.

  • Support for managing the registration and management service TLS key and certificate using the Central Server UI and management REST API.

  • Replace Akka with gRPC for inter-process communication between Security Server and Central Server components.

  • Replace the SHA-1 hashing algorithm with SHA-256.

  • Minimum supported JAVA version bumped to version 17.

  • Minimum supported PostgreSQL version bumped to version 12.

    • For RHEL7 systems, a manual update is required. The steps to migrate are available in the Knowledge Base.

  • Minor enhancements and bug fixes based on user feedback.

Both the Security Server and Central Server have been updated to the latest version of Spring Boot, which also upgrades the Jetty version used. This means that backups created prior to version 7.4.0 can not be used to restore the configuration on the newer version.

On the Central Server, restarting Nginx automatically may fail when upgrading to version 7.4.0. In that case, please restart Nginx manually (sudo systemctl restart nginx) once the upgrade process has been completed.

Completed Issues

Issue ID

Type

Summary

Issue ID

Type

Summary

XRDDEV-50

New

Make it possible to disable a subsystem temporarily on a Security Server. Disabling a subsystem temporarily enables the Security Server administrator to disable a subsystem so that all the services added under the subsystem cannot receive requests. If the same subsystem is registered on multiple Security Servers, disabling the subsystem on one Security Server doesn’t affect the others. Disabling a subsystem doesn’t change any configuration items regarding the subsystem or its services, it just makes the association between the Security Server and subsystem invisible to other Security Servers so that they cannot send requests to it. Similarly, a disabled subsystem cannot be used as a service client either.

Note 1: When a subsystem is disabled, all the services under it stop receiving service requests immediately. However, the Security Server may receive service requests targeted to the services under the disabled subsystem for a couple of minutes after a subsystem has been disabled until the change is propagated to all the Security Servers. In that case, the requests are not forwarded to the service provider information systems by the Security Server. Instead, all service requests received during that time period fail and an error message is returned to the service consumer.

Note 2: The Central Server Administrator must refresh the management services WSDL on the management Security Server(s) and configure access rights for the new management service.

XRDDEV-227

New

Make it possible to change the Security Server address in global configuration from the Security Server administrator UI and management REST API. The change is approved automatically by the Central Server, and it doesn’t require a manual approval from the Central Server administrator. By default, the change becomes visible to all the Security Servers in the ecosystem within a couple of minutes.

Note 1: When changing the Security Server address, the address visible on top of the Security Server UI is updated only after logging out and logging back in to the UI.

Note 2: The Central Server Administrator must refresh the management services WSDL on the management Security Server(s) and configure access rights for the new management service.

XRDDEV-445

Improvement

Replace the SHA-1 hashing algorithm with SHA-256. The change is fully backwards compatible and therefore, it doesn't apply to the authentication certificate hash in global configuration V2 and querying OCSP responses between the Security Servers.

XRDDEV-824

Improvement

Add support for enforcing new key creation when generating a certificate sign request (CSR) for authentication and signing keys on the Security Server. The feature is enabled by default which means that it’s not possible to generate a new CSR for a key that already has an existing certificate. The feature can be disabled by setting the proxy-ui-api.allow-csr-for-key-with-certificate system property to true on the Security Server.

XRDDEV-1203

New

Add support for managing the registration and management service TLS key and certificate using the Central Server UI and management REST API. Starting from version 7.4.0, the registration and management service TLS key and certificate can be recreated and downloaded using the Central Server UI and management REST API. Also, it's possible to create a certificate sign request (CSR) and upload a certificate issued by a trusted Certificate Authority (CA). The filenames are change from /etc/xroad/ssl/internal.key to /etc/xroad/ssl/management-service.key and from /etc/xroad/ssl/internal.crt to /etc/xroad/ssl/management-service.crt.

Note: When the key and certificate are rotated, and mTLS is enabled between the management Security Server and the management services, the new certificate must be updated to the management Security Server.

XRDDEV-1689

Improvement

Introduce updated version of the global configuration to support upcoming features. New global configuration version is V3. Also global configuration V2 remains supported for backwards compatibility. Security Servers older than version 7.4.0 use global configuration V2 while Security Servers starting from version 7.4.0 use global configuration V3. Global configuration V3 is extensible and it provides a capability to add new optional elements without breaking backwards compatibility.

XRDDEV-1983

Improvement

Update store names on the Security Server web interface to be in line with the recommended naming convention with Pinia.

XRDDEV-1997

Improvement

Introduce mapping groups to X-Road system groups to support central management of the Central Server and Security Server web interface users via LDAP. The Central Server and Security Server administrator user permissions are managed using X-Road-specific Linux groups that are mapped to X-Road user roles. An administrator must be a member of the X-Road-specific groups in order to access the management UI.

Starting from version 7.4.0, it’s possible to map additional Linux groups to X-Road user roles using the proxy-ui-api.complementary-user-role-mappings and admin-service.complementary-user-role-mappings system properties. It enables granting administrators permissions to the management UI using existing Linux groups instead of adding administrators to the X-Road-specific groups. For example:

/etc/xroad/conf.d/local.ini
[proxy-ui-api.complementary-user-role-mappings] XROAD_SECURITY_OFFICER=group1,group2 XROAD_SERVICE_ADMINISTRATOR=group3,group4

More information about the properties is available in the X-Road System Parameters User Guide.

XRDDEV-1999

New

Make it possible to define what the minimum supported version of a communication partner's Security Server is allowed to be. Starting from version 7.4.0, service providers are able to configure a minimum required X-Road software version for client Security Servers. It means that client Security Servers older than the configured version are not able to access services anymore.

Service providers can configure the required minimum version using the proxy.server-min-supported-client-version system property. By default, the property doesn't have any value which means that a minimum version hasn't been set. Instead, when the value is set, all the minor and patch versions starting from the configured version are approved. More information about the property is available in the X-Road System Parameters User Guide.

X-Road Operators may set this value in the country-specific meta packages, e.g., Estonia and Finland are setting the value to three latest versions which means that requests that are originating from client Security Servers older than version 7.2.0 are not accepted anymore in the Estonian and Finnish X-Road ecosystems. The value is rolling which means that it changes for every X-Road minor version, e.g., when version 7.5.0 is released, the minimum supported version is 7.3.0.

XRDDEV-2028

Improvement

Improve the Security Server proxy components logging so that it logs a warning if it was unable to connect to a node of a clustered Security Server. Only log an error if connecting to all nodes failed.

XRDDEV-2263

Fix

Update the Central Server web interface from Vue 2 to Vue 3.

XRDDEV-2398

Fix

Improve timestamping service recovery on the Security Server so that it is able to correctly recover on all nodes of the cluster when the service becomes available again.

XRDDEV-2403

Improvement

Migrate ASIC container hash-chain verification utility from Ruby to JAVA.

XRDDEV-2412

Improvement

Improve signer components test coverage in preparation of migrating it to gRPC.

XRDDEV-2419

Fix

Deprecate old rate-limiting configuration parameters on the Security Server so that we only use one method for configuring them on both the Security Server and Central Server.

The deprecated parameters are:

  • request.sizelimit.regular

  • request.sizelimit.binary.upload

  • ratelimit.requests.per.second

  • ratelimit.requests.per.minute

The following parameters should be used instead:

  • request-sizelimit-regular

  • request-sizelimit-binary-upload

  • rate-limit-requests-per-second

  • rate-limit-requests-per-minute

Please see the System Parameters Guide for details.

XRDDEV-2440

Fix

Improve role checks on the Security Server frontend so that certain roles don't mistakenly try to request data they don't have access to.

XRDDEV-2441

Fix

Fix and issue on the Security Server frontend that caused the "Add localngroup" dialog to not correctly close in case of errors.

XRDDEV-2444

Fix

Fix potential replay attack issue with the initialization flow of the Central Server.

XRDDEV-2445

Fix

Fix localization issues on the Security Server and Central Server web interfaces.

XRDDEV-2455

Improvement

Make it possible to navigate from member details to Security Server details using the owned servers table in the Central Server web interfaces member details view.

XRDDEV-2456

Improvement

Allow the user to input more than 25 characters as the search criteria in the member and Security Server table views on the Central Server web interface.

XRDDEV-2457

Improvement

Improve the usability of filter fields on the Central Server web interface so that the user wouldn't need to double click the field to search.

XRDDEV-2461

Fix

Fix issue with the service client URL not being validated correctly when edited on the Security Server.

XRDDEV-2462

Fix

Fix issue where the add client service access rights default view would send the incorrect empty value for filtering.

XRDDEV-2463

Fix

Update the Security Server web interface from Vue 2 to Vue 3.

XRDDEV-2465

Improvement

Show a help text in the Security Server UI when the enforce-token-pin-policy property has been enabled and the strict PIN policy rules are enforced. The help text contains the rules so that the user knows what are the complexity requirements for the PIN code.

XRDDEV-2468

Improvement

Migrate the signer component interactions from Akka to gRPC.

Note: Any Akka-related system properties are not supported anymore starting from version 7.4.0, e.g., <component>.akka.remote.artery.advanced.maximum-frame-size. If Akka-related system properties have been used to override Akka's default configuration values, they should be manually removed from the configuration.

XRDDEV-2469

Improvement

Disable showing Liquibase banner during installations to make the installation output less cluttered.

XRDDEV-2470

Fix

Fix an issue that enabled registering Security Servers with duplicate codes on the Central Server under certain conditions.

XRDDEV-2472

Improvement

Introduce a safer way to add new unique constraints on existing database fields on the Central Server, which also runs checks to verify the state of the database beforehand.

XRDDEV-2474

Fix

Fix an issue that caused the new Central Server backups to exclude the Nginx configurations for management and registration services.

XRDDEV-2475

Fix

Fix an issue that caused the automatically re-created configuration anchor not to contain the new signing key after new signing key creation on the Central Server.

XRDDEV-2476

Improvement

Improve messagelog addons test coverage in preparation of migrating it to gRPC.

XRDDEV-2477

Improvement

Improve op-monitor addons test coverage in preparation of migrating it to gRPC.

XRDDEV-2478

Improvement

Improve proxymonitor addons test coverage in preparation of migrating it to gRPC.

XRDDEV-2479

Improvement

Improve environmental monitoring components test coverage in preparation of migrating it to gRPC.