Audit Logs Display Server IP instead of Client IP in IDSP

Products

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

Issue/Introduction

In VIP Authentication Hub (IDSP) audit logs, specifically for event factor.me.auth.complete.success, the userIP field reflects the IP address of an intermediate application server (e.g., a white-label login portal) rather than the actual end-user's client IP.

Environment

• Product: Symantec Identity Security Platform (IDSP) / VIP Authentication Hub
• Version: 3.x, 4.x

Cause

This behavior occurs when the VIP Authentication Hub receives requests through a proxy, load balancer, or a server-side "white-label" application. By default, the system logs the immediate source IP of the incoming request. If the intermediate server does not forward the original client IP or if the VIP Authentication Hub is not configured to trust the forwarding headers, the intermediate server's IP is recorded as the userIP.

The provided audit log typically shows:

• userIp: Matches the internal or server-side IP (clientIp).

Resolution

1. Review application metadata
   In the Admin Console / API, check User IpAddress Headers to use (csv) → urn:iam:app:userIpAddressHeaderToUse. Confirm the comma-separated header list and order; IDSP uses the first valid IP in that list and falls back to X-Forwarded-For if none are valid.

2. Ensure headers on the full auth path
   Configure your API gateway, reverse proxy, or calling service so the chosen headers (or X-Forwarded-For) are set on every IDSP call that should carry the end-user context, including factor APIs if your design routes them through the same tier.

3. Align with Initiate Authentication
   Where you use /auth/v1/authenticate, the ipAddress attribute documents “IP from where authentication is initiated” and points to the same custom header guidance; keep body ipAddress and header-based behavior consistent with your architecture.

4. Validate with a controlled test
   From a known client, send a request with a known good custom header or XFF value and confirm userIp (and clientIp if applicable) in the audit event match expectations.

5. Escalate with evidence
   If behavior still disagrees with Custom Headers for End-User IP Address Usage, open a support case with sample audit JSON, relevant app metadata, and a HAR or proxy trace showing headers on the IDSP request.