Improve the way OIDC tenants are grouped and their properties are generated

[sberyozkin]

At the moment, OIDC configuration properties list about 310 properties if we count them one by one, first about 160 properties for the default tenant, and then approximately 150 properties are listed for named tenants.

This PR groups it together (thanks @radcortez for the hint), with about 160 properties grouped together.
Additionally, @ConfigDocSection is introduced with a few exceptions.

Now it will look more organized, see the fragment of it:

This is only an initial, tactical PR to address a pretty bad situation with a massive number of properties generated.

Expanded config doc reference with the detailed explanations, recommendations, as well as a question tree will be looked at later.

Unfortunately it might be a breaking change for some users who are working directly with the OidcConfig group, but the pros of this update are too important for the OIDC simplification story for this update be avoided...

My only concern is that OidcConfig.getDefaultTenant(OidcConfig config) static helper returns null if no default tenant config is found, but I've tested it with empty application.properties and when only non-default named tenants are present and it works, so hopefully it can never be null... (CC @radcortez )

[github-actions]

🎊 PR Preview 81d5343 has been successfully built and deployed to https://quarkus-pr-main-44374-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[radcortez]

My only concern is that OidcConfig.getDefaultTenant(OidcConfig config) static helper returns null if no default tenant config is found, but I've tested it with empty application.properties and when only non-default named tenants are present and it works, so hopefully it can never be null... (CC @radcortez )

When you use @WithDefaults, you are never going to get null when looking up a key. You get either get the specific named configuration or the default one.

[sberyozkin]

Great, thanks @radcortez.

[sberyozkin]

I'd like to tune some section descriptions. Update: just pushed some minor updates...

[gsmet]

Please don't merge, the doc is missing for several of the entries. I'm having a look.

[gsmet]

I think the regression was caused by #44140 . The doc probably wasn't checked after the change.
When converting config, it's probably a good idea to have a look at the generated doc to make sure it's still fine.

[michalvavrik]

I think the regression was caused by #44140 . The doc probably wasn't checked after the change. When converting config, it's probably a good idea to have a look at the generated doc to make sure it's still fine.

I am sorry. I saw config properties were there and I didn't check if that was all of them. If I can help to fix docs generation I am ready.

[gsmet]

I think they are all there but the Javadoc is missing because not generated and the new config generation is a bit too lenient regarding that.

I'm working on fixing that.

The problem is by removing the @ConfigGroup added to the class/interfaces in the common module, we have no idea these are config classes so they are completely ignored by the Javadoc generation.

I will do an independent PR with a fix and some more tooling. And also will fix the other cases that fell through the cracks due to us not having a big error when it happens.

[michalvavrik]

I think they are all there but the Javadoc is missing because not generated and the new config generation is a bit too lenient regarding that.

I'm working on fixing that.

Thank you.

The problem is by removing the @ConfigGroup added to the class/interfaces in the common module, we have no idea these are config classes so they are completely ignored by the Javadoc generation.

FYI, maybe I misunderstood that, but I reviewed other extensions @ConfigMapping groups before I made the change because I couldn't understand if @ConfigGroup is required or not. I am certain there are other extensions that doesn't have it on their groups.

[gsmet]

OK, let's get #44388 in first. Then I think your @ConfigDocSection problem on credentials will be gone.

Basically it should have failed earlier and this section case was the only one for which we had a hard error. What's nice is that this work allowed us to detect the problem.

[sberyozkin]

Thanks @gsmet

[gsmet]

@sberyozkin I rebased and added the @ConfigDocSection to credentials. I was able to generate the output. I let you and @michalvavrik check that it's all fine.

[michalvavrik]

Looks correct. I mentioned that quarkus.keycloak.devservices.create-client needs to be fixed and that Sergey should probably follow with similar changes in OIDC Client, but that's not related.

[sberyozkin]

Thanks for your help, @gsmet. I did tweak a bit the JavaDocs to try to describe the Credentials section as a container for several authentication options. I guess we will be keeping tuning the section descriptions.

@michalvavrik, thanks for verifying, what did you mean about quarkus.keycloak.devservices.create-client ? And indeed, I'll follow with OIDC client and OIDC client registration updates a bit later

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 3f10b51.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[michalvavrik]

what did you mean about quarkus.keycloak.devservices.create-client

it appeared when I was searching for quarkus.oidc props, badly quoted I guess:

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 3f10b51.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.