Access rules are a feature new to administrators in the world of PaaS. But what are they and why do you need to know about them? Are these new “rules files” for Essbase Cloud? (Nope.) Regardless of which area of OAC you’re managing, you’ll need to become familiar with access rules. If you are having trouble talking across services and everything is up and running, access rules may be your answer.

This blog post is intended to give a very high level introduction to access rules and how they fit into the overall spectrum of PaaS security. Note that this post is skewed very much towards OAC and Essbase Cloud, as this is how I stumbled across them. However, the real-life usage is much broader and expands as you look across the entire Oracle PaaS suite of solutions.

What Access Rules Are

In simple terms, access rules control network access to the Cloud products. Because Oracle Cloud is forced to be so secure, many components are locked down by default. Therefore, access rules are an intuitive way (through a simple interface) to allow administrators a way to open up access. This is done by entering a series of required inputs: specifying the source, destination, destination port(s), the type of security protocol, etc.

Access rules may require slightly different fields depending on the PaaS product.

Some access rules are system rules and cannot be changed or disabled. They are configured by the system. Others can be managed by administrators.

Oracle has created at least one Oracle by Example (OBE) access rule tutorial to assist new PaaS customers.

Why You Need Access Rules

To quote my awesome friend Wayne Van Sluys (who has become quite fluent in PaaS security through trial by fire): “Companies need to think about the Cloud as an extension of their corporate network. Data security is paramount and needs serious consideration and planning when moving to the Cloud.”

This is where access rules come in. They are only one component of the overall security design in PaaS. Other design considerations include white listing, VPN access, and more. Administrators will encounter access rules at least once in their duties.

Our team has found it necessary to create and configure multiple access rules in OAC deployments. To help you get a feel for how and why they are used, I’ll walk through an instructional below regarding a practical use case for configuring access rules to Essbase Cloud. This is a common scenario if you plan to use Essbase Cloud with either DV Cloud or BI Cloud in OAC.

Practical Use Case

When you first license OAC, the initial setup and configuration creates a default security design. We quickly realized that this had to be modified in order to get Essbase Cloud to talk to DV/BI Cloud.

Here was how we discovered the issue. We tried creating a connection to Essbase Cloud through DV Cloud, DVD, and BI Cloud. OAC wasn’t having it and we got this not so descriptive error message:

(If you can’t tell, I’m going to mask certain aspects of my screen shots, yet throw in some far-fetched examples to help set the scene. This is public cloud, folks. Don’t be caught displaying identifying information.)

Given the error, we tried every combination of DSN syntax that we could think of: with and without http://, with and without https://, and with and without random ports. We were eventually told that the correct syntax for the DSN is (IP address):(port). However, the ports we tried weren’t working.

So where to go from there? Naturally, I logged an SR. Luckily, the great folks in Oracle Support were able to get back to us quickly on a solution. They directed us to access rules. Since the servers were locked down by default, we were asked to open up some ports to the Essbase Cloud server which would allow the analytics and visualization tools to access it.

To navigate to access rules, go to My Services, the Oracle Analytics Cloud service, the action menu, and Open Service Console:

Then click on your Essbase service:

Now you need to copy down the Public IP address for your Essbase Cloud server. You’ll need this later when you go to setup your Essbase Cloud connection from another OAC tool.

Then in the top action menu next to the Essbase service name, select Access Rules:

This will open up the access rules list attached to this particular Essbase Cloud server (I had to hide a lot of details here).

To create a new access rule, press the Create Rule button:

When you create an access rule for the Essbase Cloud server, you’ll need to populate the fields below prefixed with an asterisk. Oracle Support directed me to create 2 total access rules: one called “Agent” and one called “Server” (although the access rule names can be whatever you want). These open up specific ports to the Essbase Cloud server.

Create the first access rule. Refer to Cloud Support Doc ID 2265410.1 for more specific details. Note the port used for the “Agent” access rule (which is completely made up in the screen shot below):

When the access rule is being created (takes <1 minute), the icon at the top of the screen changes to indicate that an event is in progress:

The icon changes back once the access rule has finished:

Then create the second access rule, which requires a range of ports to be opened:

Finally, check the list of access rules to verify that they have been created correctly and with the appropriate properties:

If you mess up, you have to delete and recreate the access rule. Edits to existing access rules are currently not allowed. Note that you can also temporarily disable or enable existing “default” and “user” access rules.

Now that these access rules have been created, it’s time to recreate that connection to Essbase Cloud. This set of steps is for the OAC-DV Cloud product.

Once logged into DV Cloud, navigate to the Data Sources area. Choose to Create | Connection:

Choose the Oracle Essbase (Beta) option:

Then fill in the connection details using the syntax rules described earlier for the DSN. The IP address is the public Essbase Cloud one noted earlier and the port is the one assigned to the “Agent” access rule.

Just like the access rule fields, the connection fields prefixed with an asterisk are required. An administrator ID should be used. It’s your preference if you wish the user credentials to be saved.

Update August 18, 2016: As discovered by my buddy Ivan Agudelo, the recent 106 OAC patch allows you to enter the above DSN without the port number now. The access rules to open the ports are still required, however.

Once you connect successfully to Essbase Cloud, a confirmation will be received and the new connection will appear in the list:

 

The PaaS world varies greatly from the SaaS world when it comes to management, maintenance, and administration. Check out these great bloggers for more information about how to maintain OAC – more posts coming!

• Glenn Schwartzberg’s Essbase blog
• Robert Gideon’s BI/EPM blog
• Wayne Van Sluys’ Beyond Just Data blog

In addition, interRel’s free Play it Forward YouTube channel has some great OAC videos, with more arriving soon!