IP Address Whitelisting in Oracle Identity Cloud Service

Introduction

Oracle IDCS (Identity Cloud Service) supports restricting access to applications based on the user IP address. Such applications can be the IDCS Console or any application registered by customers in IDCS.

At first sight, restricting access based on the user IP address may lead to the belief that IDCS can only blacklist a set of IP addresses. In other words, IDCS would only be able to block access from a set of well known IP addresses.

That's far from the truth. IDCS can very easily whitelist a set of specific IP addresses while blocking access from everyone else. And this is actually a real use case scenario where a customer wanted to only allow user access to the IDCS Console from within their intranet. This short post shows how to do it.

A related post worth checking is Restrict Access to IDCS UI using Sign-On Policies, written by my colleague Johannes Murmann.

Implementation Design

The use case is accomplished by redefining the "Default Sign-On Policy". As the name says, such policy is the default policy, being applied to all cases when there's no matching policy for the application being requested. Besides, it is the policy that gets automatically applied to IDCS Console application, invoked via /ui/v1/adminconsole and /ui/v1/myconsole.

Out of box, the Default Sign-On Policy has one default rule (which cannot be deleted) granting access to everyone. We need to modify that rule and add a new one. In summary, we'll modify the default rule to only allow access from the intranet, while the newly added one will deny access to everyone else.

Once these rules are defined, it's important to make sure the default rule gets defined as the top-most rule in the policy, to ensure it is evaluated first, as IDCS evaluates rules top to bottom. Otherwise, the new rule would take priority and everyone would be locked out.

At runtime, an incoming request from the intranet will find a match in the default rule and access will be allowed. On the other hand, an incoming request from anywhere else will not find a match in the default rule, but will certainly do in the new rule, and so access will be denied.

An important aspect to know about is that Sign-on rules are typically evaluated when users authenticate (sign on) to IDCS. Existing sessions are not impacted, unless the policy rule requires re-authentication, but this is subject to another post.

Our rules require the definition of two network perimeters, one for the intranet, one for everyone else. It is important to notice that network perimeters can be defined in 3 different ways:

a) As a discrete set of one or more IP addresses;
b) As a range of IP addresses;
c) As IP addresses in IPv4 CIDR notation, which encompasses all IP addresses belonging to a subnet. Of particular utility, we can use the IPv4 CIDR notation to refer to the IP addresses of the entire internet, which is 0.0.0.0/0.

For more information on network perimeters, please check IDCS official documentation.

Notice though that once this is implemented, any access to an application for which no Sign-on policy is defined will be subject to these new rules. As a consequence, make sure to have appropriate policies to other applications to which these new rules are not meant to apply.

When configuring the policy, it is recommended having a different browser session for testing, just to avoid any accidental lockout in case your sign-on policy gets incorrectly configured.

Implementation Steps

At this point, we can make this theory into the following steps for implementing the use case:

1. Define two network perimeters, one for the intranet, one for everyone else.

My Intranet Perimeter

My Intranet Network Perimeter

In "List of IP Addresses", enter the addresses that you want to allow access. You can enter discrete addresses separated by comma, a range of contiguous addresses in the form <initial-address>-<final-address>, or an entire subnet using CIDR notation, like, for example, 10.10.0.1/24, which means all addresses in 10.10.0 subnet.

Anyone Perimeter

Anyone Network Perimeter

0.0.0.0/0 refers to all possible addresses in the whole internet, which we want to deny.

2. Change the "Default Sign-On Rule" of the "Default Sign-On Policy"

Default Sign-on Rule

The "Default Sign-on Rule" allows access to user requests coming from the "My Intranet" network perimeter.

3. Add a new rule to the "Default Sign-On Policy"

Deny Anyone Rule

The "Deny Anyone" rule denies access to user requests coming from the "Anyone" network perimeter.

4. Make sure the "Default Sign-On Rule" has execution priority

Final Default Sign-on Policy

This is crucial, as IDCS evaluates the rules top to bottom. The allowing rule must be defined before the denying rule. If "Deny Anyone" was the first, any requests would be matched and blocked, locking everyone out of IDCS Console at authentication time.

Conclusion

This short post demonstrated how to implement IP Address Whitelisting for IDCS Console by changing the default Sign-on policy. We changed the default rule and added a new one, having each using network perimeters. Of particular importance is the usage of the IPv4 CIDR notation for representing IP addresses of the entire internet. This concept can be easily extended to any other application registered by customers in IDCS as an additional layer in the organization access control posture.