Spring Boot 3.0 support and new security capabilities in Open Liberty 23.0.0.9
You can use Spring Boot 3.x capabilities in your Liberty applications with the new Spring Boot Support 3.0 feature. You can also now authenticate your OpenID Connect clients using the Private Key method, which is more secure than using client secrets, and if you use LTPA or JWT cookies, you can now use different cookies for different applications, according to their context root.
And finally, happy birthday! Open Liberty is now 6 years old. See our history in maker projects.
In Open Liberty 23.0.0.9:
View the list of fixed bugs in 23.0.0.9.
Check out previous Open Liberty GA release blog posts.
Run your apps using 23.0.0.9
If you’re using Maven, include the following in your pom.xml
file:
<plugin>
<groupId>io.openliberty.tools</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>3.8.2</version>
</plugin>
Or for Gradle, include the following in your build.gradle
file:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'io.openliberty.tools:liberty-gradle-plugin:3.6.2'
}
}
apply plugin: 'liberty'
Or if you’re using container images:
FROM icr.io/appcafe/open-liberty
Or take a look at our Downloads page.
Spring Boot 3.0 support
The Liberty Spring Boot Support 3.0 feature provides a more complete support for running Spring Boot 3.0 applications on Liberty. It also provides the capability to thin the application when you create applications in containers.
Prior releases of Liberty provided support for Spring Boot 1.5 and Spring Boot 2.0 applications. Liberty also supported Spring Boot applications packaged as a WAR file, as demonstrated in this recent blog post. With Open Liberty 23.0.0.9, you can deploy Spring Boot 3.x applications by enabling the springBoot-3.0
feature, with support for both JAR and WAR file types.
To run a Spring Boot 3.x application on Liberty, you must be running with Java 17 or higher. Additionally, if your application uses the Jakarta Servlet feature, it must be Jakarta Servet 6.0. Configure these features in the server.xml
file, as shown in the following example:
<features>
<feature>springBoot-3.0</feature>
<feature>servlet-6.0</feature>
</features>
As with previous versions of the Spring Boot Support feature, you can put Spring Boot application JAR files in the /dropins/spring/
directory. Alternatively, specify the Spring Boot configuration elements in the server.xml
file. For example:
<springBootApplication id="spring-boot-app" location="spring-boot-app-0.1.0.jar" name="spring-boot-app" />
For more information, see Configure and deploy Spring Boot applications.
If you have used previous versions of the Spring Boot Support feature and are now migrating your application to use Spring Boot 3, note the following requirements:
-
Jakarta EE 10 features must be used.
-
Security configuration requires in-application modifications.
-
A new server template (
springBoot3
) is available.
Private Key JWT authentication support for OIDC clients
OpenID Connect clients in Liberty now support the private_key_jwt
client authentication method with OpenID Connect token endpoints.
OpenID Connect clients are required to provide authentication data to the OpenID Connect provider when they invoke the provider’s token endpoint.
Clients can authenticate using several different methods, but most of those methods require a client secret.
The private_key_jwt
authentication method enables clients to use asymmetric keys to create signed JSON Web Tokens (JWTs) to authenticate instead of client secrets.
OpenID Connect clients that use this authentication method are no longer required to have a client secret.
Enable this capability in your client application using the private_key_jwt
option for the tokenEndpointAuthMethod
attribute, and the tokenEndpointAuthSigningAlgorithm
and keyAliasName
attributes in either the openidConnectClient
or oidcLogin
elements in the client’s server.xml
file.
For example, when you use the OpenID Connect Client feature, include the following configuration:
<featureManager>
<feature>openidConnectClient-1.0</feature>
</featureManager>
...
<openidConnectClient tokenEndpointAuthMethod="private_key_jwt" keyAliasName="privateKeyJwtAliasRS512" ... />
If you are using the Social Media Login feature, include the following configuration:
<featureManager>
<feature>socialLogin-1.0</feature>
</featureManager>
...
<oidcLogin tokenEndpointAuthMethod="private_key_jwt" tokenEndpointAuthSigningAlgorithm="E512" keyAliasName="privateKeyJwtAliasES512" ... />
The tokenEndpointAuthSigningAlgorithm
attribute specifies the signing algorithm to sign the JWT that is used for client authentication. The keyAliasName
attribute points to the key to use to sign the JWT, and must also be the alias for the public key that corresponds to the private key. The private key must be in the keystore that is specified by the SSL configuration that is referenced by sslRef
in the OIDC client configuration. The public key must be in one of the following locations:
-
The truststore that is specified by the
trustStoreRef
attribute -
The truststore that is specified by the SSL configuration that is referenced by
sslRef
-
The keystore that is specified by the SSL configuration that is referenced by
sslRef
For more information about the configuration options, see the docs:
For more information about JWT authentication, see:
Use different LTPA/JWT cookies for different applications
In previous releases, LTPA and JWT cookies always had the cookie path set to /
, so that any request made to any path on the domain included the cookie. You can now set the LTPA or JWT cookie path to the application context root. With this configuration, you can use different LTPA and JWT tokens for different applications.
Enable the useContextRootForSSOCookiePath
attribute in the webAppSecurity
element. For example, add the following line to the server.xml
:
<webAppSecurity useContextRootForSSOCookiePath="true"/>
For more information about LTPA in Open Liberty, see the docs:
Get Open Liberty 23.0.0.9 now
Available through Maven, Gradle, Docker, and as a downloadable archive.