FAIDP Data Level Security based on Fusion Data Security Policies

Girishan

Many customers rely on Data Security Policies defined in Fusion Applications to enforce data-level security consistently across their transactional systems. However, these same policies cannot currently be reused in Fusion Analytics Intelligent Data Platform (FAIDP), resulting in a security gap between Fusion Applications and analytics.

This limitation has surfaced repeatedly across multiple client engagements, particularly for customers who use GL segment–based data security policies to control data access. These customers expect the same security rules defined in Fusion Applications to seamlessly govern data visibility in FAIDP, without requiring separate and redundant security modeling.

Current Limitation

• Data Security Policy filters in Fusion Applications are stored as XML-based definitions.
• These policy definitions are persisted in Fusion tables such as:
  • FND_GRANTS
  • FND_OBJECTS
  • FND_OBJECT_INSTANCE_SETS
• FAIDP currently has no native capability to interpret or evaluate these policy filters, making it impossible to directly apply Fusion-defined data restrictions to analytics.

As a result, customers must:

• Reimplement security logic separately in FAIDP, or
• Accept inconsistent security behavior between operational applications and analytics

Both options increase implementation complexity, risk, and maintenance overhead.

Proposed Enhancement

Introduce a native mechanism in FAIDP to consume and apply Fusion Data Security Policy definitions as data-level security filters.

Key points:

• The policy filters already exist in Fusion and can be retrieved using straightforward SQL queries against the Fusion security tables listed above.
• Enabling FAIDP to evaluate these definitions would allow customers to reuse their existing security model, ensuring consistency across applications and analytics.

I’ve attached a screenshot that illustrates how the policy filters are currently stored in the Fusion database, highlighting how accessible and well-defined these rules already are.

—SQL to extract filters defined in the data security policy:

SELECT
O.OBJ_NAME OBJECT_NAME,
G.ROLE_NAME ROLE_NAME,
G.DESCRIPTION GRANT_DESCRIPTION,
I.FILTER
FROM
FUSION.FND_GRANTS G,
FUSION.FND_OBJECTS O,
FUSION.FND_OBJECT_INSTANCE_SETS I
WHERE
G.OBJECT_ID = O.OBJECT_ID
AND G.INSTANCE_SET_ID = I.INSTANCE_SET_ID
AND I.FILTER IS NOT NULL
ORDER BY
O.OBJ_NAME,
G.GRANTEE_KEY,
G.DESCRIPTION