Oracle Fusion SaaS Security with Oracle Analytics Cloud

The question that is often asked is: Can we leverage the same security we already have in Oracle Fusion SaaS (which includes users, duties, roles and security policies) to secure data in Oracle Analytics Cloud (OAC – an Oracle PaaS)? The answer is Yes. To understand better how this is possible, keep reading. This blog follows my previous 2 blog posts about Integrating Oracle SaaS Data into OAC and Creating OAC Data Replication from Oracle SaaS. While the prior posts describe how to load SaaS data into OAC, this blog focuses on how to make OAC inherit Oracle Fusion SaaS security, and therefore avoid the hassle of manually maintaining security setups in multiple places.

Before delving into the details, it is important to differentiate between securing Oracle SaaS data that is flowing over to OAC directly through a Data Set Connection vs the Oracle SaaS data that is replicated into an OAC Data Warehouse, through any of the data copying techniques (Data Sync, Data Replication, Data Flows, or other ETL means).

1. OAC Data Set Connection against Oracle SaaS: This approach leverages the OAC Oracle Application Connection Adapter. It allows authenticating with either a shared admin user or with an end-user login. Choosing to make end-users login with their own Oracle Fusion App credentials automatically enforces their Fusion App security roles and data policies to any reporting that they do against the Fusion App. Therefore, with a Data Set Connection, no additional configuration is necessary to inherit Fusion App security into OAC, since it all kicks in once an end-user logins in with their Fusion credentials.

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

2. OAC Data Warehouse Connection: This approach is querying a replica of the Fusion App data that has been copied over to a data warehouse. Accordingly, the replicated data requires that object and data level security controls be defined in OAC. Luckily, while doing this requires a one-time manual configuration, it relies on whatever security role assignments and data policies are setup in the source Fusion App.

The rest of this blog post elaborates on the second type of connection, and how to make OAC inherit Fusion App security against a data warehouse.

I am going to start my explanation by describing how authentication works and then move on to discuss how to setup authorization for both object security as well as data security.

Authentication:

• OAC Authentication: Depending on how your OAC instance is provisioned, you may be using either the OAC embedded Weblogic server as an Identity Provider or Oracle Identity Cloud Service (IDCS). IDCS foundation is something you already have as part of your OAC subscription (if you have Universal Credits), and you are highly encouraged to start using it, if you haven’t already. You will need to use IDCS as the Identity Provider for OAC to establish Single Sign-On (SSO) with your Fusion App. IDCS is where users, roles, and role assignments are defined. In addition, IDCS serves as a common Identity Provider across multiple Oracle Cloud services, as well as non-Oracle Cloud and on-prem systems that may need to be integrated for user federation and SSO. For the purpose of this blog, the main idea is to enable IDCS to inherit users, roles and role assignments from your Fusion App so they can be shared with OAC.
• Fusion App Authentication: Ideally IDCS is configured as an Identity Provider for the Oracle Fusion App as well. However, there is a good possibility that this is not the case. Many of the Fusion Cloud App subscribers didn’t have IDCS at the time they provisioned their Oracle SaaS apps. Therefore, they ended up using the built-in Fusion App Identity Provider to manage Fusion user accounts. If this sounds familar, there is no need to worry. Below I will elaborate on how the inheritance of security setups from Fusion Apps to OAC is possible in both scenarios.

Authorization: There are 2 different levels of authorizations that need to be configured: Object Level and Data Level Security.

1. Object Level Security: This defines what Catalog objects (dashboards, reports, data visualization projects, etc…) and what subject areas and data models an OAC user has access to, and with what type of permission (such as read-only or editable). To seamlessly make OAC objects secured per Fusion App security, we first identify which Fusion App roles we want to use for the purpose of setting up OAC object permissions. For example, if the Fusion App is HCM, you may want to inherit the HR Specialist, HR Analyst and Payroll Manager roles. Users who have these roles in Fusion will automatically be granted access to corresponding objects in OAC. Such a configuration is a great time saver from a maintenance perspective on the analytics side. Making OAC inherit Fusion App roles and role assignments relies on making IDCS serve as a bridge between Fusion Apps and OAC. This integration looks a little different depending on whether you are using IDCS or the Fusion App as the Identity Provider for the Fusion App. Here is how things work in both of these scenarios:
   • Scenario 1: IDCS is an Identity Provider to OAC only while Fusion App is using its built-in Identify Provider for user management. With this scenario, IDCS is configured to act as a Service Provider for the Fusion App (in other words, Fusion App is the Identity Provider for IDCS.) Passwords continue to be stored and maintained in the Fusion App. Users, roles, and role to user assignments will all be defined in the Fusion App and then synchronized over to IDCS. New creations, updates and inactivation of Fusion App users flow through automatically into IDCS and OAC. This automatic synchronization from Fusion Apps to IDCS happens through Oracle Enterprise Scheduler (ESS) jobs. More details about setting up the synchronizations are available in this oracle doc.
   • Scenario 2: IDCS as Identity Provider to both OAC and Fusion App. In this case user accounts and their passwords are stored and maintained in IDCS. Users may be defined in either IDCS or the Fusion App and synced to the other side. However, Roles and Role Assignments are always defined in the Fusion App, as usual, and synchronized over to IDCS as in Scenario 1.In a nutshell, whether it’s the first or second scenario, Fusion App administrators continue maintaining security in the same way they do prior to activating OAC. There is no overhead required from an ongoing maintenance perspective on their part.
2. Data Level Security: This is what tells OAC which user has access to what subsets of the data. For example, restrict access to information based on Position, Supervisor Hierarchy, or an HCM Payroll list. Like with securing OAC objects, it is highly advisable to tie OAC data level security to the Fusion App Data Security Policies. Invest the time upfront to make a one-time setup and avoid the hassle of dual and complicated maintanance. You would need to first identify the data security objects to secure out of the Fusion app (such as by location, or by Business Unit). Fusion Data Roles combine a user’s job with the data a user accesses (for example, a Country level HR Specialist). The Data Roles are defined in Fusion App security profiles. So we need to make IDCS, and accordingly OAC, inherit the Fusion Data Roles and apply security filters on such roles in the OAC Data Model. For setting up data security in OAC, we need to be aware of the Fusion Public View Objects (PVOs) that provide the user-permitted security data object identifiers (such as the list of departments a logged in user has access to). Once the Fusion source is identified, we then form extraction SQL to load a Data Warehouse side security metadata table inherited from the Fusion App setup. After the warehouse security table is loaded, we then define OAC Session Variables to query the Fusion App PVOs. (Note that unlike OBIEE on-prem, OAC doesn’t support a direct connection to Fusion SaaS ADF PVOs from the OAC Data Model, hence the security session variable initialization blocks need to be defined against Data Warehouse tables. Refer to this Oracle Doc to see if the OAC Data Model supports direct connection to Oracle Applications in later updates.) When initially applying security filters on the inherited data roles in OAC, we mimic the security policies defined in the Fusion App. Note that securing OAC Application Roles by applying data level security filters to OAC Subject Areas may be done either in the OAC Thin Data Modeler or the OAC Client Repository Administration Tool. For more complex data-level security across several Application Roles, the Client Admin Tool offers a better way of defining such filters.

To conclude, integrating Oracle Fusion SaaS Security into OAC is an essential part of a successful Oracle Analytics implementation. Performing a comprehensive security integration with SaaS that covers the various layers including users, objects and data is crucial. The success of the implementation is determined by how secure corporate data is and how feasible it is to avoid the maintenance overhead that would have been necessary without a well-planned and integrated security solution for Oracle SaaS and PaaS.