AutoSys Web Services (AEWS) Compatibility and Requirements for Browser Local Network Access (LNA) Restrictions

Products

• Autosys Workload Automation

Issue/Introduction

Organizations deploying or preparing for the enforcement of Local Network Access (LNA) restrictions in modern Chromium-based browsers (such as Microsoft Edge and Google Chrome version 152) require attestation regarding AutoSys Web Services (AEWS) API and Web UI readiness.

LNA restrictions block web applications hosted on public network origins from accessing private network resources without explicit user or administrative permission to mitigate cross-site request forgery (CSRF) and local network fingerprinting risks. Users need to know if any code modifications or backend server configuration changes are required for AutoSys 24.2 to support these browser updates.

Environment

AutoSys Workload Automation / AutoSys Web Services (AEWS) 24.x

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

Resolution

Based on an engineering review of the AutoSys Web Services (AEWS) codebase, no direct code modifications or backend changes are required within the core AEWS application components. The Java WebServices backend is inherently compatible with the browser LNA architectural framework.

Additional Information

Core Architectural Assessment

1. Backend Isolation from LNA Enforcements: The AEWS codebase contains a backend Java REST API (built with JAX-RS/Jersey). It does not generate or serve client-side, browser-executed code (such as dynamic HTML or inline JavaScript fetch() / XMLHttpRequest blocks) that initiates outward network tracking. LNA restrictions apply strictly to connections executed inside a web browser interface; server-to-server or Java HTTP client integrations are completely unaffected.

2. Elimination of PNA CORS Preflight Requirements: Older, deprecated Private Network Access (PNA) specifications mandated backend servers to evaluate and respond to specialized CORS preflight requests utilizing Access-Control-Allow-Private-Network: true headers. Because modern LNA architecture replaces this mechanism by delegating access to explicit browser permission prompts rather than mandatory server-side opt-ins, the AEWS Java backend does not need to be updated to inject LNA-specific HTTP response headers.

Indirect Integration & Infrastructure Considerations

While the backend application layer remains fully compatible without change, network administrators and frontend applications consuming the AEWS API must ensure the following baseline conditions are met:

1. Custom/Third-Party Frontend Web Applications: If you host a separate, standalone web application on a public network origin that invokes AJAX or Fetch requests targeting the internal AEWS API endpoint:

   • The frontend application must be securely served over HTTPS.

   • The frontend application may need to explicitly annotate its calling scripts with targetAddressSpace: 'local' if it connects to AEWS via a public domain name resolving to a local or private IP address literal.

   • The client-side application layer should implement the Permissions API (navigator.permissions.query({ name: "local-network-access" })) to gracefully handle the browser permission requests.

2. HTTPS Enforcement and Mixed Content Control: If a public HTTPS-secured interface calls the AEWS API, the browser will drop the request as "Mixed Content" if AEWS operates strictly over non-secure HTTP (unless navigating via a .local domain name or a private IP literal). If endpoints are reached using regular Fully Qualified Domain Names (FQDNs), administrators must ensure that the underlying servlet container (e.g., Apache Tomcat) hosting AEWS is configured to support HTTPS. This represents an infrastructure deployment standard, not an application code bug or change.

3. Flexible CORS Administration: Standard Cross-Origin Resource Sharing (CORS) rules and headers (e.g., Access-Control-Allow-Origin) remain mandatory if external domains communicate with AEWS cross-origin. AutoSys 24.2 features a flexible filtering mechanism (CustomResponseHeaderFilters configured within the application's web.xml), enabling system administrators to dynamically inject custom HTTP response headers at the network or application layer without altering the underlying Java architecture.

Suggested Next Steps / Related Queries

• Verify that your internal corporate enterprise browser policies leverage LocalNetworkAccessAllowedForUrls to pre-approve internal application origins if explicit, user-facing browser prompts must be bypassed.

• Inspect the web.xml structure within the Tomcat deployment directory to customize CORS headers if external web portals are designated to aggregate data directly from the AEWS REST API endpoints.

 

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.