Angular Web Portal reverse proxy path issues when hosted under a subpath (4383527)

When hosting the One Identity Manager Angular Web Portal behind a reverse proxy under a subpath (for example /apiserver), browser refreshes or OAuth callback redirects may incorrectly drop the subpath from the URL.

Example:

Initial access works correctly:

https://server.domain.com/apiserver/html/qer-app-portal/index.html

However, after refresh or redirect, the browser may navigate to:

https://server.domain.com/html/qer-app-portal/index.html

instead of:

https://server.domain.com/apiserver/html/qer-app-portal/index.html

This can result in:

• HTTP 404 errors
• incorrect Angular routing behavior
• failed OAuth callback handling

The issue may appear inconsistently depending on browser, workstation, proxy, or forwarded header handling.

The issue is related to how the Angular Web Portal reconstructs URLs and handles routing when hosted beneath a preserved reverse proxy subpath.

Additional contributing factors may include:

• reverse proxy path rewriting
• inconsistent forwarded header handling
• pathbase interpretation
• URL casing inconsistencies
• browser/client-side routing state

Hosting the Angular portal under a subpath introduces additional complexity for:

• browser refreshes
• deep links
• OAuth redirects
• relative URL resolution

The recommended approach is to host the One Identity API Server directly at the IIS website root instead of beneath a subpath.

Recommended structure:

https://server.domain.com/

instead of:

https://server.domain.com/apiserver/

Additionally:

• Configure the Default HTML Application as qer-app-portal
• Enable reverse proxy mode if required
• Configure AllowedReverseProxies
• Ensure the following forwarded headers are correctly set by the reverse proxy or IIS

Example IIS rewrite/server variable configuration:

<rule name="Set Forwarded Headers">
    <match url="(.*)" />
    <serverVariables>
        <set name="HTTP_X_FORWARDED_HOST" value="server.domain.com" />
        <set name="HTTP_X_FORWARDED_FOR" value="{REMOTE_ADDR}" />
        <set name="HTTP_X_FORWARDED_PROTO" value="https" />
    </serverVariables>
    <action type="None" />
</rule>

Moving the application to the IIS root path resolved the routing and redirect issues in the reported environment.