In 2018, I wrote a fun blog post with some general tips on strategizing Oracle Cloud security. It stemmed from a situation that my colleagues encountered, which helped me rethink the experience for those folks both transitioning from on-prem Hyperion Planning and those net new to Oracle Planning Cloud. In a word, Oracle Planning security is…complex…and in both on-prem and Cloud. There are a lot of scenarios you have to think through and even the most seasoned Planning consultants may occasionally stumble.

For those coming from the Hyperion Planning world, security has evolved in several ways in the Cloud. Some things are the same, some things have changed, and some things are brand new.

For those new to Oracle Planning Cloud…well, read on and be patient. It might seem intimidating at first, but it will make sense the further you get into it. Designing and maintaining security is an essential job function. You can’t live with it, and you can’t live without it. If you don’t have an implementation partner to help you navigate the ropes, get your hands on as many resources as possible. You have a big task ahead of you, and it’s especially critical to get this piece right if you’re storing sensitive data in your new Planning application, which, by the way, is now on Cloud (and most likely public Cloud).

For those of you who read all of those generic tips in the last post, you might be thinking “but how do I design security for Planning Cloud specifically?” Onward with this part II! This blog post will focus on those high-level differences between on-prem and Cloud, new Cloud rules that you should be aware of, new Cloud scenarios that you didn’t have in on-prem, and the various layers of security that need to be thought through for Oracle Planning Cloud.

Caveat: the following tips relate only to Oracle Planning Cloud (which is inclusive of PBCS and EPBCS). Because FCCS is on the same code line, most of these tips extend to that technology as well.

Goodbye, Shared Services

The first thing to know about Oracle Planning Cloud security is to remove any loyalty you have for Shared Services. Shared Services was in the on-prem Hyperion Planning world and has been replaced by a new Cloud security system. In some ways Cloud Planning security is simpler, and in some ways it’s more complex.

In the Cloud version if you’re not using SSO (single sign-on), users must be imported into a separate site called My Services first. Some side notes: users can be bulk imported, the email address is the unique key, and users should be assigned a minimum of 1 Planning Cloud role in order to access the Planning application.

What about groups? Network groups are handled through SSO. Native Oracle Planning Cloud groups will be created later within the Planning application itself. Way more on that in a later post.

But you should be using SSO. More on that later.

Oracle BI Cloud Security != Oracle EPM Cloud Security

The next thing to know is that Oracle BI Cloud and Oracle EPM Cloud are not the same when it comes to designing and implementing security. Oracle BI Cloud has very different licensing models and their security model seems to evolve every year. It is now called IDCS (IDentity Cloud Service), and it also allows for SSO.

Therefore, if you bought both E/PBCS and OAC, well…you’re going to need another learning curve for OAC security. OAC has not had the benefit of 4 years of life yet, so they are still refining and improving the security offerings there.

Yes, SSO is possible!

Life will be so much easier if you enable SSO. And for security reasons, you really need to enable SSO to ensure your Cloud environment is extra secure. For EPM Cloud, make sure to read the extensive online Oracle documentation and get your network security experts involved, as there are some nuances and caveats.

Users Will be Notified Once They’re Granted Access

Before we go into it, note that notifications can be turned off in a system-wide way. However, depending on which security model you’re going with (SSO vs. native), you may not want to do this.

Once users are added to Oracle Cloud, they will be sent a notification via the email address used for them. This lets them know that they’ve been granted access to Oracle Cloud. Once users are given an application role to Planning, they will be sent another email alerting them that they now have access to Planning specifically. Keep this in mind. If you don’t want your users getting spammed with emails from Oracle that they don’t understand, then the timing of your security set-up is crucial here.

User Passwords

Public Cloud is public. This means that extra security protocols are necessary. When native users are first added to Cloud, they receive a temporary password through email and are asked to login and change it ASAP.

Native users (not SSO) will be required by Oracle to change their password once every 120 days by default. This is necessary. There are also many rules regarding what the password needs to look like and how which past passwords you can recycle.

If you’re using SSO, your network security protocols override Oracle’s security protocols.

Test Security != Prod Security

Don’t forget that you get two instances with your new Planning Cloud pod. (A “pod” is one licensed environment, and it comes with Test and Prod instances.) When you go to set up security, some customers set this up in Prod only. Then, when they make changes in Test, they only migrate development in piecemeal after the initial Go Live to keep security intact in Prod. There are actually several options for how to handle the different security between Test and Prod. Think through which path you want to follow, document the process, and practice it to avoid any snafus with security and sensitive data.

Security Exists at Multiple Levels

Beyond just getting a user added to the environment, you also need to secure roles, data, and application objects. This is the hard part and it requires good preparation and knowledge of your Planning application design and data. Be prepared to think through groups and access rights for the following:

• Cloud roles – for users added to the Oracle Cloud environment (the first step)
• Application roles – for users added to the Planning application (application-level roles)
• Dimensional security – how your data is secured
• Workflow/Approvals (if used)
• Data Integration (if used)
• Object security (the following, at a minimum, need to be secured):
  • Forms & form folders (if used)
  • Business rules & business rule folders (if used)
  • Financial Reporting reports & report folders (if used)
  • Task lists (if used)
  • Navigation flows (if used)
  • Dashboards (if used)
  • Infolets (if used)

More Features = More Security

Oracle Planning Cloud has advanced since it was originally released nearly 5 years ago. New features = new security. Case in point, the following features didn’t exist at initial release:

• Navigation flows
• Infolets

In addition, it’s rumored that security might also be added to:

• Valid intersections

Therefore, as new features are released and as existing features are modified, it’s important to pay attention to whether or not they need to be added into your security design and then implemented.

Workforce Intragration is not just a Misspelled Term

If you’re using EPBCS with frameworks, security design can get more complicated. Security is centralized across the single EPBCS application per instance and, therefore, intra-related due to the frameworks.

What this means is that if you have both the Financials and Workforce frameworks enabled, you’re now sharing the same dimensional security across both sets of cubes, which could be problematic. Your financial users’ entity access may not apply appropriately to the Workforce framework and vice versa. Just because user A can see employee salaries for Entity Canada doesn’t mean that they should be able to see all financial data for Entity Canada.

Security can become complex here fast and it’s important to have a good plan (which may include buying a separate instance just for Workforce). There are pros and cons to having Workforce standalone and there are pros and cons to having Workforce included with the other frameworks. …And, very importantly, there are ramifications to both situations that you may not have had to deal with in the on-prem Planning world. Get your hands on resources and/or ask your Planning Cloud friends for guidance. The ramifications may have downstream impacts to data integration and reporting.

Integration = More Security

Once you expand beyond the Oracle Planning Cloud world to other Oracle EPM and BI products, those new integration points will also have to be secured through the other products. Oracle has does a decent job with Cloud pass through security with some of the go-between products, but it’s still a work in progress. Your entire security model should be dynamic enough to evolve with add-on solutions.

Summary

Now that you understand the basics of Cloud security and the many layers of Oracle Planning Cloud security, it’s time to come up with a real, tactical design. Stay tuned for a future post on this topic!