Skip to main content

Hubble Security for EBS

How Hubble Security works with Oracle E-Business Suite

Hubble uses the core ledger security which is available in both 11i and R12. This is supplemented by the use of the GL security rules to further restrict data.

Module Security - Within the Hubble Administrator Application, licenses are assigned to users and this controls the modules a user is able to see when logging into Hubble. Our product does not refer to the function security within Oracle, e.g. the assignment of menu functions to Responsibilities. This would be far too restrictive for our users and has less relevance to the product than the aspects of data security.

Ledger Security - Users logging into our application must enter their Oracle EBS User ID. Our application will then present them with the list of Responsibilities that the specific User ID has access to, and then the user can select one of the available options.

Selection of the Responsibility guides our application to the right data set for that Responsibility and User. This will ensure that the user sees the correct default Set of Books or Ledger. It will also ensure that filters contain the correct GL segment names and calendar details. Approximately 3/4 of Hubble templates follow this security. There are templates in which the Ledger Security is not relevant, e.g. the Procurement Card Master Template. Details of the templates which do and do not adopt this security are included in Appendix: Templates.

Hubble will pick up the Ledger Profile from wherever it is set.

11i - Most often this is set at the Responsibility level and that is where Hubble will find it. However, if there is no Ledger assigned to the Responsibility, Hubble will pick up the first Ledger (Set of Books) it finds from the table GL.GL_LEDGERS.

As default, the Set of Books field in the templates are locked when a user logs in and opens the templates. This lock can be switched off in Configurator. Once this is done, users can select different/ multiple Sets of Books from the pick list. The complete list of Sets of Books held in the instance should be available in the pick list; however, data will only be displayed for Set of Books with the same calendar as the one identified by Hubble when the Responsibility is selected at login.

11i & R12 - As Hubble does not require users to change Responsibilities when they move through our modules, our security defaults to the Ledger (Set of Books) selected when the users first log in. This gives a distinct advantage over Oracle in terms of ease of use as users can seamlessly get to all the information they need with simple, uninterrupted steps.

R12 - Hubble supports Ledger Security via data access sets in R12. The Ledger field in templates is not locked, but the default ledger is preselected. The pick list will show all ledgers included in the access set for that Responsibility. On logging in, Hubble will check for an access set assignment starting at the user level and progressing up to site level, so that it will always find the correct access set.

GL Security Rules

Responsibilities can be assigned to GL security rules. This restricts the data a user can see by GL Segment, e.g. a cost center manager would only see data for his/her cost center. In Oracle this works well in some places but is clumsy in others. For example, the user would only see GL segments he/she has access to in drop-down lists, etc. which works well. But if users want to query a journal which has some lines to which they have access and others to which they don’t, they will only see the journal header information, the lines they have access to and the grand total. This can be confusing, especially for occasional users. In the subledgers such as AP, such users can see all invoices headers but can only see the distributions for the ones to which they have access; again this is confusing for end users.

Hubble honors the GL security rules across the modules. So if a user runs a report in GL, AP, AR, etc., they will only see the transactions which have GL segments relevant to their access.

Organization (ORG)/Operating Unit Security

Hubble recognizes ORG security based on the Operating Unit defined for the selected Responsibility in the profile option MO: Operating Unit. This ORG security is applied in Hubble to AP, AR, PO, FA and PA modules. It is not applied to GL as Oracle itself does not apply ORG security in GL.

Note: Hubble will not find the ORG for the Responsibility if it is set at the site level as a default. It will also not pick up the ORG from the profile option MO: Default Operating Unit.

There are 3 AR templates which do not use ORG security because they do not need it: Aged Activities, Customer Sites, and Customer Accounts.

Multi Org Access Control (MOAC)

This is new functionality introduced in R12 and is designed to help users process and inquire on transactions across multiple operating units, e.g. where they are working in a shared service center. Many organizations will not use this functionality but where they are large multi organizations, they may deploy it in R12. The security does not apply everywhere in Oracle but does apply to specific areas of functionality which would generally be used by a finance shared service center.

Hubble recognizes this security where it has been set up and applies it to all templates that contain operating units. Upon login, Hubble initializes a temporary Oracle table as a list of valid operating units for the user. This list is then referenced by joining it to tables that contain operating units. Inventory organizations are also cross-referenced to operating units and included in multi-org security.

Profile Options in Administrator

