Before you start deploying ILAP Analytics, this page explains what the Bicep templates in Azure.IaC install and why each service is needed, which app registrations are required for authentication, and — most importantly — every permission the installation requires and who needs it. Because these authorizations span Azure resources, Entra ID, SQL, Key Vault, and DNS, organisations with segregated duties will usually need several people or teams working together; the authorization matrix below makes clear who has to do what. It is written for the IT administrator (or team) planning and running an ILAP Analytics installation.
Contents
- What gets installed and why
- Authentication: the app registrations
- Permissions required to install (authorization matrix)
- Working as a team with segregated permissions
- Install from the example first, then secure
- Next steps
What gets installed and why
The main.bicep template deploys the resources below into a single resource group. Unless noted, every resource is created by the deployment.
| Resource (Bicep) | What it is | Why it is required |
|---|---|---|
App Service Plans (AppServicePlan.bicep) |
Three Linux App Service Plans (one each for API, Background Jobs, UI). | Provide the compute that hosts the three applications. Separate plans let you scale each app independently. |
Analytics API App Service (IlapAnalyticsApi.bicep) |
The .NET 8 REST + GraphQL API, with a system-assigned managed identity. | The core service the UI and external reporting tools (Power BI, Fabric) call. Validates Entra ID tokens and reads/writes the database. |
Background Jobs App Service (IlapAnalyticsBackgroundJob.bicep) |
A .NET 8 app that runs Hangfire background jobs, with a system-assigned managed identity. | Runs the heavy asynchronous work — creating/reverting revisions, periodization (time-phasing), archiving, field synchronization, and writing ILAP files — so the API stays responsive. |
Web UI App Service (IlapAnalyticsUi.bicep) |
The React single-page application, hosted on Node.js 24 LTS. | The user interface for planners and administrators. |
SQL Server (SqlServer.bicep) |
An Azure SQL logical server with a system-assigned identity, Entra-ID-only authentication, and the "Allow Azure services" firewall rule. | Hosts the databases. Entra-only authentication means the app managed identities connect without any stored passwords. |
Primary database (Database.bicep) |
An Azure SQL (Hyperscale by default) database. | Stores the live schedule data and the Hangfire job tables. |
Archive database (Database.bicep) |
A second Azure SQL database. | Closed/retired report schedules are moved here to keep the live database lean (controlled by reportScheduleArchiveConfiguration). |
Storage account + ilapfiles container (StorageAccount.bicep) |
A blob storage account with a private (publicAccess: None) container. Only deployed when moveIlapFileToBlobStorage = 'true'. |
Stores ILAP schedule files after processing, instead of keeping them in the database. Deploying this also creates a role assignment (see the matrix below). |
| Managed identities | System-assigned identities on the API, Background Jobs, and SQL Server. | Passwordless authentication to SQL (and to blob storage for the Background Jobs app). No secrets in configuration. |
App Service certificate + custom hostname (CustomDomain.bicep) |
Binds your custom domain and its SSL certificate to each app. Only deployed when useCustomDomain = true. |
Lets you avoid *.azurewebsites.net, which is frequently blocked by corporate firewalls. The certificate is read from Key Vault. |
Two dependencies are not created by the deployment and must exist beforehand:
- Azure Key Vault (
KeyVault.bicepreferences it as existing, and it may live in a different resource group). It supplies the SSL certificate used for custom domains. See Prerequisites for how to create the vault, upload the certificate, and set access. - The two app registrations in Entra ID (see the next section). They are created by hand, not by Bicep.
Optional integration: operation-completion notifications can publish to an Azure Event Hub (
operationCompletionNotificationConfig/eventhubConfig). The Event Hub is not created by this deployment — see the Event Hub guides in this folder if you enable it.
Authentication: the app registrations
ILAP Analytics authenticates users and applications with Microsoft Entra ID, so two app registrations must be created before deployment (full walkthrough: Application Registrations):
- API app registration — defines the audience the API validates tokens against (
azureAd.audience/clientId), exposes the API scopes (via Expose an API), and declares the three application roles that authorize access:DataReader(Readers) — read only; typically used by Power BI and other reporting tools.DataWriter(Writers) — read and publish data.Administrator(Admins) — full access, including configuration and metadata management.- The Readers and Writers roles allow application members (app-only/managed-identity tokens), not just users — needed for service integrations.
- UI app registration — used for interactive user sign-in from the single-page app: its client ID, redirect URI, and the API scopes it requests are set in
publicConfigurations. The same UI client ID is also used as the Swagger client (SwaggerAzureAdAuthOptions).
Role assignments to individual users and groups (who is a Reader/Writer/Administrator) are done after deployment — see User Permissions.
Permissions required to install (authorization matrix)
The table below lists every authorization the installation touches, derived from the Bicep. Grant least privilege: the roles in the "Required role" column are the minimum for that action.
| # | Installation action | Scope | Required role / authorization | Notes |
|---|---|---|---|---|
| 1 | Create the App Service Plans, the three App Services, SQL Server, both databases, and (optionally) the storage account and blob container | Subscription (preferred) or the target resource group | Contributor | Covers all resource creation in main.bicep. |
| 2 | Create the Storage Blob Data Contributor role assignment for the Background Jobs managed identity | Storage account (or resource group) | Owner or User Access Administrator | Contributor is not sufficient — writing role assignments requires Microsoft.Authorization/roleAssignments/write. Only needed when moveIlapFileToBlobStorage = 'true'. |
| 3 | Register the API and UI app registrations + enterprise applications, expose API scopes, and define app roles | Entra ID tenant | Application Developer (to create) — plus Application Administrator / Cloud Application Administrator if you also manage the enterprise applications or assign app roles | With Privileged Identity Management, the role may need to be activated first. Granting admin consent (if your tenant requires it) needs Privileged Role Administrator or Global Administrator. |
| 4 | Nominate the SQL Server Entra administrator (the sqlServerParams.administrators identity) and run the post-deployment grant script |
SQL Server / databases | The nominated Entra user becomes SQL admin and must sign in to each database (via Entra authentication) to run the grant script | The server is Entra-only (azureADOnlyAuthentication: true); there is no SQL login/password. The grant script creates the app managed identities as database users — see Deploy Azure Resources. |
| 5 | Create/import the SSL certificate into Key Vault and set access policies | Key Vault (may be a separate resource group) | Key Vault Administrator (RBAC) — or Contributor on the vault plus certificate/secret access-policy rights | The vault must exist before deployment. |
| 6 | Grant the "Microsoft Azure App Service" principal Get on Key Vault secrets and certificates |
Key Vault | Done by the Key Vault administrator (access policy or RBAC) | Required so the App Service certificate resource can read the certificate at deploy time. The principal appears as Microsoft Azure App Service (app ID abfa0a7c-a6b6-4736-8310-5855508787cd). Only needed when using custom domains. |
| 7 | Create CNAME DNS records for each custom domain (and any domain-verification records your setup requires) | Your external DNS provider | DNS zone management in your organisation | Only needed when useCustomDomain = true. |
| 8 | Run az deployment group create |
Resource group | At least action #1 (and #2 if blob storage is enabled) | See Deploy Azure Resources. |
Working as a team with segregated permissions
Many organisations do not grant a single person all of the roles above. If that is your situation, plan the installation as a coordinated effort. A typical split of responsibilities:
| Responsibility | Actions from the matrix | Typically owned by |
|---|---|---|
| Create Azure resources | #1, #8 | Cloud / platform team (subscription or RG Contributor) |
| Assign the storage role | #2 | Subscription Owner / governance (User Access Administrator) |
| App registrations & roles | #3 | Identity / Entra ID administrators |
| SQL admin & grant script | #4 | Database administrator (the nominated Entra SQL admin) |
| Key Vault & certificate | #5, #6 | Security / Key Vault owners |
| DNS records | #7 | Network / DNS team |
Agree in advance who holds each role, and sequence the work: prerequisites (Key Vault, certificate, DNS, app registrations) must be in place before the resource deployment, and the SQL grant script is run immediately after it.
Install from the example first, then secure
Deploy ILAP Analytics using the example parameters in its default, publicly reachable configuration first, verify that it works, and only then lock it down. The Bicep defaults are already the right baseline for this: SQL Server has publicNetworkAccess: 'Enabled', and the apps use public endpoints, so a first deployment is reachable for verification.
Recommended sequence:
- Complete the Prerequisites and Application Registrations.
- Fill in the Bicep parameters from the sample file and deploy the resources (including the SQL grant script).
- Install the applications.
- Run the Checklist after deployment to confirm the API, background jobs, GraphQL, UI, and time-phasing are all healthy.
- Only after that baseline is verified, apply the hardening in Securing ILAP Analytics — virtual network integration, private endpoints, an Application Gateway, and disabling public network access.
Why this order: private networking and firewall lock-down make failures much harder to diagnose. Verifying a known-good, publicly reachable installation first isolates installation problems from network problems, so that when you later restrict access you already know the application itself works.
Next steps
Continue with the Prerequisites, then work through the New Customer installation steps in order. For how the components communicate and the ports involved, see Communication Edge.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article