Version 7.0.0 contains a number of changes to the configuration model, SDK, and more. Details are provided below.
As with previous releases, the XML configuration can be converted using a provided XSLT and its associated auto-upgrade.sh script. To run the XSLT on a configuration data set, run the auto-upgrade.sh script, like this:
auto-upgrade.sh
$ $INSTALL_DIR/misc/upgrade/6.8-to-7.0/auto-upgrade.sh $IDSVR_HOME/etc/init/some-config.xml
The configuration model related to HAAPI clients has been updated and new restrictions have been created to ensure that HAAPI-enabled clients cannot be configured with a combination of insecure capabilities. To ensure that the configuration of your server is valid, check the following for each OAuth client that has the HAAPI capability:
You must make these changes to your configuration before upgrading the server to 7.0l otherwise, Curity 7.0 will fail to start. If you upgraded to Curity 7.0 with invalid configuration, you must downgrade to the previous version before being able to modify the client configuration.
The following configuration snippet shows an acceptable client configuration. It shows that both haapi and code capabilities are enabled, and that redirect-uris, as required by the inclusion of the code flow configuration, are also set.
haapi
code
redirect-uris
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
<config xmlns="http://tail-f.com/ns/config/1.0"> <profiles xmlns="https://curity.se/ns/conf/base"> <profile> <type xmlns:as="https://curity.se/ns/conf/profile/oauth">as:oauth-service</type> <id>my-good-oauth-profile</id> <settings> <authorization-server xmlns="https://curity.se/ns/conf/profile/oauth"> <client-store> <config-backed> <client> <id>haapi-enabled-client</id> <capabilities> <haapi/> <!-- Make sure this capability is present --> <code/> <!-- Make sure this capability is present --> </capabilities> <!-- redirect-uris must be configured for code flow configuration to be acceptable --> <redirect-uris>https://haapi-enabled-client.example.com</redirect-uris> <!-- ... --> </client> </config-backed> </client-store> </authorization-server> </settings> </profile> </profiles> </config>
Plug-ins that use the SDK and also rely on the javax.validation API provided with the Curity Identity Server need to upgrade to version 3.0.0. This version is part of Jakarta EE 9. As a result, the package name has been changed from javax to jakarta. This will require all plug-ins to be recompiled with this new package name:
javax.validation
javax
jakarta
-import javax.validation.constraints.AssertTrue; +import jakarta.validation.constraints.AssertTrue;
The new GAV of this dependency is jakarta.validation:jakarta.validation-api:3.0.0. The Hibernate Validators were also upgraded to version 7.0.2-Final; to upgrade to this, the new GAV org.hibernate.validator:hibernate-validator:7.0.2.Final should be used.
jakarta.validation:jakarta.validation-api:3.0.0
org.hibernate.validator:hibernate-validator:7.0.2.Final
Reliance on server-provided versions of JAXB, JAF, and JAX-WS is no longer supported. Plug-ins needing these technologies should obtain them from alternative sources. It’s important to notice that due to this change, it may be necessary to modify certain plug-ins so that the context ClassLoader used to load Jakarta EE Services is the plug-in’s ClassLoader, not the system one, otherwise the plug-in’s provided libraries would not be visible. See the Classpath considerations section for details on how to handle this problem.
As a part of the Java 17 upgrade, the following XML digital signature verification algorithms are now disabled by default:
http://www.w3.org/2000/09/xmldsig#sha1
http://www.w3.org/2000/09/xmldsig#dsa-sha1
http://www.w3.org/2000/09/xmldsig#rsa-sha1
http://www.w3.org/2007/05/xmldsig-more#sha1-rsa-MGF1
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1
As a temporary, unadvised, and unsupported workaround, these can be enabled again by modifying the $IDSVR_HOME/lib/java/jre/conf/security/java.security policy file.
$IDSVR_HOME/lib/java/jre/conf/security/java.security
Transformation Procedures, whose context object type is se.curity.identityserver.procedures.context.TransformationProcedureContext, have a requestingOAuthClient field. The type of this field changed from a custom client type to the standard se.curity.identityserver.scripting.data.OAuthClientConfiguration. This means that procedures of that type will now have access to many more properties than before. All of its methods, except for one, are compatible with the older type – the only change is that context.properties used to return a Map<string, string>, but will now return a Map<string, any> because Dynamic Client Registration (DCR) clients may have properties with any type, not only string values. This may require changes in existing procedures if the procedures had been used together with DCR clients which had non-string properties.
context
requestingOAuthClient
context.properties
Map<string, string>
Map<string, any>
Due to recent Log4j2 updates, when using scripting languages, a system property must be set with the name(s) of the language(s) that should be allowed. For example:
JAVA_OPTS="-Dlog4j2.Script.enableLanguages=javascript"
The size of grant_types column in dynamically_registered_clients table has been increased from 128 to 500 bytes, this is to allow use of all available grant_types when registering a new dynamic client. Migration scripts for each supported (relational) database are provided with this release in the $IDSVR_INSTALL/misc/upgrade/ directory. This is an optional upgrade if the existing column is wide enough.
grant_types
dynamically_registered_clients
$IDSVR_INSTALL/misc/upgrade/
Prometheus metrics now follow OpenMetrics format. Consequently, some metrics have a _total suffix added to their names. Affected metrics:
_total
The validation for endpoint URIs has been changed. It is no longer possible to have a URI containing just a slash /. It should not affect anyone as this would produce a non-functioning system.
/
The Netid (NetiD Access) authenticator that previously was deprecated has now been removed. It is available as an open source component on Github. Download the binary or compile the source and follow the instructions in the README to migrate from the old authenticator to the new open source one.
When used with the Hypermedia API (HAAPI), the Wait (polling) step now also contains the Launch the BankID App client operation. The Launch step was removed so the flow continues straight to the Wait step. This should not affect proper hypermedia clients that are driven by the state transitions provided by the server, but may require changes if the client was coded to expect a certain ordering of states.
Also, related to BankID authentication, a message with an ID of service.rfa4 was added. Localizations for English and Swedish are provided.
service.rfa4