[Bug]: OIDC config is invalid after OIDC plugin breaking change

[lewijacn]

Describe the bug

The current non-github OIDC auth config is constructed similar to:

{
     "clientId": "example_id",
     "clientSecret": "example_password",
     "wellKnownOpenIDConfigurationUrl": "https://www.example.com",
     "tokenServerUrl": "https://example.com/token",
     "authorizationServerUrl": "https://example.com/authorize",
     "userInfoServerUrl": "https://example.com/userinfo"
 }

However after breaking changes introduced in 4.350 of the OIDC plugin, this format is no longer valid for CASC usage and will produce errors similar to below:

io.jenkins.plugins.casc.UnknownAttributesException: oic: Invalid configuration elements for type: class org.jenkinsci.plugins.oic.OicSecurityRealm : authorizationServerUrl,userInfoServerUrl,tokenServerUrl,wellKnownOpenIDConfigurationUrl,scopes.
Available attributes : allowTokenAccessWithoutOicSession, allowedTokenExpirationClockSkewSeconds, captchaSupport, clientId, clientSecret, disableSslVerification, disableTokenVerification, emailFieldName, escapeHatchEnabled, escapeHatchGroup, escapeHatchSecret, escapeHatchUsername, fullNameFieldName, groupsFieldName, logoutFromOpenidProvider, nonceDisabled, pkceEnabled, postLogoutRedirectUrl, rootURLFromRequest, sendScopesInTokenRequest, serverConfiguration, tokenExpirationCheckDisabled, tokenFieldToCheckKey, tokenFieldToCheckValue, userNameField

Reference: https://github.com/jenkinsci/oic-auth-plugin/releases

To reproduce

To reproduce a clean deployment with authType=oidc can be used and logs will be produced indicating this invalid format

Expected behavior

Expected format should be similar to:

{
     "clientId": "example_id",
     "clientSecret": "example_password",
     "serverConfiguration": {
        "wellKnown": {
          "wellKnownOpenIDConfigurationUrl": "https://example.com/.well-known/openid-configuration"
     }
 }

Or below depending on use case:

{
     "clientId": "example_id",
     "clientSecret": "example_password",
     "serverConfiguration": {
         "manual": {
             "issuer": "https://example.com/api/oauth2/v2"
             "tokenServerUrl": "https://example.com/token",
             "authorizationServerUrl": "https://example.com/authorize",
             "scopes": "open-id"
         }
     }
 }

Screenshots

If applicable, add screenshots to help explain your problem.

Host / Environment

No response

Additional context

No response

Relevant log output

No response

[lewijacn]

Currently I believe the recommended guidance is to modify the authConfig secret with the desired configuration and this would get propagated into the jenkins.yaml used. The issue I am seeing, however, is that we don't seem to have support for the nested structure as shown above and currently only support providing top level values in the secret. I was looking at adding this functionality in and would like to avoid making the logic that handles this propagation from secret to jenkins.yaml any more complex, see below:

      InitCommand.shellCommand(loginAuthProps.authType !== 'default'
        // eslint-disable-next-line max-len
        ? `var=\`aws --region ${stackRegion} secretsmanager get-secret-value --secret-id ${loginAuthProps.authCredsSecretsArn} --query SecretString --output text\` && `
        + ' varkeys=`echo $var | yq \'keys\' | cut -d "-" -f2 | cut -d " " -f2` &&'
        // eslint-disable-next-line max-len
        + ` for i in $varkeys; do newvalue=\`echo $var | yq .$i\` && myenv=$newvalue i=$i yq -i '.jenkins.securityRealm.${realm}.[env(i)]=env(myenv)' /initial_jenkins.yaml ; done`
        : 'echo No changes made to initial_jenkins.yaml with respect to OIDC'),

@gaiksaya @peterzhuamazon How do you feel about me adding a python script that we call here instead to do this propagation with support for a nested secret structure and can more easily have some test cases around? Or do you have any other ideas/preference on how we can support this structure?

[dblock]

[Catch All Triage - 1, 2, 3, 4, 5, 6]

[gaiksaya]

@gaiksaya @peterzhuamazon How do you feel about me adding a python script that we call here instead to do this propagation with support for a nested secret structure and can more easily have some test cases around? Or do you have any other ideas/preference on how we can support this structure?

Sounds good @lewijacn . At the time of writing this initially, this was the easiest approach for non-nested yaml. Please make sure to ensure than original yaml stays intact while replacing the values. We can add tests to test the same.
Thanks for contributing!

[lewijacn]

@gaiksaya @peterzhuamazon Raised a PR above for you to review