Understanding IP Address Collection, Trust Behavior, and Risk Scoring in IDSP

Products

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

Issue/Introduction

Administrators integrating applications with Identity Security Platform (ISP) have observed that the IP address used for policy and risk-based decisions does not always match the IP address reported by the load balancer's X-Forwarded-For (XFF) header. Specifically:

- For applications configured with a "Trusted" client type, an IP address supplied in the authentication request payload can be used for risk scoring and policy evaluation instead of the network-derived (XFF) IP address.
- This raises questions about what qualifies an application for "Trusted" status, whether the network-derived IP is always authoritative for risk scoring, and whether a browser's IP address is captured before redirecting to an external SAML identity provider (such as Siteminder / Access Gateway) for use after the user returns from that provider.

This article clarifies the intended behavior, why it exists, and what administrators should verify in their own environment.

Environment

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

Resolution

1. What determines "Trusted" client status

Every application registered in IDSP is assigned a client type: Public, Confidential, or Trusted. This is an administrator-configured setting made at application registration time in the Admin Console. Trusted status is a general elevated-trust designation — it is not limited to IP address handling and also governs other elevated capabilities for that application (for example, certain identity-assertion flows that do not require presenting a token).

Recommendation: Because Trusted status expands what an application can assert about a request, it should only be granted to first-party, server-side integrations that terminate the actual end-user connection themselves and operate within your organization's own trust boundary. Administrators should periodically review which applications hold Trusted status and confirm each has a documented business/architectural justification.

2. IP address precedence: X-Forwarded-For vs. client-supplied IP

• For any application that is not Trusted, the IP address used for both audit logging and for risk/policy evaluation is always derived from the network path (X-Forwarded-For, or the raw connection as a fallback). Values submitted in the request body are ignored for this purpose.
• For a Trusted application that includes an IP address in its request payload, that value is used for policy and risk-scoring decisions in place of the network-derived IP. The network-derived value is still retained separately for audit purposes but does not feed the risk engine in this case.

The reason this exists: some Trusted integrations (for example, a mobile application's backend, an enterprise API gateway, or a B2B server-to-server integration) call IDSP from their own infrastructure rather than directly from the end user's device. In that architecture, X-Forwarded-For would only ever reflect the integration's own server, not the real end user — so the platform allows a Trusted application to assert the true end-user IP explicitly.

3. IP capture during SAML redirects (e.g., to Siteminder / Access Gateway)

IDSP does not have a mechanism specific to SAML or to Siteminder/Access Gateway for capturing the browser IP "before redirect." Instead, IDSP uses one general-purpose mechanism that applies to every authentication flow (password, SAML, OIDC, etc.): the user's IP address is captured once at the start of the authentication attempt and stored as part of that authentication session's state. This state persists across any redirect to an external identity provider and is available again once the flow resumes after the provider's callback.