@jgrandja @jzheaux Do you have any thoughts on this?

@ParkerM Can you share a bit more information about how you use Testcontainers with Keycloak? Are you using https://testcontainers.com/modules/keycloak/ ?

@philwebb yep, that's the one. Right now it looks a bit like the TestConfiguration + Bean method + injected DynamicPropertyRegistry approach described in the docs here (plus a few startup tasks that would ideally be rolled into the image or exist as opinionated defaults). This class is imported for int tests, and applied for the test application as from(MyApp::main).with(ContainerTestConfig.class).

I did manage to get the test application to start up with this configuration after some finagling — I was experiencing some sort of lifecycle issue with eager connections failing startup before the container was ready. Removing @RestartScope from the bean method caused startup to wait as expected, so I assume it was the cause or a catalyst if not PEBCAK. Unsure if this is in scope for this issue, but wanted to mention it as another reason I yearn for a prescribed convention and to override as a last resort.

In any case, I'm curious whether the goals of the ConnectionDetails abstraction fundamentally align here (even if it's for my own selfish understanding of the API and its goals). If my understanding is correct then the Spring Security configs could potentially be a good fit, since most contain a representation of remote service(s) and the credentials used to connect. This would also provide more sensible means for programmatically accessing validated connection properties. My current approach involves injecting Boot's ConfigurationProperties beans and clumsily accessing deeply nested properties. Separating that concern into ConnectionDetails would make for more obvious injections and provide more convenient options for test stubs and such.

Apologies if the info above isn't what you were looking for. If so let me know and I can expand or perhaps create an example project on my own time.

We talked about this yesterday and we think the ConnectionDetails abstraction fits for something like this, too.

The approach would be the following:

1. Implement ConnectionDetails in the OAuth2 client auto-configuration
2. Implement adapters from the Keycloak testcontainer to the newly created ConnectionDetails
3. Optional, but would be very nice to have: Implement adapters from a Keycloak docker compose service to ConnectionDetails.

Step 2 and 3 is the tricky bit.

I've not looked at the Keycloak testcontainer in detail, but I remember from the standalone Keycloak that one has to do some realm / client setup before it's usable.

I've not looked at the Keycloak testcontainer in detail, but I remember from the standalone Keycloak that one has to do some realm / client setup before it's usable.

Yeah, I currently have realm import do most of the work then use the Keycloak client to adjust some ports before the tests run (maybe the future will see something like a configurer DSL that simplifies test setup).

My original plan was to just implement my own ContainerConnectionDetails and such, which led me to realize ConnectionDetails would be the blocker unless I forego Spring Security AutoConfigurations.

Would definitely like to see this happen as well, for any generic OpenID or OAuth2 provider. I'm specifically thinking about Dex and custom-built authorization servers.

I'd want client_id and client_secret (optionally) available on the ConnectionDetails.

I'm just seeing this now @philwebb. Apologies for the delay.

@rwinch and I have been talking about introducing integration testing support (spring-authorization-server#258) for Spring Authorization Server.

I'm not familiar with the ConnectionDetails abstraction so I would need to look into this and see if this is an entry point for the support.