Location Based Access Control (LBAC) vs IP Whitelisting

Oracle Cloud HCM offers location-based access control features that can allow you to control the user access based on the IP address\ranges. I talked about enabling LBAC in the prior article, and in this article we can review some of the key differences between lbac and traditional IP whitelisting. 

IP Whitelisting offers a list (or range) of IP addresses from which the access is allowed. If you are trying to access Oracle Cloud HCM from an IP address that is not in the whitelist then connection is refused, you can’t even get to the application sign-in page. This is best when you don’t want to expose the application outside the defined perimeter. 

Location Based Access control offers a way to control the access based on a list (or range) of IP addresses. Instead of completely shutting down the access, it gives you the flexibility to pick-n-choose public vs private roles. For example, user may have access to 5 different security roles  (2 public roles + 3 private roles). If the user is accessing the application from an IP address that is not in the lbac list then they will be granted only the 2 public roles. If the user is accessing the application from an IP address that is in the lbac list then they will be granted access to all 5 roles.  Role based access control is always enforced and lbac gives you more flexibility to control the access even further.

Note: As we review the differences, please keep in mind that LBAC is not a replacement for IP whitelisting. Both the methods provide the perimeter defense and depending on your use case one may be more suitable over the other. 

IP Whitelisting LBAC
Implemented at layer(s) above the HCM Application, customer to raise a service request to enable\disable\modify IP whitelisting entitlement. Part of the HCM application itself, customers can do all the setup on their own (using security console).
Role based access control (RBAC) is always enforced. Role based access control (RBAC) is always enforced.
If you are not in the whitelist then you cannot connect (selective access is not allowed). If you are not in the lbac’s approved list of IP addresses then you can still connect but only the public roles are granted (selective access is allowed).

Sign-in page: Application sign-in page is not accessible, end user will see an error

Sign-in page: Application sign-in page will be presented to the end user, lbac is applied after user authenticates successfully.
In this approach, we often see requests for whitelisting URLs such as whitelist HCM, ERP, BI URLs.  LBAC is not tied to a specific URL, instead it’s for the entire application. If you enable LBAC then it applies to all the modules such as HCM, Recruiting, BI, ERP etc. Although you can access the URLs, you have the option to control what access is allowed (or not allowed) outside the network.
IP address or ranges for the whitelisting is maintained by Oracle, you can request changes via service request. Configurations for IP whitelisting are different than LBAC and it does not update\apply to the LBAC setup. IP Address or ranges for the lbac is maintained by customer, security administrators in your team will assist with any changes. Configurations for LBAC are totally different than IP whitelisting, so updates made in LBAC does not update any setup for traditional IP whitelisting. Often times you chose either IP whitelisting or LBAC, not both (although you can have both the methods enabled at the same time).
Not an ideal solution if you are implementing internet facing features such as career site for Oracle Cloud Recruiting as external candidates won’t be able to access the career site. Ideal solution if you are implementing internet facing modules such as career site for Oracle Cloud Recruiting as LBAC can expose only the access required for the career site. Also ideal if you allow new hires to access pre-boarding tasks before their joining date.

 

Good luck with your implementation…