fix: Identity provider authentication issue resolved

[PadhiAjit-Microsoft]

Purpose

• This pull request updates the deployment scripts to automatically grant the deploying user the "Container Apps Contributor" role on the resource group. This direct user assignment ensures that Easy Auth's on-behalf listSecrets validation can resolve RBAC when the Microsoft identity provider is added, and avoids issues related to group token overage.

Role assignment automation:

• Added logic to both post_deployment.ps1 (PowerShell) and post_deployment.sh (Bash) scripts to grant the deploying user the "Container Apps Contributor" role directly on the resource group after deployment. This includes checks for required variables and handles cases where the assignment already exists or cannot be created, logging appropriate messages. [1] [2]

Does this introduce a breaking change?

• Yes
• No

Golden Path Validation

• I have tested the primary workflows (the "golden path") to ensure they function correctly without errors.

Deployment Validation

• I have validated the deployment process successfully and all services are running as expected with this change.

What to Check

Verify that the following are valid

• ...

Other Information

[Copilot]

Pull request overview

Updates the post-deployment automation to mitigate an Easy Auth RBAC validation failure when adding the Microsoft identity provider by granting the deploying user a direct (non-group) “Container Apps Contributor” assignment at the resource-group scope.

Changes:

• Add Azure CLI role-assignment creation logic to the Bash post-deployment script.
• Add equivalent role-assignment creation logic to the PowerShell post-deployment script.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
infra/scripts/post_deployment.sh	Adds a non-fatal, idempotent role assignment step for the signed-in user at the resource group scope.
infra/scripts/post_deployment.ps1	Adds the same role assignment step in the PowerShell variant of the post-deployment script.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (4)

infra/scripts/post_deployment.sh:360

• Hard-coding the role definition GUID directly in the az command makes this harder to audit/maintain (it’s not obvious at a glance what that GUID represents, and it’s easy to accidentally change inconsistently between scripts). Consider assigning it to a clearly named variable with an inline comment (or use the role name if you prefer).

  RG_SCOPE="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP"
  set +e  # set -e (top of script) would abort on a non-zero az exit
  ROLE_ERR=$(az role assignment create --assignee-object-id "$DEPLOYER_OBJECT_ID" --assignee-principal-type User \
    --role "358470bc-b998-42bd-ab17-a7e34c199c0f" --scope "$RG_SCOPE" --output none 2>&1)
  ROLE_EC=$?

infra/scripts/post_deployment.ps1:328

• Hard-coding the role definition GUID directly in the az command makes this harder to audit/maintain (it’s not obvious at a glance what that GUID represents, and it’s easy to accidentally change inconsistently between scripts). Consider assigning it to a clearly named variable with an inline comment (or use the role name if you prefer).

    $RgScope = "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP"
    $RoleOutput = az role assignment create --assignee-object-id $DeployerObjectId --assignee-principal-type User `
        --role "358470bc-b998-42bd-ab17-a7e34c199c0f" --scope $RgScope --output none 2>&1

infra/scripts/post_deployment.sh:351

• This block falls back to the CLI subscription only at the end of the script. If SUBSCRIPTION_ID is empty (as the comment suggests can happen), the Portal URLs constructed and printed near the top of the script will still be incorrect/stale. Consider moving the subscription fallback to immediately after reading azd env values so all downstream uses (including the Portal URLs) are consistent.

This issue also appears on line 356 of the same file.

# azd env may not populate AZURE_SUBSCRIPTION_ID in every shell; fall back to the CLI context.
if [ -z "$SUBSCRIPTION_ID" ]; then
  SUBSCRIPTION_ID=$(az account show --query id -o tsv 2>/dev/null || true)
fi

infra/scripts/post_deployment.ps1:323

• This script falls back to the CLI subscription only here at the end. If $SUBSCRIPTION_ID is empty (as the comment suggests can happen), the Portal URLs built earlier in the script will still be incorrect/stale. Consider doing the subscription fallback immediately after reading AZURE_SUBSCRIPTION_ID from azd env so all downstream uses are consistent.

This issue also appears on line 326 of the same file.

# azd env may not populate AZURE_SUBSCRIPTION_ID in every shell; fall back to the CLI context.
if (-not $SUBSCRIPTION_ID) { $SUBSCRIPTION_ID = az account show --query id -o tsv 2>$null }
if (-not $DeployerObjectId -or -not $SUBSCRIPTION_ID -or -not $RESOURCE_GROUP) {