Support OIDC `subjects` which reference a GitHub Org and wildcard Repo

[johnstonmatt]

OIDC represents a big improvement in terms of security by reducing the risk of leaked credentials, and at polyseam/cndi we want to bring that value to our users.

In our integration with AWS we are able to specify a trust policy which grants OIDC access for all repos in a given GitHub Organization using a wildcard pattern.

Creating a new OIDC app registration for every repo is such a manual process that I don't think it is sufficiently easy to adopt, and our users will likely continue to use API credentials instead - unless support for wildcard patterns can be added.

[petrsx]

related #346

See #346 (comment)

[imar-io]

Please add this feature... Works in AWS for a long time...

[CpuID]

Pretty sure this is dependent on this preview expanding further https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-flexible-federated-identity-credentials

[reismade]

Just came here to request exactly the same feature.

[pmabres]

Just came here to say that I was able to create a flexible federated identity using a user managed identity with the following rest call:

az rest --method put \
  --url https://management.azure.com/subscriptions/YOUR_SUBSCRIPTION/resourceGroups/YOUR_RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/YOUR_USER_ASSIGNED_IDENTIRY/federatedIdentityCredentials/TARGET_NEW_FEDERATED_IDENTIRY\?api-version\=2025-01-31-preview \
  --body "{\"properties\":{\"issuer\": \"https://token.actions.githubusercontent.com\",\"audiences\":[\"api://AzureADTokenExchange\"],\"claimsMatchingExpression\":{\"languageVersion\": 1, \"value\": \"claims['sub'] matches 'repo:YOUR_ORG/*'\"}}}"

The only issue is that this generates an HTTP 500 error on azure cli (will debug further to see whats causing it)

EDIT:
Update on this issue, I'm not sure what the issue might be but here is the error I get from querying the login.microsoftonline.com api manually:

curl --location 'https://login.microsoftonline.com/REDACTED_MY_TENANT_ID/oauth2/v2.0/token' \
--header 'User-Agent: python-requests/2.32.3' \
--header 'Accept-Encoding: gzip, deflate' \
--header 'Accept: application/json' \
--header 'Connection: keep-alive' \
--header 'x-client-sku: MSAL.Python' \
--header 'x-client-ver: 1.33.0b1' \
--header 'x-client-os: darwin' \
--header 'x-ms-lib-capability: retry-after, h429' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=REDACTED_MY_CLIENT_ID' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_assertion=REDACTED_MY_OIDC_JWT_TOKEN' \
--data-urlencode 'client_info=1' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'claims={"access_token":+{"xms_cc":+{"values":+["CP1"]}}}' \
--data-urlencode 'scope=https://management.core.windows.net//.default'

AADSTS100028: Backup Auth Service attempted to serve request that previously failed at the Primary Auth Service, however the request also failed at Backup Auth Service. Trace ID: REDACTED Correlation ID: REDACTED Timestamp: REDACTED

I can't look at entra id logs though.

[johnstonmatt]

@pmabres as I understand it your approach is just another way to demonstrate a failure to use wildcards, but if you get a good test which works in YOUR_ORG/* and fails elsewhere please ping us again :)
In my experience you can circumvent the form validation, but it doesn't actually take effect as intended

[pmabres]

@johnstonmatt what I wanted to say with my comment is that whilst there is a preview API to create flexible validation with OIDC. It fails (with HTTP 500) when we issue tokens. I assume that login through azure cli is not yet supported when we use user-assigned identities alongside the preview API

[petrsx]

One way is to configure the GitHub Organization to actually allow access to all repositories with a specific owner

https://docs.github.com/en/actions/reference/security/oidc#example-allowing-access-to-all-repositories-with-a-specific-owner

And here example, i haven't tested that (only for any branch):

gh api \
  --method PUT \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  /orgs/ORG/actions/oidc/customization/sub \
  -F use_default=false \
  --input - <<< '{
  "include_claim_keys": [
    "repository_owner"
  ]
}'

based on:

https://docs.github.com/en/rest/actions/oidc?apiVersion=2022-11-28#set-the-customization-template-for-an-oidc-subject-claim-for-an-organization

[adamrlynch]

FWIW I acheived this by using the generic OIDC issuer on the Azure side rather than the built-in GitHub Actions one and was able to make the claim a wildcard. Now every repo works but just passing the client-id, tenant-id, and subscription-id to the Azure Login action