Entra Security Architecture
Dual Application Model for Secure Entra ID Integration¶
Authentication against Microsoft Entra ID is intentionally based on a strict two application model that separates interactive operator authentication from privileged service access.
The Helpdesk Portal frontend is registered as an OpenID Connect application and is used exclusively for operator sign-in. It authenticates Helpdesk Agents using delegated permissions and standard OIDC flows. This application never performs privileged operations against Microsoft Graph and never holds permissions that allow directory wide or security sensitive changes.
In addition to the operator-facing application, a separate Azure application registration is required for the Helpdesk Portal worker component. This worker is a non interactive backend service that does not perform operator authentication and never processes operator sign-in tokens. Its sole responsibility is to execute controlled and audited privileged operations against Microsoft Graph.
The worker application authenticates using Workload Identity Federation. This approach deliberately avoids the use of static client secrets for privileged service access and instead relies on short lived federated assertions that are bound to the execution environment and workload identity.
Client ID and client secret credentials do exist within the overall system, but they are strictly limited to OpenID Connect based client authentication for interactive operator sign-in. These credentials are never used for privileged access to Microsoft Graph and are never granted application permissions that allow administrative or directory wide actions.
All privileged Graph operations are executed exclusively by the worker component using Workload Identity Federation. As a result, no long term secrets capable of granting privileged Graph access are stored in configuration files, environment variables, databases, or deployment pipelines.
This architecture enables the use of hardware backed key protection mechanisms, including HSM backed private key materials and managed key stores. Cryptographic keys used for federation and token issuance can be protected by hardware security modules or equivalent managed services, ensuring that private key material is never exposed to the application runtime.
As a consequence, the worker application itself is never in possession of private key material and never gains direct access to cryptographic secrets. All signing operations are performed by secure key providers, preventing key exfiltration even in the event of a full application level compromise.
Authorization for privileged operations is not handled by Microsoft Entra ID application permissions alone. Instead, the Helpdesk Portal implements a fine grained internal authorization layer that governs which actions may be executed against the Microsoft Graph API. This authorization logic is centrally managed within the Heptis Portal and enforced independently of authentication.
This separation is a deliberate security design decision and the primary reason why two distinct application registrations are required when integrating the platform in N3D environments.
Using Workload Identity Federation for the worker component provides significantly stronger security guarantees compared to traditional client ID and client secret authentication, including reduced blast radius, improved compromise resistance, elimination of shared secrets for privileged access, and enforced cryptographic isolation.
Privileged Graph access is strictly limited to the worker application and is only possible via Workload Identity Federation combined with the platform’s internal authorization controls. This ensures that interactive operator authentication and high privilege service operations remain cryptographically, operationally, and conceptually isolated.
This architecture enforces clear trust boundaries, minimizes the impact of credential compromise, and aligns with modern zero trust, least privilege, and key isolation principles.
Protecting Federated Workload Identities¶
Federated Workload Identity Federation establishes a security critical trust relationship between the application and Microsoft Entra ID. Access to Microsoft Graph is based on cryptographically verifiable identity assertions rather than static secrets.
To protect this trust relationship the system applies additional safeguards to ensure that identity related data cannot be modified without detection.
Security Objective¶
The primary objective is to prevent unauthorized use of federated workload identities even in adverse scenarios where parts of the underlying infrastructure are compromised.
The system is designed to ensure that identity context tenant boundaries and configuration bindings remain consistent and trustworthy throughout their lifecycle.
High Level Threat Consideration¶
The design considers scenarios in which attackers may attempt to manipulate stored configuration or identity related data outside of normal application workflows.
Such manipulation must not enable unauthorized authentication token issuance or privileged access.
Integrity Protection Concept¶
To address this risk the system employs a cryptographic integrity validation mechanism that binds persisted identity related information to the runtime security context.
This mechanism allows the application to detect unexpected or unauthorized changes before any security sensitive operation is performed.
Implementation details cryptographic primitives and internal key handling are intentionally not exposed in this document.
Enforcement¶
Integrity validation is enforced at all security relevant boundaries including authentication related processing and access to external services.
If an integrity violation is detected the affected operation is immediately terminated.
Security Guarantees¶
This approach ensures that
- unauthorized modification of identity related data is reliably detected
- manipulated configurations cannot be used to obtain access tokens or privileges
- trust relationships with external identity providers remain intact