X-Road v7.4.0 Release Notes
Release Info
Version number | 7.4.0 |
---|---|
Release date | 21.12.2023 |
Supported versions |
|
Supported platforms | Central Server
Configuration Proxy
Security Server
|
Official documentation | |
Source code | |
Software license |
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.
For RHEL7 systems, manual steps are required.
The Java 17 installation instructions for RHEL7 are available in the Security Server Installation Guide for RHEL.
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 |
---|---|---|
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. | |
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. | |
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. | |
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 | |
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 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. | |
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. | |
Improvement | Update store names on the Security Server web interface to be in line with the recommended naming convention with Pinia. | |
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 /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. | |
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 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. | |
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. | |
Fix | Update the Central Server web interface from Vue 2 to Vue 3. | |
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. | |
Improvement | Migrate ASIC container hash-chain verification utility from Ruby to JAVA. | |
Improvement | Improve signer components test coverage in preparation of migrating it to gRPC. | |
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:
The following parameters should be used instead:
Please see the System Parameters Guide for details. | |
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. | |
Fix | Fix and issue on the Security Server frontend that caused the "Add localngroup" dialog to not correctly close in case of errors. | |
Fix | Fix potential replay attack issue with the initialization flow of the Central Server. | |
Fix | Fix localization issues on the Security Server and Central Server web interfaces. | |
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. | |
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. | |
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. | |
Fix | Fix issue with the service client URL not being validated correctly when edited on the Security Server. | |
Fix | Fix issue where the add client service access rights default view would send the incorrect empty value for filtering. | |
Fix | Update the Security Server web interface from Vue 2 to Vue 3. | |
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. | |
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., | |
Improvement | Disable showing Liquibase banner during installations to make the installation output less cluttered. | |
Fix | Fix an issue that enabled registering Security Servers with duplicate codes on the Central Server under certain conditions. | |
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. | |
Fix | Fix an issue that caused the new Central Server backups to exclude the Nginx configurations for management and registration services. | |
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. | |
Improvement | Improve messagelog addons test coverage in preparation of migrating it to gRPC. | |
Improvement | Improve op-monitor addons test coverage in preparation of migrating it to gRPC. | |
Improvement | Improve proxymonitor addons test coverage in preparation of migrating it to gRPC. | |
Improvement | Improve environmental monitoring components test coverage in preparation of migrating it to gRPC. | |