Support for Flexible FIC

[ishan11]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Microsoft has introduced the support for flexible FIC (i.e., wildcards for the subject field)

New or Affected Resource(s)

• azuread_application_federated_identity_credential

Potential Terraform Configuration

I don't think that the terraform configuration will change, the user would pass in a string with a wildcard in the subject argument.

References

• https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-flexible-federated-identity-credentials?tabs=github

[smmckay]

I see a couple problems with automagically treating a subject with a wildcard as a claims matching expression and otherwise using the existing property:

• This is a breaking change for anyone who currently has a * or a ? in their sub claim
• The claims matching language is complex enough that this doesn't cover its full capabilities. For example claims['job_workflow_ref'] eq 'foo-org/bar-repo/.github/workflows/deploy_prod.yml@refs/heads/main' is valid, requires using a claims matching expression (can't get this effect using the existing property), and doesn't contain any wildcards

I propose doing this:

resource azuread_application_federated_identity_credential "example" {
  ...
  claims_matching_expression {
    value = "a valid claims matching expression"
    language_version = 1 // also defaults to 1 if not provided
  }
}

[perlboy]

I agree, making subject dual use is problematic. We probably want to be explicit about what we intend, either subject or claims_matching_expression and make sure they are considered mutually exclusive. @smmckay's suggested introduction of a block is most aligned with our existing implementation which uses a local exec to post json payloads: