50 Implement Oracle Fusion Data Security

Resource: A resource on which data security is enforced, such as a purchase order. Resources are stored in the Oracle Fusion Applications FND_OBJECTS table. Note that Oracle Fusion Applications database tables are sometimes called FND tables, where FND refers to resources in the "foundation" tables.

Instance: A particular item of an resource, such as PO_NUMBER 100. An instance generally corresponds to a row in the database. Row instances have one or more primary key values.

Condition: A group of row instances that are determined by a SQL predicate (WHERE clause expression) that queries the attributes of the resource itself. The WHERE clause can reference values from the database context to implement relative conditions where the condition members depend on the security context of the current user. The conditions may also be parameterized, meaning that the WHERE clause references PARAMETER values from the policies for parameterized conditions, as described in How to Use Parameterized Conditions When Securing a Business Object.

Conditions are stored in FND_OBJECT_INSTANCE_SETS table.

Action: Secures an action (also called a function, privilege, or permission) that can be performed on a resource. You typically build features using multiple implementation strategies, including various ADF Business Components operations through Java code. These features must be secured to prevent unauthorized execution of the code. These features generally perform events on resources and actions and they are the artifacts used to secure these events. Actions are stored in FND_FORM_FUNCTIONS table, and the action names within the table are not unique. Only an action used in combination with a resource is unique.

Aggregate Action: A group of actions. Roles specify the combination of actions necessary to perform a particular role on a row instance. For example, a Project Administrator role may include the View, Update, Slip, and Delete actions and a Project Worker role may include only the View and Update actions. Aggregate actions (also called a menu) are stored in FND_MENU and FND_MENU_ENTRIES tables.

Principal (Grantee): A user or a role in Oracle Platform Security Services (OPSS) to which Oracle Fusion Data Security has a reference. The grantee key in the FND_GRANTS table holds the GUID of the OPSS user or role.

User (OPSS User): Any person or application that accesses information in the database.

Role (OPSS Role): Composed of users, groups, and possibly other roles. Roles are used to associate users with actions.

Policy: Authorization for the grantee (OPSS user or role) of an aggregate action may be done on the specified row instance, all instances, or condition. The condition for a policy may be static or parameterized. A policy logically joins a principal, aggregate action, and condition. This has the following effects:

• Any action granted on a row instance implies that the Oracle Fusion Data Security runtime system always has the ability to query the instances. This can be used by a standard Virtual Private Database (VPD) policy function to provide default query filtering. However, this does not mean that you have the ability to view or query because the ability to view a row of the resource is secured by an action.

• In the context of a specific row instance, the policies specify the set of actions that can be performed on a data record.

Resource access can be tested using the Oracle Fusion Data Security authorization checking API. Policies are stored in FND_GRANTS table.

VPD - Virtual Private Database: Provides the ability to dynamically attach a predicate at runtime to all queries issued against a database object (table or view). This feature is available in Oracle RDBMS. For more information about implementing VPD, see Integrating Oracle Fusion Data Security with Virtual Private Database (VPD).

Security Policy Function: A PL/SQL function developed to return a predicate added by VPD to a query. This function is bound to a table or view for some or all of DML statement types: SELECT, INSERT, UPDATE, DELETE.

When integrating Oracle Fusion Data Security with Oracle Platform Security Services (OPSS) to support making policies to OPSS principals, it is important to understand that OPSS principals may be defined in third-party systems and this data does not exist in the database. Only the necessary information (user/user-role mapping) for the current user session is propagated to the database at runtime during session creation to determine the various actions granted for that user session.

At runtime when a user session is created, the user information for that session and the flattened list of roles (to include role hierarchies) for the user of that session is propagated to the database. The roles available in a user session may be different from all the roles that a user may potentially have based on the authentication mechanism used, such as password vs. biometrics, authentication level of DMZ vs. non-DMZ, and so on. OPSS principal information is not stored in the Oracle Fusion Data Security schema.

Every Oracle Fusion application registers ADF task flows for setup activities with a product called Oracle Fusion Functional Setup Manager. These task flows are available from the Fusion Applications Setup and Maintenance work area and enable customers and implementers to set up and configure business processes and products. For more information about data security tasks, see the product-specific security guides.

If data security task flows are used in a web application, that web application must be configured to use ADF Security to enable authentication and authorization so that the correct data security predicates are generated.

Additionally, ADF Security controls access to a specific task flow, and users who do not have the required permission cannot view the task flow. For more information about how to implement function security permissions and roles, see Implementing Function Security .

The following table lists the task flows and their parameters.

/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/DBResourceTF.xml

/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/CreateDBResourceTF.xml

/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/CreateDBResourceTF.xml

/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/CreateDBResourceTF.xml

/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/PolicyTF.xml

Oracle Fusion Data Security integrates with user sessions and relies on session context to be implemented properly.

For information about implementing user sessions, see Implementing Application User Sessions.

If a session has been created successfully, you will see the session created in the FND_SESSIONS table and the user session roles in the FND_SESSION_ROLES view.

When making policies to an OPSS principal, the GRANTEE_KEY must be a valid User / Role GUID as identified in the jazn-data.xml file. At runtime, the list of roles available to the user is determined by the roles granted to the user in the jazn-data.xml file and is populated in the FND_SESSION_ROLES view.

Note that integrating with VPD is optional.

The database has a feature called Virtual Private Database (VPD). VPD allows an arbitrary WHERE clause to be appended to a table, view, or synonym. By doing so, the WHERE clause restricts the rows available. A PL/SQL function is written that returns the WHERE clause and a VPD policy is enabled on a particular table, view, or synonym that references that policy function. VPD policy functions based on fnd_data_security.get_security_predicate() are used to enforce data security rules.

To integrate with VPD:

1. Create an action.

   Use Setup and Maintenance - Manage Data Security Policies UI to create an action on the database resource that you want to secure.

2. When the base table contains no PII data, create a view or synonym.

   If the table contains PII data, you will add the VPD policy directly to the table. Otherwise, create a view or synonym with the exact same name as the action.

3. Add a VPD policy to the table or view.

   Add a VPD policy in the database that will associate the policy function with the table or view.

At runtime, in LOVs or UIs, wherever you want to display the rows that the user has select access to, they simply select off that view.

The user who logs in to view and manage database resources and policies must be authorized based on one of the roles described in Table 50-2.

Use cases:

• Application developer must be able to manage database resources for all Oracle Fusion resources.

• Product-family administrator must be able to manage only the database resources for their specific product family.

To use the standard Application Developer role:

The Oracle Fusion reference implementation predefines an Application Developer job role that inherits all the roles described in Table 50-2. You must contact a system administrator for Oracle Fusion Human Content Management (HCM) and request to be provisioned with the Application Developer job role. During the role provisioning process, you will be notified about the details of your account and password.

• Login to Functional Setup Manager with your account user name and password.

Alternatively, to use your own Product Family Administration role:

For example, if you have a CRM product family administration role, you must be able to manage the CRM database resources, but you will not be allowed to access the HCM resources.

If you have your own Product Family Administration role:

1. In Oracle Authorization Policy Manager, login as the user who is assigned to the appropriate duty role for your product family.

2. Inherit the appropriate duty role for your product family from the duty roles listed in Table 50-2.

3. Define the relationship between duty role and enterprise role.

How Oracle Authorization Policy Manager supports managing policies for database resources:

1. Oracle Fusion Applications delivers the duty roles and policies as specified.

2. Oracle Authorization Policy Manager authors enterprise roles and maps the duty roles listed in Table 50-2. A security manager uses Oracle Authorization Policy Manager to define the relationship between a duty role and enterprise roles.

3. A security manager can create their own enterprise roles if required. They can determine which database resources can be managed by specific data security administrators by including the duty roles into their custom enterprise roles. Security managers are expected to use Oracle Authorization Policy Manager to perform enterprise role to duty role mapping.

4. Policies runtime is based on role GUIDs only.

Reasoning:

Data security policies are granted to duty roles as the default approach. This makes it possible for the security manager to quickly assemble the duties to an enterprise role and use the Oracle Fusion reference implementation quickly. Granting them to an enterprise role means that the security manager must duplicate the policies to any new enterprise roles they create. Enterprise roles are highly guarded and should be created and used only if absolutely needed.

The data security administration UI is secured so that only administrators are permitted to create and manage security policies.

The following table lists the duty roles that have been predefined by the Oracle Fusion security reference implementation to allow users to manage data security. These roles are administered at the product family level to manage resources and policies for that specific product family. The security reference implementation provides role-based access control in Oracle Fusion Applications, and is composed of predefined security policies that protect functions, data, and segregation of duties. Note that the table also identifies the duty roles associated with Oracle Authorization Policy Manager (APM) which allow developers to manage product family data security policies using the Manage Data Security Policies task.

To make the Oracle Fusion Data Security Provider as your data model project's data security provider, you can edit the Oracle Fusion application's adf-config.xml file to define the dataSecurityProviderClass attribute for the sec:JaasSecurityContext element, as shown in the following example.

For example, the adf-config.xml file would contain the sec:JaasSecurityContext element definition shown in the following example.

In Oracle JDeveloper, the design time tools for ADF Business Components are shaped so that the Oracle Fusion Data Security Provider will be automatically registered as the default when you launch JDeveloper with the Oracle Fusion Applications Developer role selected. This occurs when the developer runs the Configure ADF Security wizard for the ADF data model project.

At runtime, the ADF Business Components invocation of Oracle Fusion Data Security Provider happens automatically only for standard operations that have been enabled for entity objects of the data model project. For custom operations that are available on the entity object, you must invoke the Oracle Fusion Data Security authorization checking API manually, as described in How to Perform Authorization Checks for Custom Operations.

There may be other reasons to invoke Oracle Fusion Data Security APIs manually to determine the SQL predicate for a given action or to do an authorization check. For example, you might query VPD policies written based on fnd_data_security.getSecurityPredicate() to enforce data security rules.

dataSecurityProviderClass=
  "oracle.apps.fnd.applcore.dataSecurity.util.FndDataSecurityProvider"

<sec:JaasSecurityContext intialContextFactoryClass=
  "oracle.adf.share.security.JAASIntialContextFactory"
jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurity.Context"
dataSecurityProviderClass=
  "oracle.apps.fnd.applcore.dataSecurity.utl.FndDataSecurityProvider"
authorizationEnforce="true"
authenticationRequire="true"/>

At design time, you secure the read, update, and delete operations on a given entity object using Security section in the General page of the entity object overview editor. The overview editor exposes a set of standard operations (read, update, removeCurrentRow) as checkboxes that you can select. Until you select these operations, read, update, and delete access will not be enforced and therefore rows queried by entity-based view objects will remain accessible to users. Thus, to secure rows of data, the application developer must opt into security by enabling security for the standard row-level operations on the entity object, as shown in the following figure.

Figure 50-2 Entity Object Overview Editor — Security Section

To secure the entity object standard operations:

1. In the Application Navigator, double-click the entity object.
2. In the overview editor for the entity object, click the General navigation tab and expand the Security section.
3. In the Security section, select the operations that you wish to secure: read, update, or removeCurrentRow.

   Note that the entity object permission class oracle.adf.share.security.authorization.EntityPermission defines the permissions read, update, and delete, which correspond to the operations read, update, removeCurrentRow, respectively.

Certain situations exists where it is preferable to secure operations at the level of view objects instead of a single entity object which protects access from all view objects derived from the entity object. In this sense, security at the level of view objects provides a more granular level of access control. Additionally, in cases where custom action checks needs to be performed, it is necessary to secure the view instance by applying a named view criteria defined for the purpose.

In the case of securing rows at the level of specific view objects, you use the View Criteria section of the General page of the overview editor for the view object to create the named view criteria. The following figure shows a view criteria that has been added in the overview editor for the view object.

Figure 50-3 View Object Overview Editor — View Criteria Selection

Once you have defined the view criteria, you must apply it to the view instance that you want the application module data model to filter, as described in the following procedure.

To secure rows displayed to a user from a view object for a custom action:

1. In the Application Navigator, double-click the view object that you will use to filter the rows.
2. In the overview editor, click the Query navigation tab and expand the View Criteria section, then click Create New View Criteria to add a view criteria.
3. In the Create View Criteria dialog, create a named view criteria with no view criteria items and name the view criteria using the following format:

   FNDDS__permissionName__objectName__objectAlias
   

   where:

   permissionName is the permission name that is used to filter the data.

   objectName is the name of the secured database resource in the FND_OBJECTS table.

   objectAlias is optional and is the alias for the resource.

   Note:

   The delimiter is "__" (double underscore characters). This is because no other special character is allowed in a view criteria name.

4. Select Both for the Query Execution Mode, as shown in the following figure (note that no criteria items are defined).

   The query execution mode for the data security view criteria must be set to Both. If you leave the default setting Database selected, then the ADF Business Components association consistency feature will not work properly.

   Figure 50-4 Edit View Criteria Dialog

   
5. In the application module overview editor, select the Data Model navigation tab and select the view instance to filter, then click Edit to apply the view criteria, as shown in the following figure.

   Alternatively, you can apply the view criteria at runtime in your code by calling the view object's applyViewCriteria(viewCriteriaName) API.

   Figure 50-5 Application Module Overview Editor — Edit View Instance Dialog

   

This means that when you define actions in Oracle Fusion Data Security, the actions for those business objects must be named as read, update, or delete to correspond to the entity object security operations that get enabled. Note that the action name corresponding to the removeCurrentRow operation is identified as delete by Oracle Fusion Data Security.

Similarly, when you create custom actions in Oracle Fusion Data Security, the action name that you define must match the custom action specified on the entity object.

Oracle Fusion Data Security Provider only implements row-level authorization check. It does not implement a column-level authorization checking API. Even though Oracle Fusion Data Security can be used to perform column-level security using custom actions, it is not integrated with ADF Business Components directly using the data security provider interface. Wherever column-level security is needed, you must use a custom action.

The default Oracle Fusion Data Security provider implementation assumes that the object name in FND_OBJECTS for the entity object being secured is the database table/view name backing this entity object. If the entity object is a translatable entity object (MLS entity), then the backing database table/view name is identified by Oracle Fusion Middleware Extensions for Applications custom property fnd:OA_BASE_TABLE.

If the default behavior used to identify the backing database table/view name is not sufficient, one can use the entity object overview editor to set a custom property on the entity object. This custom property will identify the name of the object from the Oracle Fusion Data Security repository that will be used to secure this entity. The custom property OA_DS_BASE_TABLE should be set in the Custom Properties section in the General page of the entity object overview editor to accomplish this.

Based on standard operations that you enable for entity object security, the appropriate row-level permission checks are done at runtime. To enable these checks to happen automatically, JDeveloper registers the Oracle Fusion Data Security Provider with ADF Business Components in the adf-config.xml file when you secure an operation on the entity object.

At runtime, in the case of standard entity object operations that have been secured, ADF Business Components invokes the Oracle Fusion Data Security Provider in two steps:

1. The security provider first identifies the WHERE clause (if any) that must be added to the SQL statement for the entity object on which the read operation has been secured. This is done before executing the query.

2. After the query has been executed, ADF Business Components then invokes the Oracle Fusion Data Security Provider again to perform the authorization check for the update and removeCurrentRow operations to determine whether user has update and delete access to that row.

The implementation for securing data by applying a view criteria on the view object instance is handled in the Oracle Fusion Middleware Extensions for Applications layer. It requires the use of Oracle Fusion Middleware Extensions for Applications base classes to achieve this behavior. The OAViewCriteriaAdapter class is the default view criteria adapter class set as the ADF Business Components application module in the OAApplicationModuleImpl class. This functionality is provided in the OAViewCriteriaAdapter.getCriteriaClause() method to fetch the security predicate. In this implementation, the method uses the metadata on the view criteria to invoke Oracle Fusion Data Security APIs that fetch the security predicate.

In the case of a custom operation secured by a custom action, multiple data security view criteria can be applied to the view object. When multiple view criteria are applied, the WHERE clause corresponding to each view criteria is AND'ed. This is standard behavior for ADF Business Components. However, when a single data security view criteria for a given permission is applied, the instance sets corresponding to that permission are OR'ed. When multiple permission checks are applied, the instance sets of a permission are AND'ed with the instance sets of another permission. For example, for an object, for permission perm1, the user has instance sets IS1, IS2. For the same object for privilege priv2, the user has instance sets IS3, IS4. If both perm1 and perm2 checks are applied simultaneously (using view criteria), the WHERE clause would be (IS1 OR IS2) AND (IS3 OR IS4).

At runtime, the ADF Business Components invocation of Oracle Fusion Data Security Provider happens automatically only for standard operations. For custom operations that are available on the entity object, you must invoke the authorization check API manually as shown in the following example.

Note that the allowsOperation() method expects as input the secured operation name rather than the name of the action that secures it. In the case of the standard operations, the operation name for deleting an entity row is removeCurrentRow (where delete is the action name).

There may be other reasons to invoke Oracle Fusion Data Security APIs manually to determine either the SQL predicate for a given action or to do an authorization check. For example, VPD policies written based on fnd_data_security.getSecurityPredicate() to enforce data security rules.

if(row.getSecurityHints().allowsOperation("ApprovePO").hasPermission())
        // code for PO approval
else
        // display error message

You can test data security actions for standard operations (read, update, removeCurrentRow) or custom operations on an entity row using Expression Language or Groovy expression exposed on the entity row.

The Expression Language and Groovy expressions described below work by default when the view object is an updateable view object based on an entity object. If the view object is a read-only view object (based on an entity object) or an expert mode view object, then Expression Language or Groovy expression will not work unless you create a transient attribute with a custom Groovy expression that invokes Data Security to check the operation. The transient attribute can be used to control the rendering of some other attribute in the read-only view object on the page.

• The following example shows the Expression Language expression to use on ADF bindings for view object attributes.

  For example, your UI might have a button to control the grant for the UpdateEmployeeSalary custom action; the Expression Language expression on the button may be defined as shown in the following example.

  When this expression is invoked, Oracle Fusion Data Security Provider checks to see if the user identified by the PersonId attribute has access to the current row for UpdateEmployeeSalary operation. Note that even though the attribute name is included in the Expression Language expression, it is really doing a row-level security check.

  Do not use the expression shown in the following example as Oracle Fusion Data Security Provider does not implement a column-level security check interface. If you want to perform a column-level security, use the expression shown in the previous example with a custom action.

• The following example shows the expression to use for table iterators:

  Do not use the expression shown in the following example as Oracle Fusion Data Security Provider does not implement column-level security check interface. If you want to do column-level security, use the expression shown in the previous example with a custom action.

• When using Expression Language, be careful if you decide to set the expression on the rendered attribute. When PPR is enabled, ADF Faces does not handle the rendered attribute on a UI component well.

  Tip:

  PPR is enabled by default in Oracle Fusion Applications.

  If you want to use Data Security expressions on the rendered attribute, you must manually identify the partial trigger UI components on the page and then set the partialTriggers attribute on the parent UI component of the UI component that has the data security Expression Language expression. Do not use visible attribute on the UI component as this could potentially be a security hole when the UI component and its data is rendered by the server and sent to the client. The visible attribute is a client-side attribute to show or hide the UI component on the browser.

• When using Groovy expressions, use the expression shown in the following example if the view object is an updateable view object based on an entity object.

• When using Groovy expressions, use the expression shown in the following example if the view object is a read-only view object based on an entity object or an expert mode view object. Create a transient attribute on the view object of type Boolean and Value Type Expression. The transient attribute can be used to control the rendering of some other attribute in the read-only view object on the page.

  For example, you have a read-only view object with the attributes PersonId, Name, Gender, and Age and you want to control the rendering of the Gender attribute on the UI. First, you should create a transient attribute by name TransientGenderAttr and set the Groovy expression as mentioned above. The following example shows an EL expression to conditionally render the UI component for the Gender attribute:

  You must make sure that the parent UI component of this UI component has the partialTriggers set to the appropriate UI component IDs. Also, in this scenario, make sure to have the binding available for the transient attribute in the view object, and to set the rendered="false" on the UI component for the transient attribute, or comment out the UI component in the JSF page.

#{bindings.<attrName>.hints.allows.<operationName>}

#{bindings.PersonId.hints.allows.UpdateEmployeeSalary}

#{bindings.<attrName>.hints.<attrName>.allows.<operationName>}

#{row.hints.allows.<operationName>}

#{row.hints.<attrName>.allows.<operationName>}

object.getSecurityHints().allowsOperation("updateCategory").hasPermission()

oracle.apps.fnd.applcore.dataSecurity.dataSecurityService.applicationModule.DataSecurityAMImpl.
testPrivilege("VIEW_PERSON_NAME_LIKE_T","PER_EL_TEST_PERSONS", PersonId.toString(),
null,null,null,null,object.getViewObject().getDBTransaction());

<af:panelFormLayout id="pfl1" partialTriggers="it6 cb3 cb1 cb4 cb5">
<af:inputText value="#{bindings.Gender.inputValue}"
              label="#{bindings.Gender.hints.label}"
              required="#{bindings.Gender.hints.mandatory}"
              columns="#{bindings.Gender.hints.displayWidth}"
              maximumLength="#{bindings.Gender.hints.precision}"
              shortDesc="#{bindings.Gender.hints.tooltip}" id="it4"
              rendered="#{bindings.TransientGenderAttr}">
  <f:validator binding="#{bindings.Gender.validator}"/>
</af:inputText>

<af:inputText value="#{bindings.TransientGenderAttr.inputValue}"
              label="#{bindings.TransientGenderAttr.hints.label}"
              required="#{bindings.TransientGenderAttr.hints.mandatory}"
              columns="#{bindings.TransientGenderAttr.hints.displayWidth}"
              maximumLength="#{bindings.TransientGenderAttr.hints.precision}"
              shortDesc="#{bindings.TransientGenderAttr.hints.tooltip}"
              rendered="false"
              id="it1">
</af:inputText>
<f:facet name="footer">
<af:panelGroupLayout layout="vertical" id="pgl1">
  <af:panelGroupLayout layout="horizontal" id="pgl2">
    <af:commandButton actionListener="#{bindings.First.execute}"
                      text="#{applcoreBundle.FIRST}"
                      disabled="#{!bindings.First.enabled}"
                      partialSubmit="true" id="cb3"/>
    <af:commandButton actionListener="#{bindings.Previous.execute}"
                      text="#{applcoreBundle.PREVIOUS}"
                      disabled="#{!bindings.Previous.enabled}"
                      partialSubmit="true" id="cb1"/>
    <af:commandButton actionListener="#{bindings.Next.execute}"
                      text="#{applcoreBundle.NEXT}"
                      disabled="#{!bindings.Next.enabled}"
                      partialSubmit="true" id="cb4"/>
    <af:commandButton actionListener="#{bindings.Last.execute}"
                      text="#{applcoreBundle.LAST}"
                      disabled="#{!bindings.Last.enabled}"
                      partialSubmit="true" id="cb5"/>
  </af:panelGroupLayout>
    <af:commandButton text="#{applcoreBundle.SUBMIT}" id="cb2"/>
  </af:panelGroupLayout>
</f:facet>
</af:panelFormLayout>

Parameterized conditions allow conditions to be specified generally but granted specifically. Parameterized conditions are useful because they reduce the number of predicates that the database must parse, as well as reducing the number of conditions that the administrator needs to manage.

The following example shows how a parameterized condition can be reused.

An administrator can reuse the first condition for several different policies granted to different locations and the second condition can be reused for policies granted to different titles. For example, one policy might use OIS1 to grant to 'WEST' by putting 'WEST' in FND_GRANTS.PARAMETER1, while another policy would reuse the same OIS1 to grant to 'EAST'. At runtime, the FND_DATA_SECURITY package substitutes the PARAMETER values from the FND_GRANTS table to the OISs granted.

When the data security system runs the predicates that have been defined in the conditions, it does a simple replace-style parsing of the predicate. For example, &TABLE_ALIAS is replaced by the table alias of the resource table, if it was passed to the get_security_predicate() call, and &GRANT_ALIAS is replaced by the policy table alias.

Condition. Employees in a particular region.
    Predicate: "&TABLE_ALIAS.REGION = &GRANT_ALIAS.PARAMETER1"

For development purposes, you can use the OPSS jazn-data.xml flat file to create users and roles for testing.

For an example of the identity store in the flat file used by JDeveloper, see the Enabling ADF Security in a Fusion Web Application chapter of the Developing Fusion Web Applications with Oracle Application Development Framework, in the Oracle Fusion Middleware Online Documentation Library.

Before testing the application in the staging environment, any custom application roles that you created will need to be created in the LDAP application policy store. These new application roles will receive new GUIDs and any data security policies defined for application roles of the same name must have their GUIDs reconciled. For details about reconciling GUIDs in the data security repository, see the Reconciling GUIDs section in the Administrator's Guide.

The DataSecurityAMImpl class is in the oracle.apps.fnd.applcore.dataSecurity.dataSecurityService.applicationModule package. It is the container for all data security resources provided by Oracle Fusion Middleware Extensions for Applications. This class contains core methods to:

• Check action for the current user, as shown in the following example.

  Where DataContext is a container class that represents the resource and optionally the primary keys of that resource for which data security check must be done. It has the following attributes: ObjectName, PK1, PK2, PK3, PK4, PK5.

  Note:

  Privilege and DataContext classes are in the oracle.apps.fnd.applcore.dataSecurity.util package.

  If the action is granted to an Oracle Platform Security Services (OPSS) role in FND_GRANTS table, then the system retrieves all the OPSS roles that the user has access to, and checks if one of them matches with the OPSS role to which the action has been granted.

• Get the security predicate associated with a given action on a given resource for the current user, as shown in the following example.

• Get all the actions available on a given row instance for the current user, as shown in the following example.

• Get all the aggregate actions available on a given row instance for the current user, as shown in the following example.

As shown in the following example, static APIs are also provided in the DataSecurityAMImpl class for the above core methods that take in a DBTransaction object.

/**
 * Test if an action is accessible for a given data context for the user 
 * in the current session context.
 * @param privilege the privilege to test
 * @param dataContext data context (object and primary key) to use for
 * testing the privilege.
 * If null, then no data context is used.
 * @return true if privilege is accessible, false otherwise.
 */
public boolean testPrivilege(Privilege privilege, DataContext context)

/**
 * Return the security predicate for a given action on a resource
 * for the user in the current session context.
 * @param privilege privilege to use to determine the predicat.
 * @param dataContext the data context, which provides the object name.
 * @param grantInstanceType the grant instance type, (such as "UNIVERSAL").
 * @param statementType the statement type, (such as "OTHER").
 * @param tableAlias alias for the table.
 * @return the security predicate.
 */
 public String getSecurityPredicate(Privilege privilege, DataContext dataContext
    grantInstanceType, String statementType, String tableAlias)

/**
 * Provides the list of action names granted to the user for
 * the specified dataContext (Object/PK) in the current session context.
 * @param dataContext data context (object and primary key) to use for
 * identifying the granted actions.
 * @return list of action names.
 */
 public String[] getPrivileges(DataContext dataContext)

/**
 * Provides the list of aggregate action names granted to the user for
 * the specified dataContext (Object/PK) in the current session context.
 * @param dataContext data context (object and primary key) to use for
 * identifying the granted aggregate actions.
 * @return list of aggregate action names.
 */
 public String[] getAggregatePrivileges(DataContext dataContext)

public static boolean testPrivilege(Privilege privilege, DataContext context, 
      DBTransaction dbTxn)

public static String getSecurityPredicate(Privilege privilege, 
     DataContext dataContext, String grantInstanceType, String statementType,
     String tableAlias, DBTransaction dbTxn)

public static String[] getAggregatePrivileges(DataContext dataContext, 
      DBTransaction dbTxn)
public static String[] getPrivileges(DataContext dataContext, DBTransaction dbTxn)

Oracle Fusion Middleware Extensions for Applications provides the FND_DATA_SECURITY PL/SQL package for the data security system.

FUNCTION check_privilege determines whether the user is granted a particular action for a particular row instance, as shown in the following example. The user is determined from the user session context.

This API returns a 1 byte result code:

T - Action is granted.

F - Action is not granted.

E - Error

U - Unexpected error.

PROCEDURE get_security_predicate gets the union of all predicates for the user on an action, as shown in the following example. The user is determined from the user session context.

p_grant_instance_type can take on one of the following values:

INSTANCE - Returns predicate for policies with instance_type = 'INSTANCE' or 'GLOBAL'.

SET - Returns predicate for policies with instance_type = 'SET'.

UNIVERSAL - (Default) Returns predicate for policies with any instance_type.

p_table_alias is appended in front of the column references in the returned x_predicate. It is normally used when two security predicates are going to be ANDed together to use with a select that joins two secured tables. The value passed here should correspond to the table alias that the statement uses for the p_object_name passed to this routine. The default, NULL, means there is no table alias so none is appended.

p_statement_type can take on one of the following values:

OTHER - (Default). The predicate returned is not attached by policy to the base table as is done for VPD. In practice, this allows the predicate to have a sub select against the base table, which allows aliases and may improve performance.

VPD - Pass this type if the predicate is attached by policy to the base table. Use this when VPD uses the returned predicate to control access. In practice, this means the predicate cannot have sub selects against the base table, prevents aliases and may lower performance.

EXISTS - Pass this type if the predicate is simply used to determine if there are any rows at all that are available. The predicate returned is in the format like 'EXISTS...'.

X_return_status is the result of all the operations:

T - Successfully got predicate

E - Error

U - Unexpected error

L - Value too long - predicate too large for database VPD

The return value is all the available predicates from the policies on this action for this user. They are OR'ed together to form a SQL predicate that can be dropped into the WHERE clause to limit rows returned to those that are allowed by the security. Does not include WHERE.

FUNCTION check_privilege
(
  p_api_version          IN NUMBER, 
    /* API Version of this procedure - currently 1.0 (Required) */
  p_privilege            IN VARCHAR2, 
    /* Name of the action (Required) */
  p_object_name          IN VARCHAR2,
    /* Resource on which the policy should be checked from FND_Objects table
       (Required) */
  p_instance_pk1_value   IN VARCHAR2 DEFAULT NULL,
    /* p_instance_pk(1...5)_value (Required)
       Primary key values for the row instance, with order corresponding
       to the order of the PKs in the FND_Objects table. Most resources have
       only a few primary key columns so let the higher, unused columns
       default to NULL. 
       NOTE: The caller must pass an actual primary key and it must be the
       primary key of an actual instance (row). */
  p_instance_pk2_value   IN VARCHAR2 DEFAULT NULL,
  p_instance_pk3_value   IN VARCHAR2 DEFAULT NULL,
  p_instance_pk4_value   IN VARCHAR2 DEFAULT NULL,
  p_instance_pk5_value   IN VARCHAR2 DEFAULT NULL
)RETURN VARCHAR2;

PROCEDURE get_security_predicate
(
  p_api_version          IN NUMBER,
  /* API version of this procedure - Currently 1.0 (Required) */
  p_privilege            IN VARCHAR2 DEFAULT NULL,
  /* Name of action. (Optional) */
  /* NULL represents all actions so the predicate will not take the 
     action into account. */
  p_object_name          IN VARCHAR2,
  /* Object on which the predicate should be checked from FND_Objects table. */
  p_grant_instance_type  IN VARCHAR2 DEFAULT 'UNIVERSAL',
  /* SET, INSTANCE  (Optional) */
  p_statement)_type      IN VARCHAR2 DEFAULT 'OTHER',
  /* (Optionsl) statement type: 'OTHER', 'VPD', 'EXISTS' = to check existence. */
  x_predicate            OUT NOCOPY VATRCHAR2,
  x_return_status        OUT NOCOPY VARCHAR2,
  p_table_alias          IN VARCHAR2 DEFAULT NULL
  /* (Optional) */
);

The WLST script datasecurityDiagnostics.py is provided to help administrators verify that data security setup and configuration definitions are correct for a newly deployed application. Additionally, the script generates a report that system integrators, developers and security managers can further use to diagnose runtime issues related to a logged-in user's ability to access data.

To accomplish these tasks, the script performs these specific functions:

• Validates data security configuration in the adf-config.xml file, which is archived in the application EAR file. The scripts checks the configuration values of the <sec:JaasSecurityContext> element to verify that the data security provider is properly configured and outputs the result to the output file DataSecurityDiagResults.out.

• Validates that GUID consistency is enabled in the weblogic-application.xml file. The script checks the value of the jps.approle.preserveguid application parameter and outputs the result to the output file DataSecurityDiagResults.out. The application parameter must be set to TRUE to support deploying the policy store from a test to a production environment. This ensures the GUID for each application role remain the same when migrated from XML to LDAP or LDAP to LDA.

• Optionally, takes the running application's session cookie value as an input parameter and, using this session cookie, the script gets the corresponding session object from the data source, inspects the session attributes and outputs the session information to the output file DataSecurityDiagResults.out. Using the session cookie, the script gets role information corresponding to the session's logged-in user, along with their access privileges to various database objects and outputs it to the output file DataSecurityDiagResults.out.

  Note: If you only want the script to perform the application configuration validation checks, you can skip this step by pressing Enter when prompted to enter the value for session cookie.

Important Note

Before invoking a WLST script you must run the following wlst.sh script on Oracle WebLogic Server to ensure that the required JARs are added to the class path.

>sh $ORACLE_HOME/common/bin/wlst.sh

After you invoke the wlst.sh script, you can connect to Oracle WebLogic Server in offline mode, that is, the data security script does not require a connection to a running server to operate.

To invoke the data security diagnostic script:

At the offline prompt, enter the following command:

>wls:/offline> execfile('datasecurityDiagnostics.py')

The script prompts you for the following information before outputting the results:

• Output file's directory path where you want the script's output file to be saved.

• Application name for which you want to run the script. The application name is the deployment name in Oracle WebLogic Server. For example, SalesApp#V3.0. Note that the version part of the application name is specified with a # symbol: for example, #V3.0 in SalesApp#V3.0.

• Application source path of the deployed application. For example, /scratch/myself/view_storage/myself_main_gene_testing/system11.1.1.4.37.56.69/DefaultDomain/servers/DefaultServer/upload/DemoSecurity/V2.0/app/DemoSecurity.ear. The source path can be obtained from Oracle WebLogic Server Administration Console, under the Deployments section for the application.

• Session cookie value created for the logged-in user for whom you want to validate data security roles and privileges. Optional (you can press Enter to skip). To obtain the session cookie, you must log into the application as the user whose roles and privileges you want to examine. After logging into the application, from the browser, open the cookies window (for example, in Internet Explorer, you can display cookies from the Temporary Internet Files and History Settings dialog). Under the site oracle.com, locate the cookie named <DATABASE_SID>_FND_SESSION and copy the value, which is the required session cookie. If you do not find this named session cookie, it means that the applications context is not created for your application.

  Tip:

  You can run the application context diagnostic script by pressing Enter when the data security script prompt you to enter the value for session cookie for your application. This will invoke the applications context script and validate the applications context configuration. For details about the applications context script, see How to Validate Applications Context.

The WLST script applsessionDiagnostics.py is provided to help administrators verify that applications context setup and configuration definitions are correct for a newly deployed application and that the applications context is created for a logged-in user. Additionally, the script generates a report that system integrators, developers and security managers can further use to diagnose the runtime issues related to an Application Session.

To accomplish these tasks, the script performs these specific functions:

• Validates the session filters and filter mapping definitions in the web.xml file, which is archived in the application EAR file. The scripts checks for the presence of the <filter-name>ApplSessionFilter</filter-name> element and verifies that the ApplSessionFilter mapping definition appears immediately after the JpsFilter mapping definition, and then outputs the result to the output file ApplsessionDiagResults.out.

• Connects to the database and gets the Oracle Fusion Applications FND table metadata for the application context. The script checks the value of the Name, Datatype, Precision, and isNullable attributes for each column in the tables, validates the database schema for each table, and then outputs the result to the output file ApplsessionDiagResults.out.

• Optionally, takes the running application's session cookie value as an input parameter and, using this session cookie, the script gets the corresponding session object from the data source, inspects the session attributes and outputs the applications context session properties to the output file ApplsessionDiagResults.out. Using the session cookie, the script gets the applications context properties corresponding to the session's logged-in user, determines whether ApplSession is created properly, and outputs the result to the output file ApplsessionDiagResults.out.

  Note: If you only want the script to perform the application configuration validation and the database metadata validation checks, you can skip this step by pressing Enter when prompted to enter the value for session cookie.

• Connects to the database and validates the FUSION.FND_SESSION_MGMT PL/SQL package to check for its consistency. The script checks whether a valid package header and package body is defined for the package and outputs the result to the output file ApplsessionDiagResults.out.

Before you begin:

Before invoking a WLST script you must run the following wlst.sh script on Oracle WebLogic Server to ensure that the required JARs are added to the class path. Use the following command:

>sh $ORACLE_HOME/common/bin/wlst.sh

After you invoke the wlst.sh script, you can connect to Oracle WebLogic Server in offline mode, that is, the data security script does not require a connection to a running server to operate.

To invoke the application context diagnostic script:

At the offline prompt, enter the following command:

>wls:/offline> execfile('applsessionDiagnostics.py')

The script prompts you for the following information before outputting the results:

• Output file's directory path where you want the script's output file to be saved.

• Application name for which you want to run the script. The application name is the deployment name in Oracle WebLogic Server. For example, SalesApp#V3.0. Note that the version part of the application name is specified with a # symbol: for example, #V3.0 in SalesApp#V3.0.

• Application source path of the deployed application. For example, /scratch/myself/view_storage/myself_main_gene_testing/system11.1.1.4.37.56.69/DefaultDomain/servers/DefaultServer/upload/DemoSecurity/V2.0/app/DemoSecurity.ear. The source path can be obtained from Oracle WebLogic Server Administration Console, under the Deployments section for the application.

• Session cookie value created for the logged-in user for whom you want to validate data security roles and privileges. Optional (press Enter to skip). To obtain the session cookie, you must log into the application as the user whose roles and privileges you want to examine. After logging into the application, from the browser, open the cookies window (for example, in Internet Explorer, you can display cookies from the Temporary Internet Files and History Settings dialog). Under the site oracle.com, locate the cookie named <DATABASE_SID>_FND_SESSION and copy the value, which is the required session cookie. If you do not find this named session cookie, it means that the applications context is not created for your application.

The process of integrating the data security task flows into an Oracle Fusion application involves understanding the input parameters of the task flow. Your application will use a managed bean to initialize the task flow's parameters before the application displays the task flow to the end user. The way your application references the values of the input parameters on the bean depends on how you want to display the task flow. Your application can display the data security task flow one of two ways:

• You can display the task flow in the application's primary browser window.

• You can display the task flow in the application's secondary browser window that displays a new web page and allows the user to view the primary window while working in the task flow.

For example, the object instance task flow user interface is well-suited to run in a dialog. When you run this task flow in a dialog, the user can select an object in the primary browser window, make grants on the selection in the secondary window, and repeat for other objects without needing to reopen the primary window. The other task flows, including the object-centric task flow, profile (role-centric) task flow, and role management task flow, are large enough that you may want to display them in the primary window.