There are currently two profile options in Administrator related to security:

  1. EBS Org and Segment Security flag – This enables organizations to switch off the reference to the EBS Org and Segment security for completely open reporting. This is beneficial for consolidation reporting but can cause security concerns for some organizations and should be treated with caution as once it is switched off, it applies to all users accessing the affected Hubble profile.
  2. Allow Expired Users flag – This enables organizations to allow their expired Oracle EBS users to log on. While this can be beneficial in terms of efficient use of Oracle licenses it can again raise security concerns and will require some manual monitoring by the organization to ensure it is not abused. Oracle may request that each disabled user has a database license. Please consult a license specialist if you want to use this option.

Restricting Responsibilities for Explorer and Viewer Users

Normally when users log onto Hubble with their Oracle username, they are presented with a list of all the Responsibilities assigned to them in Oracle. They are then able to select any of those Responsibilities in Hubble and this will govern the data they can see in their Hubble reports.

If you wish to restrict the Responsibilities that Explorer or Viewer users can logon to Hubble with, there are controls which view a profile in Oracle and there you can control a user’s access to Responsibilities.

To restrict the Responsibilities from which a Explorer or Viewer user can select, Hubble now references an additional user-defined profile option for the Responsibility in Oracle. This is an additional configuration of Oracle within System Administration. This feature will only work when the profile option is set up in Oracle. If the profile option does not exist in Oracle, Hubble will work in the normal way. If the profile option is set up, Explorer and Viewer users must have at least one Responsibility which references it or they will not be able to log in to Hubble.

Setting up the Profile Option in Oracle

  1. Select the Application Developer Responsibility.
  2. Navigate to profiles.
  3. Set up a new profile as shown below. A suggested description is “Used to restrict Hubble Explorers and Viewers available responsibilities”. Hubble does not reference the profile (at site or user level).

The code reads as follows:

SQL="SELECT MEANING \"Console User\", LOOKUP_CODE
into :visible_option_value,
:profile_option_value from fnd_lookups
where lookup_type = 'YES_NO'" COLUMN="\"Console User\"(10)"
  1. Save this profile.
  2. Select the System Administrator Responsibility.
  3. Navigate to System profile values.
  4. Check the Responsibility box and specify the Responsibility which should reference the new profile option.
  5. In the find box enter INSIGHT%. This will return the new profile option in the results.
  6. Click Find.

  1. Under Responsibility, change the profile option to YES:
  2. Click Save.
  3. Any users which have this Responsibility assigned will now be able to see this Responsibility in the list when they log onto Hubble.

Using the Responsibility in Hubble

There is no additional setup in Hubble. Our application will automatically reference the new profile option for all Explorer users if it exists in the Oracle instance.

  1. Log in to Hubble as an Explorer user who has Responsibilities referencing the new profile option.
  2. If a user only has one Responsibility referencing the new profile option, he/she will automatically be taken into Hubble without having to select the Responsibility.
  3. If an Explorer user has more than one Responsibility referencing the new profile option, he/she will be presented with a list of those Responsibilities and will be able to select any of them for use in Hubble.
  4. If an Explorer user does not have any Responsibilities which reference the new profile option (but it does exist in Oracle), he/she will not be able to log in.

Important: Troubleshooting: If an Explorer user is not able to log in to Hubble, check if this profile option exists in the Oracle instance and if any of the Responsibilities for the user reference it.

Ledger Set and MOAC Security

These are specific security features for R12.

  1. Ledger Set security (also known as Data Access Sets) allows users to view multiple ledgers where they have access to a set of ledgers within Oracle itself.
  2. MOAC allows users to view multiple operating units where this is enabled within Oracle. There will be some best practice disciplines which need to be applied within EBS to ensure the security for these features works as it should, for example, if a Payables Responsibility has MOAC access, any other module Responsibilities should also have that MOAC access to ensure consistency within the drill downs and navigation between modules within Hubble.

Security Features Not Currently Used By Hubble

The following features within Oracle E-Business Suite are not currently being used by Hubble:

  1. OPSFi Sub Ledger Security - This is a specific piece of EMEA public sector functionality which strips data in the subledgers by business unit. This ensures that transactions entered by a secured department can only be accessed by that department to keep sensitive data safe. This is only used by a very small number of EMEA public sector organizations now. Hubble does not address this security feature.
  2. Role-based Access Control - This is a relatively new security feature but is available for use in both 11i and R12. It groups together function and data security and allows security features such as Responsibilities to be assigned to groups of users rather than single users. As Hubble supports Responsibility security, this should be adequate to cover RBAC security.
  3. Security Groups (specific to Oracle HRMS) - Oracle HRMS has additional security group features but these do not impact Oracle Financials.

Subledger Accounting

The Subledger Accounting Template adopts the general security used by Oracle’s subledger account screens, which includes ignoring the Ledger and Operating Unit Security. This template does provide the ability to report across ledgers, operating units, etc.