Managing server secrets in a Java server

[yotommy]

I work on CiviForm, an open-source project that simplifies the application process for government benefits programs by re-using applicant data for multiple benefits applications.

My goal is to enable server secret rotation with an overlap period. I found play-secret-rotation, which seemed very promising. However, it is written in Scala and I am having trouble wiring it into my Java server.

I am now considering writing my own (Java) code, inspired by the approach of play-secret-rotation. It seems that a fundamental step is providing a custom RequestFactory, as shown here. Unfortunately, I do not see a RequestFactory class in the Javadoc for 2.8.x.

Is there some alternative approach I can use in a Java server?

[yotommy]

Let me rephrase this question slightly:

We would like to implement server secret rotation (with an overlap period) in our Java server (currently Play 2.8.x), using Guice. What interfaces, if any, are available to which we can bind custom implementations to accomplish that goal?

[yotommy]

Hi @mkurz just checking in to see if you had any suggestions on a good approach here. Thanks in advance.

[mkurz]

Will look into that the next days for sure.

[yotommy]

This is a blocker for us to migrate to Play 2.9, and 2.8 is rapidly approaching end-of-life.

Background:

• We use play-pac4j for authentication and authorization.
• Play 2.9 requires longer server secrets than we currently have deployed on our 2.8 server.
• My understanding is that simply changing the server secret (with no overlap period between new and old secrets) will cause users with existing Play sessions (with pac4j credential) to get an ugly error when trying to access protected resources. If I understand correctly, users would need to clear cookies in order to access these resources again.

Thanks in advance for any info you can share.

[mkurz]

My understanding is that simply changing the server secret (with no overlap period between new and old secrets) will cause users with existing Play sessions (with pac4j credential) to get an ugly error when trying to access protected resources. If I understand correctly, users would need to clear cookies in order to access these resources again.

I haven't worked with play-pac4j, but my guess would be if you change play.http.secret.key users with the "old" cookies should be handled just like they are not logged in.
So if change play.http.secret.key users will be logged out and "just" need to log in again and that should be it.

[yotommy]

Thanks for this valuable information. This buys us some time to implement secret rotation.

[hertg]

Theoretically, you can bind a custom SecretConfiguration. I have used that strategy to use an application secret that is stored in encrypted form in my persistent storage. I am using an "APP_SECRET" instead, which I pass into the application at runtime, which will then be used to encrypt/decrypt sensitive information before storing it to disk, the play secret being one of them.

This might be a different use-case, but maybe it helps you for yours.
Note: Here, the play secret is generated on the fly if it doesn't exist yet.

// CustomSecretProvider.scala

import org.example.common.utils.Utils
import org.example.settings.SettingsService
import play.api.http.SecretConfiguration

import javax.inject.{Inject, Provider, Singleton}

@Singleton
class CustomSecretProvider @Inject()(settingsService: SettingsService) extends Provider[SecretConfiguration] {

  lazy val get: SecretConfiguration = {
    val secret = settingsService.getEncrypted[String](MainStatics.SETTING_PLAY_SECRET) match {
      case s if s.isEmpty =>
        println(s"generating a new secret secret...")
        // note: play has an internal check whether a secret is secure enough where it just
        // checks the length of the secret. This check may not apply because we use a custom secret provider
        // but just in case, we'll use a secret that has a length of 64 bytes to satisfy the
        // length requirement play would set for 512bit signatures
        val generated = Utils.generateRandomBase64Url(64);

        settingsService.setEncrypted(MainStatics.SETTING_PLAY_SECRET, generated)
        generated
      case s => s.get()
    }
    SecretConfiguration(secret = secret, provider = None)
  }

}

Then bind that inside a custom application loader.

// CustomApplicationLoader.java

import play.api.http.SecretConfiguration;
import play.inject.guice.GuiceApplicationBuilder;
import play.inject.guice.GuiceApplicationLoader;

public class CustomApplicationLoader extends GuiceApplicationLoader {

    @Override
    public GuiceApplicationBuilder builder(Context context) {
        return super.builder(context)
                .overrides(binder -> binder.bind(SecretConfiguration.class).toProvider(CustomSecretProvider.class));
    }

}

Use the custom application loader

play.application.loader = org.example.CustomApplicationLoader

---

In this implementation, the play secret itself is not rotated, but it should be fairly easy to implement it here. I'm not rotating the play session cookie here because I don't really use the play session for anything important other than CSRF. The reason I don't is that once you have more complex requirements, the default Play session handling gets quite limiting.

If you want a seamless transition between secret rotations (the cookie not being invalidated, but being superseded by a new one, without logging the user out), you probably have to implement your own cookie handling for that. I am working on an Identity Provider written in Play that includes asymmetric JWT signatures, seamless key rotations, and rolling session IDs to somewhat protect against cookie stealing. I have been thinking about writing my solutions down in a blog post, but haven't come around to do so yet.

[yotommy]

This looks like an immensely helpful starting point. Thank you, will report back!