Forem: Greg Simons

Spring Security private_key_jwt with AWS KMS

Greg Simons — Mon, 16 Jan 2023 14:44:01 +0000

Spring security has long had great OAuth2.0 support from both the server and client elements. Recently spring security added support for the private_key_jwt client authentication method as part of the authorization code grant flow.
Spring Security GitHub ref

The configuration for the key signing requires both the public and private key to be available to the application. Key Management Service (KMS) by Amazon Web Services (AWS) provides services to centrally manage your keys for encryption and signing and is an option to allow a more centralised mechanism for key rotation and policy management.

In order to add this support in to Spring it requires a number of customisations to be made which will be explained in this post. If your AuthZ server also supports elliptic-curve digital signature algorithms (ECDSA) for the ID token I will outline the additional Bean configuration required as Spring security defaults to RS256 supported with RSA keys.

private_key_jwt

The private key jwt client authentication method requires a jwt token to be sent alongside client id, code as a client assertion to the token endpoint. This jwt will need to be signed and then sent in a client_assertion parameter to the auth server. A number of algorithms are supported by various auth servers and can be found by visiting the configuration endpoint of the auth server.

Full details of the spec can be found here rfc 7523

The first configuration change required is to switch out the default access token response client as part of the HttpSecurity config. This provides the ability to customise the token endpoint request parameters to enrich with the client assertion signed by kms.

@Bean
public Security FilterChain filterchain(HttpSecurity http) throws Exception {
  ....
  http.oauth2Login(oauth2Login ->
    oauthLogin.tokenEndpoint(tokenEndpoint ->
      tokenEndpoint.accessTokenResponseClient(accessTokenResponseClient))).
    .oauth2Client.authorizationCodeGrant(authorizationCodeGrant ->
    authorizationCodeGrant.accessTokenResponseClient(accessTokenResponseClient)));

  ....
  http.build();
}

OAuth2AccessTokenResponseClient

In order to override the request entity handling to add support for the kms signing you need to add a custom request entity converter to the access token response client that you create.

...
@Bean
public OAuth2AccessTokenResponseClient<OAuthAuthorizationCodeGrantRequest accessTokenResponseClient() {
  ....
  DefaultAuthorizationCodeTokenResponseClient client = new DefaultAuthorizationCodeTokenResponseClient();
  client.setRequestEntityConverter(converter);
  return client;
}

From this point it is now necessary to create the converter:

It is important to note whether or not you are creating the beans or are they being managed and created by Spring as you could incur a number of errors if the objects are manually instantiated.

The converter is the main class that allows the overriding of the request parameters.

@Component
public class CustomKMSJWTClientAuthNConverter implements Converter<OAuth2AuthorizationCodeGrantRequest, RequestEntity<?>> {

  private OAuth2AuthorizationCodeGrantRequestEntityConverter defaultConverter;

  public CustomKMSJWTClientAuthNConverter () {
    defaultConverter = new OAuth2AuthorizationCodeGrantRequestEntityConverter();
  }

  public RequestEntity<?> convert(OAuth2AuthorizationCodeGrantRequest req) {
    String signedJWT = createSignedJwt();
    RequestEntity<?> entity = defaultConverter.convert(req);
    MultiValueMap<String, String> parameters = (MultiValueMap<String, String>) entity.getBody();
    parameters.set("client_assertion_type", "urn:ietf:params:oauth:client-assertion-type:jwt-bearer");
    parameters.set("client_assertion", signedJWT);
    return new RequestEntity<>(parameters, entity.getHeaders(), entity.getMethod(), entity.getUrl());
  }
}

Creating a signed JWT

The next step is to create the JWT and use the KMS API to sign the token.

You will need to setup the AWS SDK and KMS Client. For example, I exported the AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN and AWS_ACCESS_KEY_ID environment variables and set them on the command line. There are a number of alternatives supported in spring that can be found here: AWS SDK on Spring

  kmsClient = KmsClient.builder().region(Region.of("....."))
      .credentialsProvider(DefaultCredentialsProvider.create()
      .build();


  // tbc values can be configured with your auth server

  public String createSignedJwt() {
    JWTClaimSet.Builder claimSetBuilder = new JWTClaimSet.Builder().audience('tbc').issuer('tbc').subject('tbc').expirationTime(tbc).issueTime(Date.from(Instant.now())).jwtId('tbc');

    JWTClaimSet claimSet = claimSetBuilder.build();
    return sign(claimSet);
  }

We now have a JWT token ready to sign and verify with KMS.

  public String sign(JWTClaimSet claimSet) {
      ....
      // choose a token alg based on what is supported by your auth Server
      JWSHeader header = new JWSHeader(TOKEN_ALG);

      Base64URL encodedHeader = header.toBase64URL();
      Base64URL encodedClaims = Base64URL.encode(claimSet.toString());
      // create String to sign with KMS
      String signingString = encodedHeader + "." + encodedClaims;
      ....
    }
  }

