Limit authentication to ServiceNow based on IP Range

[steveo2]

Hi folks,

We have an IP Range that is open in ServiceNow (inbound) that is quite large.  We want to limit access to ServiceNow (interactively and non-interactive) over this IP Range to a user with a certain role.  Wondering if anyone has run into this use case before and has something to try.  We have tried adaptive authentication, however this only works for interactive sessions (users logging into ServiceNow) and not for REST or Web Service calls.  We want to limit exposure over this large IP Range so that only user X (with role Y) can access.

Thanks

[Ravi Chandra_K]

Hello @steveo2 

This can be achieved using IP restriction.

Please refer below support article 

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0818862#:~:text=IP%20restrict....

Please mark this answer as helpful and correct if helped.

Kind Regards,

Ravi Chandra.

[Randheer Singh]

Hi @steveo2 ,
You can use the API access policy feature (Applicable for integration calls) along with the Adaptive Authentication Post-authentication context policy (for interactive sessions) for enforcing contextual IP restrictions.

As the post-authentication policy does not apply for API/non-interactive accesses, we have the API Access Policy feature, using which admins can craft policies to allow REST, Scripted REST, processors and SOAP APIs access based on the IP/location/user criteria and authentication scheme(Basic Auth/OAuth/ID Token/certificate-based auth).

Example use cases:

1. Allow Table REST API access if the request originates from a trusted network and the authentication type is OAuth.

This capability is available from the Rome release onwards

In the Utah release, we have added three significant enhancements.

1. Global Policy Option for REST APIs. A single policy can be applied to all non-public REST APIs (including scripted REST APIs). The global policy can be overridden by a policy defined at the API level. The access policy enforcement prioritization can be referred to here.

2. API access policy option for SOAP and Scripted SOAP APIs. Admins can create an API access policy for SOAP APIs at the individual API level or global level. To create a global policy for SOAP APIs, the admin must add an access processor access policy for SOAPProcessor (available in the Utah release). 

3. Access policy support for non-public processors (like CSV, PDF, XML etc.), RSS processors and JSONv2 processors.

In the Vancouver release, we increased the processors' coverage supported by the API access policy. API access policy will be available to non-public processors from the Vancouver release onwards.

Note: Global API access Policies for REST API and SOAPProcessor can be overridden with an API-specific access policy. Please refer to this documentation to understand the access policy prioritization logic. Using this capability, admin can relax IP restrictions for specific APIs/endpoints. This is helpful in scenarios where you want to allow an API to be called from a cloud application for which the IP address is not fixed and hence, cannot be added as part of the trusted IP range.

Useful Links

Adaptive authentication – Product Doc

API access policy – Product Doc

Adaptive Authentication NowLearning course

Zero trust access NowLearning course

Configuring Adaptive Authentication - example

Platform Privacy and Security Community

[ed475]

Hi Randheer,

I hope you don't mind me throwing an an extra question for this, as it appears on topic for this discussion.

I have an active Post Authentication Context Policy to IP limit access which is working well. However, I have a service account which requires an OAUTH token to connect to a specified API on my instance, and I expected this to fall under non-interacive login and therefore not need to pass the post auth policy. However, this account is unable to connect to /oauth_token.do to issue a token due to failing the post auth policy check.

Is this expected behaviour, and if so does that mean all external service accounts that need OAUTH tokens will need to be included in the post auth context policy in some way (by group, role, or IP)? I expected them to only require configuration using SOAP/REST API Access Policies.

Thanks for any insight you might be able to provide.