Resolving Ingress Path Shadowing and Custom Route Conflicts in IDSP

Products

• Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

After upgrading the Identity Security Platform (IDSP) to version 4.0.3, you may find that existing custom ingress routes (such as portals, extended services, or customized user interfaces) residing on the same host/URL as IDSP are no longer reachable.

Environment

Platform: Identity Security Platform (IDSP) version 4.0.3+

Cause

In IDSP 4.0.3+, the platform architecture introduces a new centralized routing service (ssp-router).

The Routing Architecture Shift

• Legacy Routing (IDSP < 4.0.3): The IDSP ingress controller only claimed specific, explicit paths (e.g., /admin/, /oauth2/, /identity/), leaving other paths open for custom external resources on the same host.

• New Routing (IDSP 4.0.3+): By default, IDSP deploys a single catch-all ingress with a path of / (root) that intercepts and proxies all incoming traffic directly to the ssp-router service.

Why Custom Routes Get Shadowed

If your custom ingress definitions utilize pathType: ImplementationSpecific with regular expressions (regex) (for example, /common/portal/(.*)), the precedence order between the custom ingress and the new IDSP catch-all / ingress is not guaranteed.

When deploying onto NGINX, OpenShift, or Gateway API controllers, a catch-all root path often overrides or interferes with evaluation-heavy regex paths on the same hostname, rendering your services unreachable.

Resolution

To ensure your custom routes coexist peacefully with the new IDSP routing architecture and remain compatible across NGINX, OpenShift Route, and Gateway API controllers, implement the two-step resolution below.

Step 1: Switch Path Types from Regex to Explicit Types

Modify your custom ingress definitions to use guaranteed precedence matching rather than regex-based routing. Modern ingress controllers enforce a strict "longest matching prefix or exact match wins" rule over catch-all / rules when standard path types are used:

• Prefix Match: Change paths relying on regex wildcards to pathType: Prefix.

• Exact Match: Change direct, static routes to pathType: Exact.

Mapping Examples:

Original Legacy Config	Recommended Config
Path: /common/portal/(.*) Type: ImplementationSpecific	Path: /common/portal Type: Prefix
Path: /status\.txt Type: ImplementationSpecific	Path: /status.txt Type: Exact
Path: /api/v1/otp Type: Exact	Keep as is (guaranteed precedence)

Step 2: Segregate Environments (Best Practice)

For long-term architectural stability, rely on Domain/Hostname Separation rather than path-based multiplexing on a single shared hostname.

1. Host-Based Isolation: Host your custom portals, user interfaces, and extended services on a dedicated domain or subdomain (e.g., portal.example.com) distinct from the core IDSP routing domain (e.g., idp.example.com).

2. Benefits:

   • Fully decouples your lifecycle upgrades from IDSP routing updates.

   • Eliminates ingress routing overlaps across all ingress types (NGINX, OpenShift, Gateway API).

   • Ensures secure, independent TLS profiles and strict DNS/CORS segregation.

Temporary Workaround

If you require immediate restoration of legacy routing behavior during an upgrade window, you can configure the following Helm setting in your deployment configuration:

YAML

 

ssp:
  ingress:
    keepLegacyRoutes: true

⚠️ Warning: The keepLegacyRoutes flag is a migration bridge meant to prevent downtime during initial upgrade phases. It is not a supported long-term solution for future major releases. Plan to transition your custom routes to use Prefix/Exact path matching or dedicated hostnames.