back to all blogsSee all blog posts

Use the Password Utilities feature without forcefully federating stand alone user registries in Open Liberty

image of author
Reece Nana on Aug 30, 2022
Post available in languages:

Open Liberty has arrived and brings the Password Utilities 1.1 feature, which does not forcefully federate stand-alone user registries. Along with the new feature, this release also includes several notable bug fixes.

In Open Liberty

Run your apps using

If you’re using Maven, here are the coordinates:


Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[,]'

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

Stand-alone user registries no longer forcefully federated (Password Utilities 1.1)

A new version of the Password Utilities feature, passwordUtilities-1.1, is available. This version of the feature does not start the Federated User Registry feature or the Jakarta Connectors feature. When you use this version of the feature, stand-alone user registries are not forcefully federated, which sometimes results in slightly different behavior than the previous version. The previous feature version, passwordUtilities-1.0, starts the Federated User Registry and Jakarta Connectors features by default.

To enable Password Utilities 1.1, add the passwordUtilities-1.1 feature to the list of features in your server.xml file:


For more information about the Password Utilities feature, check out the feature documentation.

Security vulnerability (CVE) fixes in this release

There are no security vulnerability fixes for this release. For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in

  • Invalid character warning for colon in WorkQueueManagerImplMBeanWrapper objectName

    A colon character ( : ) in the Apache CXF WorkQueueManagerImplMBeanWrapper class’s objectName creates a warning and a caused by the invalid : character when is called. This issue occurs in Open Liberty, though it did not appear in

    A fix to this issue was made where by the removal of an invalid : character from URI base in the bus ID and resulted in no additional warning messages. More information can be found in #22069

  • CXF property cxf.ignore.unsupported.policy is not processed correctly in Liberty

    In Liberty, when the JVM system property cxf.ignore.unsupported.policy is set to true, some unsupported policy assertions in the WSDL file are not ignored as expected.

    This has since been resolved to now process the cxf.ignore.unsupported.policy correctly.

  • Expiration fields are not compared in an LTPA Token

    When two expiration times are present in an LTPA token, the times must be compared to confirm whether they are within an acceptable difference.

    The issue is fixed via #21883 and Open Liberty will now reject LTPA tokens when the two expiration times in the token are not within an acceptable difference by throwing an invalidTokenException.

  • Liberty does not provide exported packages for java.* packages at runtime in the OSGi framework instance

    Starting with OSGi R7 Core specification, bundles are allowed to import (using Import-Package header) packages from java. (e.g. When installing a Liberty feature that includes a bundle that imports a java. package, the bundle fails to resolve because Liberty does not configure the OSGi framework (Equinox in this case) to export the java.* packages available in the running JVM.

    The issue is resolved via #16188 and Open Liberty will now configure the OSGi framework to export the available java.* packages for the running JVM.

  • MP Fault Tolerance 1.x can log an FFDC when a method times out at the same time as it completes

    When a method times out at the same time as it completes, an FFDC may be logged. Aside from the FFDC being logged, there are no other symptoms.

    There has been a fix to timeout cancellation race condition which resolves:

    A lock shared between stop() and timeout(), but if the timeout has fired, the timeout future is not complete at the point where timeout() releases the lock. This gives stop() a chance to run and attempt to cancel the future. Doing this results in an InterruptedException which causes and FFDC to be emitted by the policy executor.

    By checking the value of timeout, it avoids trying to cancel the timeout task if the timeout has already fired and interrupted our thread. There has also been a package added to the FT trace group.

    Both the fix to the timeout cancellation race condition and adding the package to trace group has resolved the issue of MP Fault Tolerance 1.x.

  • OpenAPI 2.0+ throws error at startup

    After enabling mpOpenApi-2.0 or mpOpenApi-3.0. at startup, this error might occur because the MP OpenAPI implementation tries to get a MicroProfile Config object before the MicroProfile Config feature has initialized.

    This issue was fixed by only calling Config.getConfig() when needed, rather than when the component starts to avoid occasional cases where the config component hasn’t initialized yet. The fixes are in #21881

  • Multiple protocols not always getting honored with the IBMJDK

    When the IBM JDK is being used not all protocols in a list of protocols will get honored.

    After the fix, each protocol in the list should be able to be used in a connection as long as the protocol is not disabled in the Security configuration.

Get Open Liberty now