Setting up IP address restrictions
Who is this article for?
Administrators seeking information on advanced settings.
Elevated roles that restrict User access and data visibility required.
The platform supports restricting incoming traffic to IP addresses that are part of a pre-defined list. This is typically used to ensure that only traffic from an internal network or corporate VPN will be granted access.
Managing a Whitelist
The Operations team manages the creation or modification of these whitelists of IP addresses.
In certain cases, it may be necessary to allow specific roles to override the subscriber-level IP restrictions. For example, some applications may allow mobile users to connect from outside of their corporate network with access to a limited sub-set of roles. Alternatively, there may be a role that is only granted to users who have access to a specific VPN. To accommodate these cases, set up role-level IP restrictions in the Subscriber Roles screen:
These restrictions are designated on a specific Subscriber Role. When a user logs in, and IP role restrictions are present, they will only be granted access to roles that contain their IP address in their whitelist. (Of course, normal role restrictions still apply, so users will also have access only to those roles that have been granted to them by an Administrator in the Person's screen.)
Consider the following set up of a Subscriber with Role-level IP address restrictions:
Subscriber-level whitelist: 10.15.1.*
| Administrator | Mobile | Participant |
|---|---|---|
| 10.15.1.10 | *.*.*.* | |
| 10.15.1.11 | ||
| 10.15.1.12 |
In this case, the subscriber-level whitelist (which has just one entry) is restricting to an internal corporate VPN (10.15.1.*), The Administrator role is further restricted to only a few addresses in that VPN's range, and the Mobile role is allowing traffic from any address at all. There are no role-level restrictions defined for the Participant role, so they will inherit the subscriber's settings (10.15.1.*).
So as an example, a group of users who had person-level access to all the roles listed, would end up being restricted to the sub-set of roles defined in the table below if they entered from the following IP addresses:
| User | IP Address | Roles |
|---|---|---|
| Alice | 10.15.1.55 | Mobile, Participant |
| Bill | 10.15.1.11 | Administrator, Mobile, Participant |
| Chris | 67.25.19.198 | Mobile |
It is also possible to define IP Restrictions at the User-level, using the same pre-defined groups:
The user-level IP Restrictions are designed to add more restrictions on certain types of users as an additional factor in their authentication.
Some examples include ensuring that users (who may be generic accounts) run only from a restricted IP or range of IPs (for example, a server computer behind a firewall) or ensuring that users that are allowed to login with Username/Password instead of SSO login from a corporate network, which would give them an IP within an allowed range of IPs.
These user-level IP Restrictions are required for Interface-Type users, and also for users who have the "Allow Username/Password" behavior checked in an area where SSO is otherwise forced, although if there are no subscriber-level IP restrictions, choosing a group of 'No IP Restrictions' is an option if no IP Restrictions are desired for that user.