Financial Services Accounting Hub Security
Financial Services Accounting Hub Security Overview
Oracle Financial Services Accounting Hub uses accounting events generated by subledger applications to create accounting. As the implementation is generic for all applications, the architecture provides a common solution to enforce event security.
Subledger journal entries fall between the subledger applications and General Ledger. There are requirements to secure creation and inquiry of subledger journal entries and lines according to the following mechanisms:
The table below describes how the different security types are enforced in General Ledger and the Financial Services Accounting Hub.
| Application | Transaction Security | Flexfield Security Rules | Transaction Security |
|---|---|---|---|
| General Ledger | Enforced by the Financial Services Accounting Hub inquiries (drilldown) and reports if the profile option SLA: Enabled Subledger Transaction Security in GL is set to Yes and the subledger application owning the transaction supports multiple operating units. | Always enforced by Financial Services Accounting Hub inquiries and reports. | Always enforced by Financial Services Accounting Hub inquiries and reports. |
| Subledger Application | Enforced by the Create Accounting program and the Financial Services Accounting Hub inquiries and reports if the subledger application provides a security policy. | Always enforced by manual journal entries and the Financial Services Accounting Hub inquiries and reports. | Enforced by the Create Accounting program, manual journal entries, and Financial Services Accounting Hub inquiries and reports if the profile option SLA: Enable Data Access Set Security in Subledgers is set to Yes. |
Transaction Security
Transaction security refers to the way in which subledger transactions are secured. Subledger transactions are secured in different ways depending on the subledger application as in the following examples:
-
In Payables and Receivables, the operating unit is used to secure transactions.
-
Assets transactions are secured by asset book.
-
Payroll transactions are secured by an HR specific security profile option.
Transaction Security Overview
The Financial Services Accounting Hub implements transaction security by securing the accounting events.
The Financial Services Accounting Hub secures events by storing the security context of the transaction to which the event belongs. For example, if a transaction is secured by operating unit, events created for the transaction include operating unit data. Events therefore inherit the security of their source transactions.
Once event security is established for a subledger application, access from a subledger responsibility to the application's accounting events to view them, create accounting, or view the event's journal entries are limited by the security model of that application.
Example: Payables secures invoices by operating unit. For a customer using Payables, assume the following setup for transaction data that is described in the table below.
| Operating Unit | Invoice Number |
|---|---|
| North East | INV-101 |
| North West | INV-102 |
A user without granted access to operating unit North West is not allowed to view accounting events, create accounting, or view accounting for INV-102. Similarly, a user with no access to operating unit North East is not allowed to view accounting events, create accounting, or view accounting for INV-101.
General Ledger responsibilities can view journal entries and balances in General Ledger independent of transaction security. However, drilldown through the Financial Services Accounting Hub optionally enforces transaction security. The profile option SLA: Enable Subledger Transaction Security in GL determines whether transaction security is applied.
-
If the option is set to No for a General Ledger responsibility, inquiries and reports are not restricted by transaction security.
-
If the option is set to Yes for a General Ledger responsibility, inquiries and reports are restricted by transaction security.
See: SLA: Enable Subledger Transaction Security in GL, Oracle Subledger Accounting Implementation Guide
Transaction Security Implementation
The Financial Services Accounting Hub supports transaction security through the standard security mechanisms supported by Oracle Applications.
When registering your application with the Financial Services Accounting Hub in the Subledger Applications window, choose whether to use transaction security. If the subledger is set to enforce transaction security, then you are prompted to enter a policy function to be used in enforcing the security. This policy function must return the needed predicate (a string added to a WHERE clause in DML operations) that restricts the data that can be accessed on the secured objects.
If the subledger is not set to enforce transaction security, the Financial Services Accounting Hub automatically attaches a default policy that makes every rule accessible for the DML operations.
Information for events is implemented in the table. For every event that is created, the transaction security information, including the security context, is stored in the XLA_TRANSACTION_ENTITIES table. This table serves as a base object for event security in the XLA schema.
The table below lists the columns in the XLA_TRANSACTION_ENTITIES table that stores the security context for events.
| Col. Number | Security Context Columns | Data Type |
|---|---|---|
| 1 | Security_id_int_1 | INTEGER |
| 2 | Security_id_int_2 | INTEGER |
| 3 | security_id_int_3 | INTEGER |
| 4 | security_id_char_1 | VARCHAR2(30) |
| 5 | security_id_char_2 | VARCHAR2(30) |
| 6 | security_id_char_3 | VARCHAR2(30) |
| 7 | valuation_method | VARCHAR2(30) |
To implement transaction security on accounting events, perform the following steps:
Define a Policy Function
As the security rules implied on a transaction are passed to the transaction's accounting events, the responsibility of defining security for events lie with the subledger applications implementing the Financial Services Accounting Hub.
Security for the events in a subledger is defined through the use of a Policy Function. This function returns the needed predicate (a string added to a WHERE clause in DML operations) that can be used to secure the data in a table.
Note: Functions should be written following the standards for application security policies given in Overview of Functions and Menu Security, Oracle Applications Developer's Guide.
Consider the following example of a policy function. Assume that Oracle Receivables implements the uptake of the Financial Services Accounting Hub and wants to implement transaction security on its accounting events. As Receivables secures its transactions using ORG_ID, it chooses to use the SECURITY_ID_INT_1 column to store its ORG_ID information when it creates its accounting events.
The security policy function could be as follows:
CREATE OR REPLACE PAKCAGE ar_security_pkg AS
FUNCTION ar_policy
(obj_schema VARCHAR2
,obj_name VARCHAR2) RETURN VARCHAR2
END ar_security_pkg;
/
CREATE OR REPLACE PACKAGE BODY ar_security_pkg as
FUNCTION ar_policy
(obj_schema VARCHAR2
,obj_name VARCHAR2) RETURN VARCHAR2 IS
BEGIN
RETURN 'EXISTS
(SELECT 1
FROM mo_glob_org_access_tmp oa
WHERE oa.organization_id =
xla_transaction_entities.security_id_int_1)';
END ar_policy;
END ar_security_pkg;
Whenever this policy function is active on the table, the function returns a predicate that is appended to all DML statements (Select, Update, and Delete) that are issued on the table XLA_TRANSACTION_ENTITIES.
In the example, a simple sql statement like:
SELECT *
from XLA_TRANSACTION_ENTITIES;
is now executed as:
SELECT *
from XLA_TRANSACTION_ENTITIES
WHERE EXISTS
(SELECT 1
FROM mo_glob_org_access_tmp oa
Register Policy Functions in the Accounting Methods Builder
Transaction security in the Financial Services Accounting Hub is implemented in the Transaction Security Options region of the Subledger Applications window.
See: Registering Subledger Applications
In the Event Security Options region of the Subledger Application window, select the appropriate option.
-
If the application implements transaction security, select Use Security.
-
If Use Security is selected, enter the name of the transaction in the Policy Function field.
The Policy Function field is required if Use Security is selected. As the field has no validation, ensure that the value entered in this field corresponds to a valid function.
Flexfield Security Rules
Flexfield security rules are owned by the Application Object Library and enable users to restrict access to Accounting Flexfield segment values by responsibility. If users have access to the underlying subledger transactions, they should also have access to the Accounting Flexfield segments stored in the transaction data model. Therefore, the Financial Services Accounting Hub does not validate whether the Accounting Flexfields stored in the transaction objects and used by the Accounting Program are consistent with flexfield security rules.
The following features implement flexfield security rules:
-
Manual subledger journal entries
-
Inquiries of subledger journal entry headers and lines
-
Financial Services Accounting Hub reports
For Accounting Flexfield Security, no distinction is made between general ledger and subledger responsibilities in terms of security. Whether an inquiry is performed from a general ledger or a subledger responsibility, users cannot view journal entry lines containing code combinations unless they have access to all the segments in those combinations.
See: Overview of Flexfield Value Security, Oracle Applications Flexfield Guide
Data Access Set Security
Data access set security is enforced by Oracle General Ledger Data Access Sets. The Financial Services Accounting Hub makes data access set security optional for subledger responsibilities using the SLA: Enable Data Access Security in Subledgers profile option. The available values for this profile option are Yes and No. Data access set security is not optional for general ledger responsibilities.
Data access set security is available for the following:
-
Journal entry creation (accounting program or manual subledger journal entries)
-
Inquiries and reports of subledger journal entry headers and lines
See: SLA: Enable Data Access Security in Subledgers, Oracle Subledger Accounting Implementation Guide
Data Access Set
In addition to linking balancing and management segment values to ledgers, General Ledger grants access to ledgers and balancing or management segment values to user responsibilities using data access sets.
Data access set security refers to the data access set security features of the ledger architecture. A data access set grants read/write access to journal entries and lines by ledger, balancing segment values, or management segment values. A data access set can contain many ledgers that share the same chart of accounts and calendar. General Ledger supports one data access set per responsibility. Since primary and secondary representations of a subledger transaction typically have different charts of accounts, subledger accounting supports up to two data access sets per responsibility. Assignment of data access sets to responsibilities is implemented using profile options. There are two profile options: GL: Data Access Set and SLA: Additional Data Access Set.
See:
-
GL Profile Options, Oracle General Ledger User Guide
-
SLA: Additional Data Access Set, Oracle Subledger Accounting Implementation Guide
Each data access set has the following levels:
-
Ledgers: the ledgers to which the user's responsibility has access
A data access set must have at least one ledger. All ledgers in a data access set must use the same chart of accounts and calendar.
-
Balancing or management segment values
Optionally, access can be granted to specific balancing segment or management segment values. The balancing and management segment level grants are read only or read/write.
Data Access Set Example
For the same enterprise, there could be two types of users:
-
Users who have access to the Consulting Line of Business in all ledgers but not the Sales Line of Business
-
Users who have access to all entries for the USA Corp. but not Canada Corp.
The table below describes the user types example.
| Responsibility | Data Access Set Name | Ledger | Balancing Segment Values | Management Segment Values | Access Level |
|---|---|---|---|---|---|
| Consulting | Consulting Line of Business in both countries | USA Corp., Canada Corp. | (all) | Consulting LOB | Read/Write |
| USA Corp. | All USA Corp. | USA Corp. | (all) | (all) | Read/Write |
Data Access Set Security for Journal Entry Creation
Journal Entry Creation includes the following security checks:
-
When users submit the Create Accounting request, the list of values for ledgers is restricted if the profile option SLA: Enable Data Access Security in Subledgers is set to Yes. The ledgers displayed in the list of values includes those that are assigned to the data access sets specified by the profile options GL: Data Access Set and SLA: Additional Data Access Set. Users must have both read and write access to the ledgers as part of the definition of the data access sets.
-
If ledger security is enabled, the Financial Services Accounting Hub validates that the user has write access to the balancing or management segment values assigned to any code combination for the subledger journal entry lines for the ledger of the subledger journal entry. Validation is done based on the type of access set.
Data Access Set Security for Inquiries and Reports
When inquiries or reports are accessed from a general ledger responsibility, data access set security is enforced. The user cannot view a journal entry line unless the user has read access to the ledger and the balancing or management segment values used in the line.
If ledger security is enabled using the SLA: Enable Data Access Security in Subledgers profile option when inquiries or reports are accessed from a subledger application responsibility, then the user cannot view a journal entry line unless the user has read access to the ledger and the balancing management segment values used in the line.