Composite claims in OIDC connector

[Oded-B]

Overview

Adds the ability to compose new group claims elements in the OIDC connector, based on other claims.
So this OIDC connector config:

     claimConcatenations:
        - claimList:
           - "organization_slug"
           - "pipeline_slug"
           - "build_branch"
          delimiter: "::"
          prefix: "bk"

Would result in this element in the group claim which looks like this:: bk::acme-inc::super-duper-app::main

What this PR does / why we need it

After #2806 we are able to authenticate with JWT generated by CI systems.
The claim provided by those systems are usually static and if the upstream OIDC service doesn't support sophisticated query language in its IAM/RBAC mechanism the operator might be unable to find a configuration that provided the needed granularity.

For example, lets say you want a specific Buildkiite pipeline to run a sync action on an ArgoCD instance.
These are claim provided by Buildkite CI/CD system:

{
  "iss": "https://agent.buildkite.com",
  "sub": "organization:acme-inc:pipeline:super-duper-app:ref:refs/heads/main:commit:9f3182061f1e2cca4702c368cbc039b7dc9d4485:step:build",
  "aud": "https://buildkite.com/acme-inc",
  "iat": 1669014898,
  "nbf": 1669014898,
  "exp": 1669015198,
  "organization_slug": "acme-inc",
  "pipeline_slug": "super-duper-app",
  "build_number": 1,
  "build_branch": "main",
  "build_commit": "9f3182061f1e2cca4702c368cbc039b7dc9d4485",
  "step_key": "build",
  "job_id": "0184990a-477b-4fa8-9968-496074483cee",
  "agent_id": "0184990a-4782-42b5-afc1-16715b10b8ff"
}

AFAIKT ArgoCD doesn't have any fancy query language in its RBAC config like big cloud providers IAM (regexs are supported to action field only)
So If you want to allow pipelines runs from a specific repo and branch combination, you would need to combine organization_slug, pipeline_slug and build_branch claims ( notice the sub claim includes the git commit, making it unusable as reference for RBAC ).

With this PR you'll be able to concatenate/compose multiple claims to a new element in the group claim:

        - name: Buildkite Agents OIDC
          type: oidc
          id: bk-oidc
          config:
            issuer: https://agent.buildkite.com
            scopes:
              - groups
              - openid
            userNameKey: sub
            claimConcatenations:
              - claimList:
                  - "organization_slug"
                  - "pipeline_slug"
                  - "build_branch"
                delimiter: "::"
                prefix: "bk"

This would be the resulting group : bk::acme-inc::super-duper-app::main
And you can refrence it in ArgoCD RBAC like so:

      g, bk::acme-inc::super-duper-app::main, role:cicd-sync

Special notes for your reviewer

This is intended as a temporary solution until a more flexible solution is provided via #1635.
Because the problem is uniq to service-tied JWTs and only relevant for OIDC I believe a connecter-specific solution is acceptable.

Does this PR introduce a user-facing change?

Enhancements:
* Support composing new group claims in OIDC connector.

[sagikazarmark]

@Oded-B Thanks for the contribution.

I expect's going to be some time before we get #1635 implemented, so I suggest we take a more structured approach, anticipating that other similar features may be added to connectors.

First of all, I find it a bit misleading that groups are not mentioned anywhere even though the concatenated claims end up as groups.

Secondly, I think it would be nice to add at least one level of config above it so that we can collect similar future additions.

A couple options I can imagine:

# ...

claimModifications:
    groups:
        newFromClaims:

# ...

claimModifications:
    newGroupsFromClaims:

I'm not quite sure which one I like better yet. (@nabokihms WDYT?)

[Oded-B]

I used the 2nd option (claimModifications.newGroupsFromClaims) for now but I'll change it per @nabokihms opinion.
Also added comments for each test case.

[sagikazarmark]

LGTM, thank you!

Once the build turns green, good to go.

[nabokihms]

Suggested change

	Prefix string `json:"prefix"`
	Prefix string `json:"prefix"`

Prefix scales badly because people may want to add prefixes, suffixes, or both, or only prefix specific groups.
This is the same problem we are struggling in Kubernetes (that will be fixed in upcoming releases with CEL).

[nabokihms]

This is obscure for users.

1. At least an error should be returned.
2. I do not see any obstacles to support integers or boolean claims.