Forem: Ryszard Grodzicki

Set up Content Encoding for AWS API Gateway in Terraform

Ryszard Grodzicki — Thu, 11 Aug 2022 11:09:00 +0000

Content Encoding in AWS Console

Recently, when looking through API Gateway settings I stumbled upon Content Encoding:

I was curious and thought that I surely want it enabled (and that it should be enabled by default...). So I set it up, tested, was glad with the results, so wanted to include it in my terraform setup.

After searching the web for some time I was sure it's not possible to set it up. In none of the resources related to the API Gateway, stage or deployment, was any parameter related to encoding.

Setup in Terraform

I must've dig really deep into aws terraform provider commit history to find out that they've hidden this parameter under aws_api_gateway_rest_api resource and named it minimum_compression_size !?

So, when this parameter is defined, it means the Content Encoding is turned on and sets what in AWS Console was called Minimum body size required for compression.

resource "aws_api_gateway_rest_api" "this" {
  name        = "the-best-api"
  description = "Api gateway for ${var.environment} environment"
  minimum_compression_size = 4096
}

Hope this helps you and will save you some time searching through the web. 👍

Give this post a heart if you like it!

SOAP security using WSS4J in Apache CXF in Java/Kotlin

Ryszard Grodzicki — Wed, 16 Dec 2020 11:23:45 +0000

Securing SOAP communication in CXF using standard WSSE is not a trivial task, especially considering the documentation is quite old and often shows XML Spring bean configuration and other, a bit outdated, stuff.

We will see how to configure the security both on the server and the client side.

Short explanation of terms used:

WSS - Web Service Security - Official specification of securing SOAP Web Services
Apache CXF - implementation of SOAP protocol in Java. Used both for server side and client
Apache WSS4J - A library from Apache that integrates with CXF and implements WSS specification. We will use the UsernameToken method.