The steps to integrate the data security task flows into your application will depend on the method you choose to display the task flow. However, review the following general steps for an overview of the process.

Before you begin:

Add the data security task flows to your project. Decide whether you want your application to display the task flow in the primary window or in a popup dialog

To integrate the data security task flows, follow these general steps.

1. Decide whether you want your application to display the task flow in the primary window or in a popup dialog.

2. Create a task flow reference in your application to bind the data security task flow to the ADF Model layer.

   In JDeveloper, the reference will be generated for you when you drag and drop the data security task flow. The way you drag and drop the data security task flow depends on the way your application displays the task flow:

   • How to Configure Data Security Task Flows to Display in the Primary Window

   • How to Configure the Object Instance Task Flow to Display in a Dialog

   1. Define the data security task flow's input parameters so they have page flow scope.

      Page flow scope will allow the values to be passed into the task flow from a managed bean. The ADF Model layer component that you use to define the parameters depends on the way your application displays the task flow:

   2. Create a managed bean and define an initialization method to populate the input parameters for the data security task flows, as shown in Table 50-4.

      The method you define will initialize the values before your application displays the task flow. When displaying the page inside your application's primary window, the initialization method must also return the value of the flow control outcome you configure in your application's task flow to invoke the data security task flow. The outcome return value is not needed when displaying a dialog, since the dialog is not invoked the same way.

   3. Create a navigation button that invokes the initialization method in your method bean.

      The ADF Faces component you use to create the button depends on how you want the data security task flow to display:

3. Authorize the data security task flows to make grants in the LDAP policy store. For details see How to Grant the Data Security Task Flows Access to the Application Policy Store.

4. Authorize end user to access the task flow. For details see How to Grant the End User Access to the Data Security Task Flows.

5. Configure the application to access the domain LDAP policy store. For details see How to Map the Application to an Existing Application Stripe.

The following table describes the input parameters that your managed bean must initialize for each task flow.

/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/ObjectLevelFT.xml

objectName

roleCategories

actions

disableViewAll

disableUpdateAll

/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/ProfileTF.xml

roleCategories

actions

disableViewAll

disableUpdateAll

/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/ObjectInstTF.xml

objectName

instancePk1
instancePk2
instancePk3
instancePk4
instancePk5

actions

taskflowId

parameterMap

/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/RoleManagementTF.xml

roleCategories

title

1. In your application's task flow, create a call activity and specify a control flow case from the calling web page's view activity.

   The calling web page is the page in your application where you want the end user to launch the data security UI. This is the page that will be replaced in the browser window when the data security UI is displayed.

2. Drop the desired data security task flow onto the task flow call activity.
3. Edit your application's task flow configuration file to specify the data security task flow's input parameter values on the call activity.
4. Create a managed bean that initializes the data security task flow's input parameters and returns the value of the outcome for the control flow case you specified.
5. Register the managed bean in your application's task flow configuration file.
6. In the web page associated with the view activity, drop an ADF command button and configure the button to invoke the managed bean's initialization method.

1. In your application's task flow, double-click the view activity associated with the web page that end users will use to open the dialog.
2. In the web page, drop an ADF command button component.
3. Drop an ADF popup component onto the button and configure a popup fetch listener to invoke an initialization method on a managed bean.
4. Drop an ADF dialog inside the popup component and configure a dialog listener to invoke a method to save grants made by the user.
5. Drop the object instance task flow as a region onto the dialog component.
6. Edit the page definition file for the calling page to specify the data security task flow's input parameter values on the task flow executable.
7. Create a managed bean and define a method to initialize the task flow parameters before the dialog displays.
8. Define another method on the managed bean to trigger the task flow save action and save the grants into the database.
9. Register the managed bean in your application's task flow configuration file.

1. In JDeveloper, open the jazn-data.xml file in the overview editor.
2. In the source for the jazn-data.xml file, add the code source grant shown in the previous example to the policy store and enter the name of your application in the <url> and <name> definitions.

   The application name you enter must match the application name identified in the policy store definition.

3. Save the jazn-data.xml file.

<grant>
   <grantee>
      <codesource>
          <url>file:${domain.home}/servers/${weblogic.Name}/tmp/_WL_user/<application-name>/-</url>
      </codesource>
   </grantee>
   <permissions>
      <permission>
          <class>oracle.security.jps.service.policystore.PolicyStoreAccessPermission</class>
          <name>context=APPLICATION,name=<application-name></name>
          <actions>getApplicationPolicy,grant,revoke,alterAppRole,createAppRole,
                                                         alterAppRoleCategory</actions>
      </permission>
   </permissions>
</grant>

1. In JDeveloper, open the jazn-data.xml file in the overview editor.
2. In the source for the jazn-data.xml file, add the permission definition shown in the previous example to the policy store and define the grantee.

   Grantee are typically application roles that your application defines. A grant is always made to a single grantee. When you need to grant view permission to more than one grantee, create duplicate grants and name the grantee in each.

3. Save the jazn-data.xml file.

<grant>
   <grantee>
      ...
   </grantee>
   <permissions>
      <permission>
        <class>oracle.adf.controller.security.TaskFlowPermission</class>
        <name>/WEB-INF/oracle/apps/fnd/applcore/dataSecurity/ui/taskflow/.*</name>
        <actions>view</actions>
      </permission>
   </permissions>
</grant>

1. In JDeveloper, open the web.xml file in the overview editor.
2. In the source for the web.xml file, add the web application initialization parameter shown in the previous example beneath the JPS filter.

   The application name you enter must match the application name identified in the policy store definition.

3. Save the web.xml file.

<init-param>
      <param-name>application.name</param-name>
      <param-value><application-name></param-value>
</init-param>