Queries on the range of IP addresses that the IDNow Saas Connector uses

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hello Experts,

I have some queries on the range of IP addresses that the IDNow Saas Connector uses.

I have gone through the below document and got the list of IP addresses for our region where our tenant is hosted:

IP Address Allow List | SailPoint Developer Community

Now the question is when we call any API via postman and see the remote IP address it does not match with the list of IP address (https://files.accessiq.sailpoint.com/network/us-east-1/source_ips.yaml).

When we check those IP address via script (that is provided in the above SailPoint documentation we find that those are coming from the same region but does not match with downloaded list of IP addresses)

Basically, we have a custom SaaS connector which will call some API to do its operation, for that reason we will need to whitelist the IP addresses that SailPoint uses to communicate. This whitelisting will happen on the API side.

Can we simply give the list of IP address that we get using below URL? Or is there anything else that we need to do to get full list of IP address that SailPoint SaaS connector uses?

https://files.accessiq.sailpoint.com/network/us-east-1/source_ips.yaml

Regards,
Shekhar Das

2

@shekhardas1825 -

From SailPoint’s perspective, the authoritative source of IP addresses is always the YAML file published for each region (e.g., https://files.accessiq.sailpoint.com/network/us-east-1/source_ips.yaml for US East 1). The short answer is: yes, you typically must whitelist all the IP ranges in that YAML file for your region to ensure SailPoint can communicate successfully.

Why you might see IPs not in the YAML file

  1. Testing from Postman locally
    If you invoke your API via Postman on your local machine, the remote IP in the target application’s logs will be your local IP (or your local network’s outbound IP), not SailPoint’s. That would differ from the addresses you see in the YAML file. In other words, you are not going through the SailPoint SaaS connector in that scenario—you’re calling directly from your local environment.
  2. AWS NAT / ephemeral addresses
    Occasionally, you might see ephemeral IPs in logs if you’re capturing real-time traffic and it’s going through certain AWS gateways. However, from the SailPoint side, those ephemeral IPs should fall within the CIDR blocks published in the YAML. Sometimes you will not see a 1-to-1 match with your logs if you’re only matching single IP addresses rather than checking whether they lie in the published CIDRs.
  3. Multiple data centers / fallback nodes
    In the event of failover or region-level redundancy, the actual IP used could be from a different subnet that still resides in the same region but might differ from a single IP you expected. Again, the published YAML is meant to capture all such possibilities.

Recommended best practices

  1. Whitelist the entire set of CIDRs in the YAML for your tenant’s region. Don’t pick and choose single IP addresses—allow the range.
  2. Regularly check for updates. Those YAML files can change over time if SailPoint expands or alters infrastructure.
  3. Confirm you’re testing from IdentityNow. If you see an IP in your logs that isn’t in the YAML, ensure your calls are actually coming from IdentityNow (for example, using a SailPoint Source/SaaS Connector test) versus your local client or another proxy.

In summary: The only guaranteed set of IP addresses SailPoint will use in IdentityNow (SaaS) is the set published in the YAML for your region. Whitelist those CIDR ranges and you will cover all IP addresses IdentityNow uses to communicate.

3

Thanks @officialamitguptaa for detailed explanation.

I am sure this post will help others as well.

I will share the list of IP addresses that we get via .yaml file and test it.

Once tested successfully will mark this as resolved.

Regards,
Shekhar Das