(I'm showing Kotlin code but Java should be very similar and easy to convert to)

Setup

So at the start you should have your classes generated from a wsdl file. Then the CXF's Endpoint should be configured with a CXF Bus and implementation of the main WSDL-generated interface.

I used cxf-spring-boot-starter-jaxws to have the Bus already configured. I declared the SomePort implementation before and EndpointImpl like that:

// in Kotlin apply block just makes the object available as this
@Bean
fun endpoint(port: SomePort){
    EndpointImpl(bus, port).apply {
        this.inInterceptors.add(LoggingInInterceptor())
        this.publish("/ws")
    }
}

With the CXF Spring Boot starter mentioned above, it's all that is needed to have the service up and running.

We will work on this definition to include the WS-security.

Server

So, first things first - let's add the needed dependencies. Here's what you need to add to your maven pom.xml (check if newer versions are available) :

<dependency>
    <groupId>org.apache.wss4j</groupId>
    <artifactId>wss4j</artifactId>
    <version>2.3.0</version>
    <type>pom</type>
</dependency>
<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-ws-security</artifactId>
    <version>3.4.1</version>
</dependency>

Next, we will add the WSS4JInInterceptor to the endpoint, just like the LoggingInInterceptor was already added.
But before that, we will need to declare some properties for this interceptor :

val wss4jProps = mapOf(
    WSHandlerConstants.ACTION to WSHandlerConstants.USERNAME_TOKEN,
    WSHandlerConstants.PASSWORD_TYPE to WSConstants.PASSWORD_DIGEST,
    WSHandlerConstants.PW_CALLBACK_REF to PasswordCallback(username, password)
)

Here we are declaring the UsernameToken method, the type of password and the password callback reference. It's a class we'll have to implement by ourselves. Here the username and password are predefined and constant, but we may as well use database for verification of multiple users:

class PasswordCallback(
        private val username: String,
        private val password: String,
) : CallbackHandler {
    override fun handle(callbacks: Array<out Callback>) {
        val pc = callbacks[0] as WSPasswordCallback
        if (pc.identifier == username) {
            pc.password = password
        }
    }
}

Now, finally, we can add our new interceptor to the endpoint configuration:

// in java you will access inInterceptors through the getter
this.inInterceptors.add(WSS4JInInterceptor(wss4jProps))

Client

To configure the client we'll use JaxWsProxyFactoryBean and WSS4JOutInterceptor.
So we're starting from a plain configuration without security which looks like this:

JaxWsProxyFactoryBean().apply {
    this.serviceClass = SomePort::class.java
    this.address = wsAddress
    this.outInterceptors.add(LoggingOutInterceptor())
    this.inInterceptors.add(LoggingInInterceptor())
}.create() as SmpsPort

Once again - SomePort is an interface generated from wsdl. wsAddress parameter is the url to our service. There are also in and out logging interceptors.

Security

Here we also have to configure a map with configuration for our WSS4J interceptor, but this time it looks a bit different:

private val wss4jProps = mapOf(
    WSHandlerConstants.ACTION to WSHandlerConstants.USERNAME_TOKEN,
    WSHandlerConstants.USER to username,
    WSHandlerConstants.PW_CALLBACK_REF to PasswordCallback(username, password)
)

Then, we can configure the interceptor in JaxWsProxyFactoryBean:

this.outInterceptors.add(WSS4JOutInterceptor(wss4jProps))

HTTP Basic Authorization

If you need an HTTP Basic authorization then there is a fast way to do so on the client side.
On a previously configured JaxWsProxyFactoryBean, instead of adding interceptor, there are fields for username and password:

jaxWsProxyFactoryBean.username = username
jaxWsProxyFactoryBean.password = password

Summary

We have seen how to configure CXF's UsernameToken security.
We ended up with the endpoint configured:

// in Kotlin apply block just makes the object available as this
@Bean
fun endpoint(port: SomePort){
    EndpointImpl(bus, port).apply {
        this.inInterceptors.add(LoggingInInterceptor())
        this.inInterceptors.add(WSS4JInInterceptor(wss4jProps))
        this.publish("/ws")
    }
}

And the client for use in other modules or for test purposes:

@Bean("smpsProxy")
fun smpsProxy(): SmpsPort =
    JaxWsProxyFactoryBean().apply {
        this.serviceClass = SmpsPort::class.java
        this.address = wsAddress
        this.outInterceptors.add(LoggingOutInterceptor())
        this.outInterceptors.add(WSS4JOutInterceptor(wss4jProps))
        this.inInterceptors.add(LoggingInInterceptor())
    }.create() as SmpsPort

Reference

Web Service Security Specification
Apache CXF WSS
Using Apache WSS4j
More advanced examples of WSS4j

Thanks for reading

If you see anything is missing in this guide, please let me know in the comments. And if you found it useful then give a heart, I'll be grateful :)

Upgrading Kotest (Kotlintest) to version 4.2+

Ryszard Grodzicki — Tue, 29 Sep 2020 19:13:49 +0000

Kotest is one of the most popular testing frameworks for Kotlin (known as Kotlintest before version 4.0).
In recent versions there were some changes in class names and general behaviour which makes the transition to newer version not so obvious.

As of writing this post, the recent version of Kotest is 4.2.5 and the examples will be based on it.

Kotlintest to Kotest

If you already have Kotest in your project in version 4.0 or higher then you may skip this section.

So upgrading from old Koltintest you have to remember to change both all of the kotlintest dependencies in pom.xml/build.gradle and change all imports in code files.

Remember that the groupId was changed to io.kotest and some artifact ids have also changed.
Ie. 'kotlintest-runner-junit5' was changed to 'kotest-runner-junit5-jvm'
and
'kotlintest-assertions' as changed to 'kotest-assertions-core-jvm'

General Configuration

Okay, so earlier you could use an interface to make the configuration easier, like setting an isolation mode or adding listeners. (We'll talk about Spring listener later)

So instead of overriding a method, which is more cumbersome:

class ApplicationTest : StringSpec() {
    override fun isolationMode() = IsolationMode.InstancePerTest
    init {
        "sample test" {}
    }
}

You could make such interface:

interface IsolationPerTest : SpecConfigurationMethods {
    override fun isolationMode(): IsolationMode = IsolationMode.InstancePerTest
}

And then use it in a test just by implementing this interface to set an isolation mode:

class ApplicationTest : StringSpec(), IsolationPerTest {
    init {
        "sample test" {}
    }
}

In Kotest 4.2.5 though, the interface has changed its name from SpecConfigurationMethods to SpecFunctionConfiguration.

Spring integration and other listeners

Same as with isolation mode: You can either do this by overriding a method in each test:
override fun listeners(): List<TestListener> = listOf(SpringListener)
or use an interface

interface SpringListenerSpec: SpecConfigurationMethods {
    override fun listeners(): List<TestListener> = listOf(SpringListener)
}

and implement it in the test class (here together with the isolation interface):

@SpringBootTest
class ApplicationTest : StringSpec(), SpringListenerSpec, IsolationPerTest {
    init {
        "sample test" {}
    }
}

What has recently changed is the type of SpringListener - now it's just an alias to a new SpringTestListener class, but it shouldn't be a problem if you've omitted the type declaration of listeners() function.

Just remember to include a @SpringBootTest or @ContextConfiguration annotation when you need any of the spring autowiring.

For more information about Kotest - Spring integration here are the docs.

Extra - global configuration

There is another way of configuring Kotest, this time - globally.
You can create an object extending the AbstractProjectConfig just like that:

object KotestConfiguration : AbstractProjectConfig() {
    override val isolationMode = IsolationMode.InstancePerTest
    override val parallelism = 3
    override val testCaseOrder = TestCaseOrder.Random
}

In this example we've set all tests to have an isolation mode InstancePerTest (more about isolation in Kotest docs), to run in parallel (it should work, but may be problematic in some cases).
We've also made the order of test cases random. It's useful for being sure, that our tests are not depending on the order of execution, as it's a very bad practice.

Thanks for reading and let me know if you've had any more problems with Kotest versions so I can update the article.