- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2016 02:34 PM
Currently, we have our environment setup to use IP Address Access Control to only allow users that are on our network. We would like to open up our environment so people can get to it from anywhere, but if they are not on our network, it would require multi-factor authentication.
To do this, we were thinking:
1. Disable IP Address Access Control
2. Setup Muti-SSO and force all regular accounts to use this. We would then setup our SSO provider to force multi-factor authentication if the person was coming from an IP outside of our network.
3. Setup Multifactor Authentication and force the admin accounts to always use that.
The above would take care of everything but one account. We have an account that is used to make web-service calls to ServiceNow to create incidents from a third-party scheduling tool. Does anyone know a way to restrict it so this one account can only be used if the call is originating from our network IP? If not, that leaves this account open to a simple username/password guess from anywhere in the world. We can't setup this account as multi-factor since it is used for integration from one system to another. This account would only be used for calls between third-party systems and ServiceNow, within our network.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-24-2016 01:07 PM
The solution that appears to work for this is:
1. Put in logic in an Installation Exit to evaluate the IP of the client. This logic takes care of all interactive logins. In the Installation Exit, the following code can be used to determine the IP of the user trying to connect:
var clientIP = gs.getSession().getClientIP().toString();
2. Put in logic in the BasicAuth script include to evaluate the IP of the client. This logic takes care of things like ODBC connections and SOAP calls. In the script include, the following code can be used to determine the IP of the user trying to connect:
var clientIP = GlideTransaction.get().getRemoteAddr().toString();

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2016 04:10 PM
Hi Brad,
If you go to your Installation Exits module and find the one being used for your SSO solution, you can then just add a preliminary bit of code to check whether the user is that particular integration user when the IP is outside your range, and then fail the login without actual submission for authentication if it is.
e.g.,
if(gs.getUserID() == <web-service user sys_id>){
//(return some failure code and exit the function)
}
That should do it. I do something similar to disallow AD users from logging into the instance if an instance account does not already exist for them... we don't import all AD users into the portal, but once AD integration is setup a valid authentication will let them in and create an account automatically OOB, unless you stop it.
Thanks,
-Brian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2016 07:33 AM
Thanks. That gets us what we need.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2016 10:55 AM
Brian,
Further testing proves that this doesn't work. We have modified our MutliSSOLogin and put in code that prevents people from logging in if they are not on our IP. However, apparently web service calls do not hit this code. The same user who is unable to log in via the login screen is still able to make web service calls. We have also found that that user is also able to connect via ODBC. This user is not setup to use SSO, and has a password in the ServiceNow. Any thoughts?
Brad

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-18-2016 12:22 AM
Hi Brad,
I'm not sure how/where the Web Services authentication is handled or whether you can intercept it in the same fashion. But I would venture a guess that the web service call comes in through the ECC Queue [ecc_queue] to be processed. If that's the case, you could setup a BR to check any entries created by that particular user and verify that the source/from_host is within your network... if not, you could abort the record insert to the queue.
Just a thought, I don't have a current setup to test it with,.
-Brian