EEM - Prepare Web Applications for Edge and Chrome LNA Restrictions

Products

• Autosys Workload Automation

Issue/Introduction

Organizations preparing for the rollout of browser-enforced Local Network Access (LNA) restrictions (coming in Microsoft Edge and Google Chrome version 152) require attestation regarding the readiness of CA Embedded Entitlements Manager (EEM).

Modern Chromium-based browsers are implementing LNA restrictions to prevent web applications hosted on public network origins from interacting with internal, private network resources without explicit permissions. This security control mitigates risks associated with cross-site request forgery (CSRF) and local network fingerprinting. Users need confirmation on whether any configuration updates are required for EEM servers or URLs to remain compliant and fully operational after these browser security policies take effect.

Environment

Embedded Entitlements Manager (EEM) 12.7.2.0 and later

Chromium-based Browsers (Google Chrome, Microsoft Edge, Mozilla Firefox)

Resolution

A comprehensive security review of CA Embedded Entitlements Manager (EEM) has confirmed that EEM is not impacted by browser-level LNA restrictions. No server configuration changes, code modifications, or URL parameter adaptations are required for EEM hosts or services.

EEM remains inherently secure and unaffected by these changes due to the following structural and architectural design choices:

1. Same-Origin Architecture: LNA restrictions are only triggered when a web application residing on a public network origin attempts a cross-origin connection to a private network resource. The EEM Web User Interface (UI) is served directly by its own built-in application web server (iGateway), ensuring that all browser-to-server communications strictly reside on the identical origin boundary.

2. Internal Server-Side Communication: The backend iGateway framework communicates directly with the local EEM identity daemon via internal, server-side system calls. The client web browser has no direct execution path, involvement, or network visibility into this underlying loop. Architecturally, this is treated equivalent to an internal application server communicating with a localized database.

3. Mandatory HTTPS Enforcement: Out of the box, EEM is configured to serve all application content over secure TLS/HTTPS channels and natively redirects unencrypted HTTP traffic. LNA's stricter execution and blocking metrics primarily target unencrypted HTTP local traffic, which does not apply to default EEM communication paths.

4. Robust Out-of-the-Box Security Headers: EEM’s iGateway container natively injects a comprehensive suite of security headers into its responses, including Strict-Transport-Security (HSTS), X-Frame-Options, and X-Content-Security-Policy, preventing cross-site boundary exploitation.

5. Backend-Driven Single Sign-On (SSO): All advanced authentication processes, including SAML and OIDC metadata exchanges, are handled purely server-to-server via backend application layers. The browser is only utilized to pass standard, top-level HTTP redirects, which are explicitly exempted from LNA cross-origin block conditions.

Suggested Next Steps / Related Queries

• Validate that your specific network architecture routes users directly to the iGateway endpoint under a unified origin, avoiding split-domain frontends.

• If your organization utilizes a centralized corporate browser policy, verify that internal application roots are documented for compliance reporting without needing to apply the LocalNetworkAccessAllowedForUrls administrative policy specifically for EEM.

Additional Information

To speak with a customer representative or a Support Engineer see Contact Support. Scroll to the bottom of the page and click on the respective region.