Article

Flexible single sign-on authentication and more in Open Liberty 20.0.0.7

July 17, 2020
Security Java Microservices Kubernetes
Tom Jennings
Software Developer and Adocate Intern

Open Liberty 20.0.0.7 lets you disable the default of returning Lightweight Third-Party Authentication (LTPA) cookies for authentication when using Trust Association Interceptor (TAI) or Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) authentication. You can also disable JSON Web Token (JWT)  cookies when using JWT's single sign-on (SSO) feature. In this article, we introduce these improvements and more in the new Open Liberty 20.0.0.7 release:

How to run your apps using Open Liberty 20.0.0.7

Here are the coordinates if you're using Maven: 

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>20.0.0.7</version>
    <type>zip</type>
</dependency>

For Gradle, you would use: 

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[20.0.0.7,)'
}

If you're using a docker container, it's: 

FROM open-liberty

Another option is to download the Kernel package as a ZIP file from the Open Liberty downloads page. You can then use the featureUtility command to add the features that you need to the kernel.

LTPA cookies contain an encrypted authentication token with user identity and expiration information, which you can use for single sign-on (SSO) authentication. In Open Liberty 20.0.0.7, you can decide whether you want to receive the LTPA cookie when using TAI or SPNEGO for authentication.

When a client (like a browser) is authenticated with an Open Liberty server, the default response is to receive an SSO LTPA cookie in the HTTP servlet. When that client accesses another protected resource in the Open Liberty server sharing the same LTPA configuration, authentication with the SSO LTPA cookie takes priority over any other authentication mechanism. Prioritizing authentication with the SSO LTPA cookie can cause unintended results if you are using another authentication mechanism. You can now work around this by disabling the creation of LTPA cookies when using TAI and SPNEGO authentication.

Here's how to disable LTPA cookies for TAI in the server.xml: 

<server>
  <featureManager>
    <feature>appSecurity-2.0</feature>
  </featureManager>
  <trustAssociation id="sample" disableLtpaCookie="true" />
</server>

Here's how to disable LTPA cookies for SPNEGO (also in server.xml): 

<server>
  <featureManager>
    <feature>spnego-1.0</feature>
  </featureManager>
  <spnego id="sample" disableLtpaCookie="true" />
</server>

When a client (like a browser) is authenticated with an Open Liberty server through the JSON Web Tokens SSO feature (jwtSso-1.0), the default response is a JWT SSO cookie in the HTTP servlet. When that client accesses another protected resource in the same Open Liberty server or a different one, authentication with the JWT cookie is prioritized over any other authentication mechanism. Prioritizing authentication with the JWT cookie can cause unintended results if you are using another authentication mechanism. You can now work around this issue by disabling JWT cookies when using the JWT SSO feature.

Here's how to disable JWT cookies for JWT SSO in the server.xml: 

<server>
  <featureManager>
    <feature>jwtSso-1.0</feature>
  </featureManager>
  <jwtSso id="sample" disableJwtCookie="true" />
</server>

Bug fixes in Open Liberty 20.0.0.7

In this section, we describe just a few of the issues that we've resolved with the 20.0.0.7 release. See fixed bugs in Open Liberty 20.0.0.7 for a complete review.

Two bugs fixed in JAX-RS 2.1

Issue 8048: NullPointerException: If you've seen a NullPointerException when writing multipart form data in your JAX-RS response, the good news is that we fixed it. See issue 8048 for details.

Issue 12715: ContextResolver: A user needed a way to restrict JSON field serialization by a user's security role. They were able to make it work by using ContextResolver to specify the JSON-B visibility strategy and injecting the SecurityContext. Unfortunately, the injection into the ContextResolver wasn't working. We fixed that with issue 12715, which makes a pretty cool use case.

Improvements to HTTP/2

Issue 12599: HTTP/2 connection: A user reported a scenario involving excess CPU consumption when a client did not gracefully terminate an HTTP/2 connection. We've resolved the CPU consumption with issue 12599.

Issue 12399: HTTP/2 flow control: In specific cases, Open Liberty was not updating its HTTP/2 read window quickly enough, causing the flow-control window to stall. We have improved the flow-control behavior with issue 12399.

Resolving a missing dependency in MicroProfile Fault Tolerance 2.1

Before this release, adding a dependency to the MicroProfile Fault Tolerance 2.1 feature in a maven or gradle build did not automatically add a corresponding dependency to the MicroProfile Fault Tolerance 2.1 API. In some cases, when writing or compiling an application that used the API, users received the error message: 

The import org.eclipse.microprofile.faulttolerance cannot be resolved

We've resolved the missing dependency with issue 12567.

Try Open Liberty 20.0.0.7 in Red Hat Runtimes

Open Liberty is part of Red Hat Runtimes. If you're a Red Hat Runtimes subscriber, you can try this new Open Liberty release now.

To learn more about deploying Open Liberty applications to Red Hat OpenShift, see our Open Liberty guide: Deploying microservices to OpenShift.

Last updated: July 15, 2020

Comments