Configuring "oauth2" based authentication for "devops" access does not allow to use a different OpenID connect provider

[thjaeckle]

When configuring to secure access to DevOps commands and to connections using oauth2 via Helm:

ditto/deployment/helm/ditto/values.yaml

Lines 1533 to 1546 in 5239859

	# one of: "basic" | "oauth2"
	authMethod: "basic"
	# oauth contains the OAuth2.0 / OpenID Connect related configuration applied when "authMethod" above is "oauth2"
	oauth:
	# allowedClockSkew configures the amount of clock skew in seconds to tolerate when verifying the local time against the exp and nbf claims
	allowedClockSkew: 20s
	# openidConnectIssuers holds a map of issuer-prefixes as key (e.g. "example")
	# and OAuth "issuer" and "authSubjects" list containing which claims to extract from a JWT issued by the issuer
	openidConnectIssuers:
	# example-ops:
	# issuer: "example.com"
	# authSubjects:
	# - "{{ jwt:sub }}"
	# - "{{ jwt:groups }}"

It is currently not possible to choose in the openidConnectIssuers a different OpenID connect provider than already defined in the "normal" oauth2 configuration at:

ditto/deployment/helm/ditto/values.yaml

Lines 1515 to 1525 in 5239859

	oauth:
	# allowedClockSkew configures the amount of clock skew in seconds to tolerate when verifying the local time against the exp and nbf claims
	allowedClockSkew: 20s
	# openidConnectIssuers holds a map of issuer-prefixes as key (e.g. "example")
	# and OAuth "issuer" and "authSubjects" list containing which claims to extract from a JWT issued by the issuer
	openidConnectIssuers:
	# example:
	# issuer: "example.com"
	# authSubjects:
	# - "{{ jwt:sub }}"
	# - "{{ jwt:groups }}"

E.g. with a -ops suffix as in the comments .. Or even a completely different "issuer" endpoint.

The reason seems to be that this is loaded as "Extension" in Ditto (so basically a Singleton) and that only the first configuration is applied (which is the "normal" oauth2 config).

So e.g. having admin users in a separated OpenID connect provider is not possible.

I also figured that this is currently not at all documented at DevOps commands - so adding some documentation about the option to use oauth for securing admin access would also be good as part of the bugfix.