Skip to main content
These values were printed by infra/entra-deployment-{env}.sh (see Deployment → Entra app registrations). App IDs and the tenant ID are identifiers, not secrets. They stay the same on redeploy because the script matches registrations by uniqueName. Publisher tenant ID (both environments): ed5c1757-0275-4beb-a5ea-072c938da4e2

dev

Customer tenant admin consent (sent by the onboarding flow):

prod

Customer tenant admin consent (sent by the onboarding flow):

Registration settings

What infra/entra.bicep configures on each registration. The purpose of each app and the credential decision are in README §4.7. Scope and app-role IDs are deterministic (guid() of app, environment and value) and must never change once issued; Graph permission IDs are looked up from the Graph service principal at deploy time, not hard-coded.

Where the values go

The Entra deployment (infra/entra-deployment-{env}.sh / .ps1, also run by deploy.yml) writes these values as AzureAd__* app settings of the environment’s two web apps, merged with their other settings, so App Service needs no manual configuration. Locally, set them as user secrets (below).

Client secrets

In prod, the Valedo and Valedo Marketplace apps have a client secret, stored only in that environment’s Key Vault (Deployment → Client secrets). Dev has none: its apps have no client secrets and uw-kv-valedo-weu-dev holds none. Reference prod secrets from App Service or Functions settings with a versionless Key Vault reference, never copy the value. Example setting value for prod: @Microsoft.KeyVault(SecretUri=https://uw-kv-valedo-weu.vault.azure.net/secrets/valedo-client-secret). The Marketplace app ID goes into Partner Center (technical configuration of the SaaS offer) and into the webhook token validation settings MarketplaceWebhook__TenantId and MarketplaceWebhook__AppId of Valedo.API (set by infra/entra.bicep). The Worker calls the Fulfillment API as this app without a secret: its user-assigned identity {prefix}-id-worker-valedo-… is a federated credential of the app (added by the Entra deployment), and the settings are Marketplace__TenantId, Marketplace__ClientId (written by infra/entra.bicep) and Marketplace__ManagedIdentityClientId (written by infra/modules/functions.bicep). Locally there is no managed identity and dev has no secrets, so the Worker runs its other jobs and Marketplace events wait; to test the Fulfillment calls locally, use an app with a secret in Marketplace__ClientSecret in local.settings.json (never committed). Add the values to the Postman environments and the SPA settings of the portals too.

Local development (user secrets)

Locally, both APIs use the dev registrations from .NET user secrets (UserSecretsId valedo-api and valedo-publisher-api), which override appsettings.Development.json:
Check with dotnet user-secrets list --project <project>.

GitHub deployment identities

Used by .github/workflows/deploy-environment.yml through OpenID Connect; each has one federated credential with subject repo:uab-uniwave@129962912/Valedo@1440127505:environment:{env} and no client secret. The organization issues OIDC subjects with immutable owner and repository IDs, so the plain repo:uab-uniwave/Valedo:… form fails with AADSTS700213. The client IDs are the AZURE_CLIENT_ID and AZURE_INFRA_CLIENT_ID variables of the GitHub environment (Environment variables).