Authentication and Access¶
The portal signs users in with Microsoft Entra ID and decides what they may see from the catalog: a team sees the sensitive detail of the workloads it owns. This page describes the reference design. Your deployment may differ.
Sign-in¶
Each environment has its own Entra app registration. Users are redirected to Entra ID and the portal matches the signed-in account to a User entity in the catalog.
| Item | Detail |
|---|---|
| Provider | Microsoft (Entra ID), one app registration per environment |
| Delegated permissions | email, offline_access, openid, profile, User.Read, with admin consent |
| Redirect URI | https://<portal-domain>/api/auth/microsoft/handler/frame |
| Users and groups | Read from Entra ID by the catalog (Catalog and entity model) |
| Default resolver | emailMatchingUserEntityAnnotation: the sign-in e-mail must match the e-mail annotation of a User entity |
If no User entity matches, the sign-in fails. A new employee therefore cannot sign in until the next user sync has run.
Provider environment
In the provider's own environment, the portal uses a custom sign-in resolver. It looks up the user by e-mail and then allows the sign-in only for members of a configured set of Entra groups. This is part of the provider's internal tooling and does not apply to a standard environment. See Configuration.
For local development the portal supports a guest sign-in. It is disabled in the production configuration.
Service-to-service access¶
External callers, such as MCP clients, can use a static token configured for the environment, or OAuth. See MCP server.
Access to sensitive detail¶
Access follows ownership. The workload entity has an owner (a team group). A user owns the entities that their groups own. The portal asks the Backstage permission framework before it returns sensitive detail, and a policy answers with a condition: the user must be an owner of the entity.
| Question | Answer |
|---|---|
| Who can see the overview pages (workloads, domains, secure score, compliance score, costs)? | Every signed-in user |
| Who can see the detail of one workload (firewall log lines, gateway blocked requests, security recommendations, per-policy compliance)? | Owners of that workload |
| Do ownership claims include group membership? | Yes: the claims come from the user's sign-in identity, which includes the groups the user is a member of |
| What if the check cannot be evaluated against an entity? | The request is denied |
What is gated¶
The default policy gates exactly four permissions. Everything else is allowed.
| Permission | Protects |
|---|---|
networking.firewall.logs.read |
Azure Firewall log lines of a workload |
azure-network.application-gateway.blocked-requests.read |
Application Gateway blocked requests of a workload |
security-insights.detail.read |
Per-recommendation security detail of a workload |
compliance-insights.detail.read |
Per-policy compliance detail of a workload |
Cost is not gated
Cost data is visible to all signed-in users. The policy does not gate cost, so decide whether that is acceptable before you enable the cost insights.
The same permissions apply when the data is requested through the MCP server or by an agent, because those calls run with the identity of the user.
Status of the design
The decision record for this model is still marked as proposed, although the policy is implemented in the code (Decisions). The broader security and compliance views are described as in progress in the source. Treat the table above as the behaviour of the current code, not as a commitment.
Audit events¶
The service that checks entity access emits an audit event for each check, through the Backstage auditor. The event records whether the access succeeded or failed. Where these events end up (log stream, Application Insights) depends on the logger configuration of the environment. See Operations.