We now need to use the AWS SDK to create the signing request to pass to KMS to get the signed JWT.

Key Id is the id of your key from AWS.
Signing alg can be selected from a predefined set using
software.amazon.awssdk.services.kms.model.SigningAlgorithmSpec;

  ....
  SignRequest signRequest = SignRequest.builder()

  .message(SDKBytes.fromByteArray(signingString.getBytes()))
  .keyId(KEY_ID)
  .signingAlgorithm(SIGNING_ALG)
  .build();

  SignResponse response = kmsClient.sign(signRequest);
  String signature = Base64.encode(response.signature().asByteArray()).toString();
  return signature;

The above call now provides a Base64 encoded version of the signed string that is attached to the request parameters for the invocation of the token endpoint.

ID Token Verification

Depending on the supported algorithms for the id token you might find that the ID Token is signed with a different algorithm than the default RS256 that spring supports. In order to override this setting you can again create a custom Bean that sets alternative signatures using the JWSAlgorithmResolver.

@Bean
public JwtDecoderFactory<ClientRegistration> idTokenDecoderFactory() {
  OidcTokenDecoderFactory idTokenDecoderFactory = new OidcTokenDecoderFactory();
  idTokenDecoderFactory.setJwsAlgorithmResolver(clientRegistration -> SignatureAlgorithm.RS512);
return idTokenDecoderFactory;
}

QLDB, is it the perfect DDD aggregate store ?

Greg Simons — Tue, 23 Mar 2021 22:23:59 +0000

There has been much talk about the ideal aggregate store in domain driven design (DDD) over the years. One particular post that drew my attention back then was this one from Vaughn Vernon https://kalele.io/the-ideal-domain-driven-design-aggregate-store/ that reached the consensus that some form of serialized json in a document store was optimal. In this approach fields themselves can still remain queryable.

This approach had the added benefit of limiting the complicated mapping that inevitably ensued from object-relational-mapping (ORM) tools. For anyone who has tried DDD without event sourcing and hit some of the encapsulation issues, you will know what I mean.

Change data capture (CDC) (transactional outbox)

One additional highlight of that article is the reference to domain events and persisting these within an ACID transaction with the aggregate.

A pattern that has certainly grown a lot more popularity recently is the CDC outbox pattern which prescribes an outbox table where data can be streamed out to analytics and big data products such as Apache Pinot.

CDC Outbox pattern with MySQL, Debezium & Apache Pinot

For further information on this pattern there are detailed explanations on the concept in the following posts:

Event Sourcing

A number of previous organisations I have been part of have been led down the Event Sourcing (ES) path due to the promises of intrinsic audit and the ability to recreate views on records to previous states. The reality of these approaches can often be fraught with danger without significant experience. In my experience, it has often resulted in applications that were difficult to design, adapt and manage.

This is where a database technology such as Quantum Ledger Database from Amazon Web Services (AWS) can really help simplify the engineering process and help deliver similar benefits to the event sourcing approach but without the added complexity that it can bring.

Quantum Ledger Database (QLDB)

QLDB is a fully managed ledger database that provides a transparent, immutable, and cryptographically verifiable transaction log owned by a central trusted authority. Amazon QLDB tracks each and every application data change and maintains a complete and verifiable history of changes over time. QLDB Guide

Matthew Lewis has written a very useful introduction around the key concepts behind this new style of database and for that reason I will not repeat that detail here. Intro to QLDB

For the purposes of the reference to the perfect aggregate store, QLDB supports the following key attributes:

create cryptographically verifiable versions of your document
documents can be stored with an intention on querying the materialized view of the events within journal
while it doesn't allow you to stream from an outbox table, you can stream from the ledger and filter/reconstruct an event message from something like AWS Lambda

QLDB and the CDC Outbox pattern

QLDB provides QLDB Streams to support attaching a kinesis data stream that allows you to stream data from the journal into kinesis from any point in time. This then enables functionality such as additional views in search databases such as Elastic Search or analytics tooling such as Apache Pinot. QLDB streams takes care of all the configuration around partition keys for kinesis.

The figure above illustrates the mechanism by which data can be transmitted to Online Analytical Processing (OLAP) tooling. I will be producing some demos to back up this post showing CDC Outbox in to Apache Pinot using the new Kinesis connector which was unveiled in a sneak preview by Neha Pawar in Jan 21.

For those of you that want to take a look at the CDC Outbox style pattern with QLDB and Kinesis, Matthew Lewis has created a demo available on github which highlights this process. It is also available as a running reference example that you can play around with at demo.qldbguide.com.

So is QLDB the perfect aggregate store?

Possibly, time will tell as the product evolves and it gains more traction. It does however provide some critical features not available in other database technology that provides greater verifiable integrity of your records.

Thanks for taking the time to read!