| Oracle® Fusion Applications Developer's Guide 11g Release 6 (11.1.6) Part Number E15524-11 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Developer's Guide 11g Release 6 (11.1.6) Part Number E15524-11 |
|
|
PDF · Mobi · ePub |
This chapter describes how to use Oracle Fusion Data Security to enforce security authorization for access and modification of specific data records in an Oracle Fusion application.
This chapter includes the following sections:
Section 49.2, "Managing Data Security Artifacts in the Oracle Fusion Data Security Policy Tables"
Section 49.4, "Using Oracle Fusion Data Security to Secure New Business Resources"
Section 49.5, "Getting Security Information from the Application User Session Context"
Section 49.6, "Understanding Data Security Performance Best Practices"
Section 49.7, "Validating Data Security with Diagnostic Scripts"
Oracle Fusion Data Security is the technology that implements data security in Oracle Fusion Applications and is not used by function security (Oracle Platform Security Services (OPSS) is used for function security). Oracle Fusion Data Security integrates with Oracle Platform Security Services (OPSS) by granting actions to an OPSS principal. The grant defines who (the principal) can do what (the actions) on a given resource. A grant in Oracle Fusion Data Security can use any enterprise user or enterprise group as principals.
Note:
Oracle Platform Security Services (OPSS) principal information is not stored in the Oracle Fusion Data Security schema. The OPSS principal may be stored in any third-party system. 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.
The goal of Oracle Fusion Data Security is to authorize a user to perform specified actions on selected data. It can secure rows and attributes of a database object and relies on OPSS to provide the authentication services for OPSS principals (users, groups, or roles). It answers the question "Who can do what on which set of data". Who refers to the OPSS user or group (or role), what is the action, and which is the subset of data that can be accessed.
You can use Oracle Fusion Data Security to either restrict the rows that are returned by a given query based on the intended business operation or restrict the actions that are available for a given row.
Note:
Oracle Fusion Data Security assumes that the connection or session provided to it has been initialized properly with the appropriate user session user context, as described in Chapter 48, "Implementing Application User Sessions." In this chapter, the user session is specifically an application user session (ApplCore). The application user session is the session that Oracle Fusion Data Security expects to see.
The purpose of data security is to model and enforce security authorization for a specific data record or a set of records. Data security provides access control within Oracle Fusion applications on the data a user can access and the actions a user can perform on that data. Oracle Fusion application rely on data security to restrict access to individual data that is displayed on a page that may display after the user has selected a menu or menu option.
For additional information about Oracle Fusion Data Security, see the Oracle Fusion Applications Security Guide.
The following are some use cases where Oracle Fusion Data Security can be utilized:
Grant read action on expense reports to managers of the current employee when the manager is granted Expenses Administrator role.
Administer the list of documents available to an end user in a Document Management System (DMS) based on Document Categories.
Show the list of Sales Opportunities available to a Sales Head of an organization based on region.
Allow a Human resources (HR) Benefits Administrator to only administer the employees whose last name begins with A-F.
Allow a HR Administrator to only administer the employees in a given region.
In Oracle Fusion Data Security, data that needs to be secured is identified as resources. These resources are database tables or views. Policies that control which data that a user has access and can perform actions, can be made on a row instance or condition. Figure 49-1 illustrates the logical data model implemented by Oracle Fusion Data Security.
An instance is a row of data and is identified by the primary key value of the row in the resource's storage table. A condition is a group of row instances whose membership is determined by a rule in the form of a SQL predicate, which must be applicable to the WHERE clause of a single-table query against the resource's storage table.
For example, each row in the Purchase Order table is an instance of the Purchase Order resource. The purchase order number is the primary key that identifies a particular purchase order instance. You can create an condition with the predicate "PO_NUMBER=100", which contains just one row of data. Purchase orders from the West region can be put into a condition that is defined by the predicate "REGION='WEST'". A condition that contains all the rows of data in the resource's storage table can be defined by the predicate "1=1".
Memberships of a condition are dynamic in many ways, such as:
Condition membership rules may contain any valid SQL attributes, such as columns of a table. Adding new instances or updating existing instances may affect the membership of a condition. Using the above Purchase Order example, if the predicate is "REGION='WEST'", new purchase orders in the region of West will automatically become a member of the condition.
When an action is granted to an OPSS application role (also called a duty role by Oracle Fusion Applications) on a condition it can be parameterized. Using the Purchase Order example, the condition may be defined by the predicate "REGION=&PARAM" where the parameter PARAM is associated with different regions. When an action is granted on a condition, it may be done for a particular value of the parameter, such as a sales manager in the West region may have an action granted on a Region condition with the parameter value West.
The condition rules may not reveal any membership at all. It can just be a WHERE clause to filter rows based on runtime user session variables.
To grant data security actions to a user, you must first identify the resources that you want to secure, define conditions on those resources, and then grant specific actions on these conditions to the application role to which the user belongs.
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 Section 49.4.2, "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) 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 are what is used to secure these events. An action must be associated with a resource.
Note:
The action name alone is not unique on the table; the combination of an action name and resource is what makes it unique.
Actions are stored in FND_FORM_FUNCTIONS table.
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.
Once 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 Section 49.1.5, "Integrating Oracle Fusion Data Security with Virtual Private Database (VPD)".
Security Policy: 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. 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.
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 Oracle Fusion Applications Common Implementation Guide.
If data security task flows are used in a web application, that web application must be configured to use ADF Security in order 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 privilege cannot view the task flow. For more information about how to implement function security privileges and roles, see Chapter 50, "Implementing Function Security."
Table 49-1 lists the task flows and their parameters.
Table 49-1 Data Security Task Flows and Parameters
| Task Flow Name | Task Flow XML | Parameters Passed | Behavior | Comments |
|---|---|---|---|---|
|
Manage Database Resources |
/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/DBResourceTF.xml |
|
Goes to the Search page for database resources. |
None. |
|
Manage Database Resource |
/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/CreateDBResourceTF.xml |
|
Goes to the Edit page for a database resource. |
None. |
|
Manage Database Resource Conditions |
/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/CreateDBResourceTF.xml |
|
Goes to the Conditions tab of the database resource Edit page. |
Conditions are a child entity of database resource. There is no Search page for conditions across all database resources; therefore, DB resource ID is mandatory. |
|
Manage Database Resource Actions |
/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/CreateDBResourceTF.xml |
|
Goes to the Actions tab of the database resource edit page. |
Actions are a child entity of database resource. There is no Search page for actions across all database resources; therefore, DB resource ID is mandatory. |
|
Manage Policy |
/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/PolicyTF.xml |
|
This is the Create/Edit Policy page |
There is no Search here, except to pick a specific database resource and pick a specific role. |
Oracle Fusion Data Security integrates with user sessions and relies on session context to be implemented properly.
For information about implementing user sessions, see Chapter 48, "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 policy is enabled on a particular view or synonym that references that policy function. Policy functions based on fnd_data_security.get_security_predicate() are used to enforce data security rules.
To integrate with VPD:
Create an action.
Create an action on the database resource that you want to secure. Using the Functions form, set the object column of the action to point to the data security object. This column is fnd_form_functions.object_id.
Create a view or synonym.
Create a view or synonym with the exact same name as the action.
Add a policy.
Add a policy in the database that will associate the policy function with the 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.
Oracle Fusion Data Security artifacts include resources, row instances, conditions, actions, aggregate actions, and so on. Data security artifacts are stored in the Oracle Fusion Data Security repository and are customized using Oracle Authorization Policy Manager, which can be accessed by the developer through Oracle Fusion Functional Setup Manager, from the Manage Data Security task available in the Setup and Maintenance work area of any Oracle Fusion Setup application.
Note:
After the developer selects the Manage Data Security task in Oracle Fusion Functional Setup Manager, the environment redirects to the data security customization user interface provided by Oracle Authorization Policy Manager. In this document, although the data security customization tool is identified as Oracle Authorization Policy Manager, be aware that the tool must be accessed through Oracle Fusion Functional Setup Manager.
For details about managing data security, see the "Managing Oracle Fusion Applications Data Security Policies" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
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 49-2. The Oracle Fusion reference implementation predefines an Application Developer job role that inherits all the roles described in Table 49-2. It also seeds a user APPLICATION_DEVELOPER that inherits the Application Developer job role.
To use the standard Application Developer role:
Login to Functional Setup Manager as the APPLICATION_DEVELOPER user. Contact the system administrator for the password.
If you have your own Product Family Administration role:
In Oracle Authorization Policy Manager (Oracle APM), login as the user who is assigned to the appropriate duty role for your product family.
inherit the appropriate duty role for your product family from the duty roles listed in Table 49-2.
Define the relationship between duty role and enterprise role.
Use cases:
CRM Administrator logs in. He must be able to manage the CRM database resources. He must NOT be able to access the HCM resources.
Super Administrator (Application Developer) logs in. He must be able to manage conditions for all Oracle Fusion resources.
Solution based on the above use cases:
Oracle Fusion Applications delivers the duty roles and policies as specified.
Oracle Authorization Policy Manager (APM) authors enterprise roles and maps the duty roles listed in Table 49-2. A security manager uses APM to define the relationship between a duty role and enterprise roles.
APM can create three enterprise roles, one per pillar. (Multiple product families can be included into one pillar).
APM can include the product family level duties into the above enterprise roles, as appropriate.
APM must ensure that they have the correct role GUIDs for the duty roles. (See the jazn-data.xml file.)
A security manager can create their own enterprise roles if required. They can determine which objects can be managed by specific data security administrators by including the duty roles into their custom enterprise roles. Security managers are expected to use the APM console to perform enterprise role to duty role mapping.
Policies runtime is based on role GUIDs only.
Reasoning:
Data security policies are made 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.
Note:
You cannot view the database resources or manage policies from the Functional Setup Manager if you have not granted the appropriate data security manage privileges to your administrators.
Table 49-2 lists the duty roles that have been predefined by the Oracle Fusion security reference implementation to allow access to users to manage data security. These roles are administered at the product family level to manage resources and policies for that specific product family.
Table 49-2 Duty Roles to Manage Data Security Policies
| # |
Family | Duty Role |
|---|---|---|
|
1 |
CRM |
Customer Relationship Management Database Resource Administration Duty |
|
2 |
HCM |
Human Capital Management Database Resource Administration Duty |
|
3 |
FSCM |
Financials and Supply Chain Manufacturing Database Resource Management Duty |
|
4 |
APM - CRM |
APM - CRM Database Resource Administration Duty |
|
5 |
APM - HCM |
APM - HCM Database Resource Administration Duty |
|
6 |
APM - FSCM |
APM - FSCM Database Resource Administration Duty |
In Oracle Fusion applications, the data to be secured is typically defined in the application's data model project by an ADF Business Components entity object. Oracle Fusion Data Security integrates with ADF Business Components so that when you are defining an ADF Business Components entity object you can:
Identify the actions that are available on a given row
Have the ability to check at runtime if the user has access to this row based on the policies that are available to that user.
The authorization check is done automatically by ADF Business Components for standard operations, such as read, update, and removeCurrentRow. To perform a security check on non-standard operations you must call Oracle Fusion Data Security APIs directly.
You must identify your actions on the entity object. You cannot identify actions directly on an ADF Business Components view object; however, when a view object references an entity whose operations have been secured, the entity security policies also apply to the view object.
Oracle Fusion Data Security provides an implementation of a data security provider interface defined by ADF Business Components to perform the authorization check.
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 Example 49-1.
Example 49-1 Making the Oracle Fusion Data Security Provider the Data Security Provider
dataSecurityProviderClass= "oracle.apps.fnd.applcore.dataSecurity.util.FndDataSecurityProvider"
For example, the adf-config.xml file would contain the sec:JaasSecurityContext element definition shown in Example 49-2.
Example 49-2 sec:JaasSecurityContext Element Example
<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"/>
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 once 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. 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 Section 49.3.4, "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.
At design time, you can identify the various operations on a given entity object to be secured by using the entity's overview editor and going to the Security section, as shown in Figure 49-2. The overview editor exposes a set of standard operations (read, update, removeCurrentRow) as checkboxes that you can select. Based on the operations that you select, the appropriate checks are done at runtime.
This means that when you define actions in Oracle Fusion Data Security, the actions for those objects should be named as read, update, or delete to correspond to the entity object security operations that get enabled.
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 needs to be done, you must use a custom action.
Note:
The default Oracle Fusion Data Security provider implementation assumes that the object name in FND_OBJECTS for the entity being secured is the database table/view name backing this entity. If the entity is a translatable entity (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 is not sufficient, one can set a custom property on the entity object to identify an object name from the Oracle Fusion Data Security repository that should be used to secure this entity. The custom property OA_DS_BASE_TABLE should be set to accomplish this.
At runtime, for the read operation, ADF Business Components automatically invokes the Oracle Fusion Data Security Provider (which is registered with ADF Business Components in adf-config.xml when you secure the read operation on the entity object), to identify the WHERE clause (if any) that needs to be added to the SQL statement for the entity object. This is done prior to executing the query.
Once the query has been executed, ADF Business Components invokes the Oracle Fusion Data Security Provider again to perform the authorization check for standard operations, (update and removeCurrentRow), to see if the user has update and delete access to that row.
In the case of custom privilege that you define, you must create a view criteria and apply it to the view instance that you want the application module data model to filter. In either case, the user must have sufficient privileges to view the filtered rows. The action name that you define in Oracle Fusion Data Security must match the custom action specified on the entity object.
To secure the rows displayed to a user for read privilege:
In the Application Navigator, double-click the entity object.
In the overview editor for the entity object, click the General navigation tab and expand the Security section.
In the Security section, select the read action.
To secure rows displayed to a user based on a custom privilege:
In the Application Navigator, double-click the view object that you will use to filter the rows.
In the overview editor, click the Query navigation tab and expand the View Criteria section, then click Add New View Criteria to add a dummy view criteria.
Figure 49-3 shows a dummy view criteria that has been added in the overview editor for the view object.
In the Edit View Criteria dialog, create a dummy view criteria with no view criteria items and name the view criteria using the following format:
FNDDS__privilegeName__objectName__objectAlias
where:
privilegeName is the privilege 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.
Select Both for the Query Execution Mode, as shown in Figure 49-4.
The query execution mode for the dummy 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.
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 Figure 49-5.
Alternatively, you can apply the view criteria at runtime in your code by calling the view object's applyViewCriteria(viewCriteriaName) API.
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 in order to 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 privilege is applied, the instance sets corresponding to that privilege are OR'ed. When multiple privilege checks are applied, the instance sets of a privilege are AND'ed with the instance sets of another privilege. For example, for an object, for privilege priv1, the user has instance sets IS1, IS2. For the same object for privilege priv2, the user has instance sets IS3, IS4. If both priv1 and priv2 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 Example 49-3.
Example 49-3 Manually Invoking the Authorization Checking API
if(row.getSecurityHints().allowsOperation("ApprovePO").hasPermission())
// code for PO approval
else
// display error message
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.
You can test data security actions for standard (read, update, delete) or custom actions 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 action. The transient attribute can be used to control the rendering of some other attribute in the read-only view object on the page.
Example 49-4 shows the Expression Language expression to use on ADF bindings for view object attributes.
Example 49-4 Using Expression Language on View Object Attributes
#{bindings.<attrName>.hints.allows.<privilegeName>}
For example, your UI might have a button to control the grant for the UpdateEmployeeSalary privilege; the Expression Language expression on the button may be defined as shown in Example 49-5.
Example 49-5 Correct Expression Language Expression Example
#{bindings.PersonId.hints.allows.UpdateEmployeeSalary}
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 privilege. 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 Example 49-6 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 Example 49-5 with a custom action.
Example 49-7 shows the expression to use for table iterators:
Example 49-7 Using Expression Language for Table Iterators Example
#{row.hints.allows.<privilegeName>}
Do not use the expression shown in Example 49-8 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 Example 49-7 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 Example 49-9 if the view object is an updateable view object based on an entity object.
When using Groovy expressions, use the expression shown in Example 49-10 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.
Example 49-10 Groovy Expression if View Object is Read-Only Example
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());
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. Example 49-11 shows an EL expression to conditionally render the UI component for the Gender attribute:
Example 49-11 Implementing Attribute Security Example
<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>
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.
The general process for defining Oracle Fusion Data Security policies to secure business resources that you add to your Oracle Fusion application is as follows.
Identify the business resource that you want to secure:
Register your database view or table that you want to secure with Fusion Oracle Data Security.
Populate the FND_OBJECTS and FND_OBJECTS_TL tables appropriately.
Identify the conditions that you want to make available on the registered business resource:
Tip:
Conditions may be static or parameterized. For details about parameterizing conditions, see Section 49.4.2, "How to Use Parameterized Conditions When Securing a Business Object."
Populate the FND_OBJECT_INSTANCE SETS and FND_OBJECT_INSTANCE_SETS_TL tables appropriately.
Identify the actions that you want to secure this business resource:
Populate FND_FORM_FUNCTIONS and FND_FORM_FUNCTIONS_TL tables appropriately.
Group the actions appropriately to form aggregate actions:
Identify the name of the aggregate action and register it.
Register the various actions that are part of the aggregate action.
Compile the aggregate actions for faster reference.
You must do this to avoid hierarchical queries against the FND_MENU_ENTRIES table as aggregate actions may nest other aggregate actions. To compile the menus, invoke fnd_function.fast_compile or fnd_function.compile_all_from_scratch.
Note:
Menu hierarchies, such as sub-menus, are currently not supported. Menus may only include functions. This is because Seed Data Loaders do not support hierarchies at this time.
However, this step is still required as runtime queries are fired against the fnd_compiled_menu_functions table instead of the fnd_menu_entries table.
Populate FND_MENUS, FND_MENUS_TL, and FND_MENU_ENTRIES tables appropriately.
Identify the Oracle Platform Security Services (OPSS) principals (OPSS users and roles) for which you want to make policies.
OPSS principals do not exist in the database and are managed by OPSS Policy Store, which may be a third-party system.
Make appropriate aggregate action policies on the business resource to OPSS users and roles.
Policies can be made on a row instance, on the resource globally, or for a condition, which may be parameterized.
Populate the FND_GRANTS table appropriately.
This example shows how to secure a document categories business resource. The document categories business data is stored in the FND_DEMO_DOC_CATEGORIES table. Table 49-3 lists the document category definitions for the table.
Table 49-3 FND_DEMO_DOC_CATEGORIES Table Definition
| Name | Value |
|---|---|
|
CATEGORY_ID |
NOT NULL NUMBER |
|
APPLICATION_ID |
NUMBER |
|
CREATION_DATE |
NOT NULL DATE |
|
CREATED_BY |
NOT NULL NUMBER |
|
LAST_UPDATE_DATE |
NOT NULL DATE |
|
LAST_UPDATED_BY |
NOT NULL NUMBER |
|
LAST_UPDATE_LOGIN |
NUMBER |
|
NAME |
NOT NULL VARCHAR2(30) |
|
START_DATE_ACTIVE |
DATE |
|
END_DATE_ACTIVE |
DATE |
|
ATTRIBUTE_CATEGORY |
VARCHAR2(30) |
|
ATTRIBUTE1 thru ATTRIBUTE15 |
VARCHAR2(150) |
|
DEFAULT_DATATYPE_ID |
NUMBER |
Before you begin:
You must have configured your user interface project to use application user sessions to support the data security runtime. For more information about implementing application user sessions, see Section 48.2, "Configuring Your Project to Use Application User Sessions."
You must enable security on your application. For more information about enabling security, see Section 50.3.5, "How to Enforce Authorization for Securable ADF Artifacts."
To secure a business object:
Create a resource named FND_DEMO_DOC_CATEGORIES and identify its primary key as category_id.
Create a static condition named DMS_STATIC_INSTANCE_SET, which secures categories 33, 34, and 35.
The predicate for this condition is 'category_id in (33,34,35)'.
Create a dynamic condition named DMS_PARAMETERIZED_IS to secure categories, which can be identified at grant time.
The predicate for this condition is 'category_id in (&GRANT_ALIAS.PARAMETER1,&GRANT_ALIAS.PARAMETER2)', where &GRANT_ALIAS refers to the Policies table.
Identify the actions securing this entity object for read, update, and delete operations as read, update, delete. Additionally, custom actions with the names FND_DEMO_ATTACHMENT_VIEW, FND_DEMO_ATTACHMENT_UPD, and FND_DEMO_ATTACHMENT_DEL may be created for testing.
Identify aggregate actions for which policies are made for this entity:
Create an aggregate action named FND_DEMO_ATTACHMENT_VIEW for the read operation, which contains actions named read and FND_DEMO_ATTACHMENT_VIEW.
Create an aggregate action named FND_DEMO_ATTACHMENT_ADMIN, which allows a user to administer this resource. It has read, update, and delete actions. This aggregate action contains read, update, delete, FND_DEMO_ATTACHMENT_VIEW, FND_DEMO_ATTACHMENT_UPD, and FND_DEMO_ATTACHMENT_DEL actions.
Compile the menus in the database by executing:
fnd_function.compile_all_from_scratch;
Create OPSS principals.
For this example the user names created are joeUser and admin. The role names created are regularUserRole and admin.
Make policies to OPSS principals admin and regularUserRole for the FND_DEMO_DOC_CATEGORIES business resource.
Grant FND_DEMO_ATTACHMENT_ADMIN aggregate action on the resource globally to OPSS admin role.
Grant FND_DEMO_ATTACHMENT_VIEW aggregate action to regularUserRole for static DMS_STATIC_INSTANCE_SET and dynamic (DMS_PARAMAETERIZED_IS with parameters 37 and 38) conditions.
Parameterized conditions allow conditions to be specified generally but granted specifically. Parameterized conditions should be used whenever possible 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.
Example 49-12 shows how a parameterized condition can be reused.
Example 49-12 Reusing Parameterized Conditions
OIS1. Employees in a particular region.
Predicate: "&TABLE_ALIAS.REGION = &GRANT_ALIAS.PARAMETER1"
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.
Caution:
The &TABLE_ALIAS and &GRANT_ALIAS column qualifiers must be included in the predicates of all conditions in order to keep possible duplicate column names from causing collisions.
The policy parameters hold only string values so you must convert non-string values into character values.
To convert non-string values into character values:
integer- NUMBER with no decimal point. For example, 123.
To store the number in the policy PARAMETER column, use to_char() without a format mask.
float- NUMBER that can have a decimal point. For example, 123.456.
This should be stored in the canonical format, using FND_NUMBER.NUMBER_TO_CANONICAL(). (The canonical format is based on the FND_NUMBER package 'FM999999999999999999999.99999999999999999999'.)
You should use canonical format because the string must be stored in a format that doesn't need to be converted if the data is passed between systems that use different decimal characters or other number formatting.
date- DATE calendar date, optional time. For example, 2009/04/30 11:32:32.
This should be stored in canonical format, using FND_DATE.DATE_TO_CANONICAL(). (The canonical format is based on the FND_DATE package, 'YYYY/MM/DD HH24:MI:SS'.
You should use canonical format because the string must be stored in a format that doesn't need to be converted if the data is passed between systems that use different date formats.
varchar2- VARCHAR2 character string. For example, FND_THING_NAME.
This can be stored without any conversion.
However, translated values should not be stored here. This is for internal developer key values. There is no facility for having different multilingual values in different languages because predicates should not be comparing translated values.
Use the following rules when writing performance type conversions in your predicates.
Integer Equality:
Example 49-13 shows the correct Integer equality format to use.
Example 49-14 shows Integer equality formats that you should NOT use.
Example 49-14 Incorrect Integer Equality Formats
&TABLE_ALIAS.ITEM_ID = to_number(&GRANT_ALIAS.PARAMETER1) &TABLE_ALIAS.ITEM_ID = fnd_data_security.to_int(&GRANT_ALIAS.PARAMETER1)
You must use to_char() as it is built-in and performs much faster than fnd_data_security.to_init().
When used with data security parameters, to_number() causes Invalid Number exceptions. This in turn, will make SQL statements abort if the to_number() gets run on policy parameters, which store non-numeric data such as DATE or VARCHAR2 data. The policies table will almost certainly contain some non-numeric data in a policy.
It may be decided to run a to_number(&GRANT_ALIAS.PARAMETER1) in a big statement on more policy rows than intended, and filter the rest of the rows later in the execution. This will definitely cause your SQL statement to fail so therefore, you must not have to_number() around any of the policy parameters in your predicate.
Tip:
The routine fnd_data_security.to_init() was written to avoid this problem; it is basically a wrapper over to_number(), which traps the Invalid Number exception. Therefore, if the execution plan involves operating against policies that don't apply, they won't cause the whole statement to fail. However, because of performance issues, to_char() is the preferred solution.
Integer Range:
Example 49-15 shows the correct Integer range format to use.
Example 49-15 Integer Range Format
&TABLE_ALIAS.LEVEL >= fnd_data_security.to_init(&GRANT_ALIAS.PARAMETER1)
Example 49-16 shows Integer range formats that you should NOT use.
Example 49-16 Incorrect Integer Range Formats
&TABLE_ALIAS.LEVEL >= to_number(&GRANT_ALIAS.PARAMETER1) to_char(&TABLE_ALIAS.LEVEL) >= &GRANT_ALIAS.PARAMETER1
As explained previously, to_number() can fail with an Invalid Number exception if other policy rows are processed that have non-numeric parameters. to_char() does not produce the correct ordering. For example, '3' > '25'.
Float Equality:
Example 49-17 shows the correct Float equality format to use.
Example 49-17 Float Equality Format
to_char(&TABLE_ALIAS.TEMP,'FM999999999999999999999.99999999999999999999') = &GRANT_ALIAS.PARAMETER1
Example 49-18 shows Float equality formats that you should NOT use.
Example 49-18 Incorrect Float Equality Formats
to_char(&TABLE_ALIAS.TEMP) = &GRANT_ALIAS.PARAMETER1 &TABLE_ALIAS.TEMP = to_number(&GRANT_ALIAS.PARAMETER1) &TABLE_ALIAS.TEMP = fnd_data_security.to_decimal(&GRANT_ALIAS.PARAMETER1)
Using to_number() without a format could fail if the environment is set up to use comma as the decimal character and the parameter is stored with a period as the decimal character. Using to_char() without an explicit format could convert to a comma-format number, which would not match the period-format number. Because of these potential problems, you must explicitly provide the canonical format.
Float Range:
Example 49-19 shows the correct Float range format to use.
Example 49-19 Float Range Format
&TABLE_ALIAS.TEMP > fnd_data_security.to_decimal(&GRANT_ALIAS.PARAMETER1)
Example 49-20 shows Float range formats that you should NOT use.
Example 49-20 Incorrect Float Range Formats
to_char(&TABLE_ALIAS.TEMP,'FM999999999999999999999.99999999999999999999') > &GRANT_ALIAS.PARAMETER1 to_char(&TABLE_ALIAS.TEMP) > &GRANT_ALIAS.PARAMETER1 &TABLE_ALIAS.TEMP > to_number(&GRANT_ALIAS.PARAMETER1) &TABLE_ALIAS.TEMP > fnd_data_security.to_init(&GRANT_ALIAS.PARAMETER1)
You should not use to_char() because it does not order correctly.
You should use fnd_data_security.to_decimal() instead of fnd_data_security.to_init() because the data may contain decimals, which to_init() cannot handle.
Date Equality:
Example 49-21 shows the correct Date equality format to use.
Example 49-21 Date Equality Format
to_char(&TABLE_ALIAS.ACTION_DATE,'YYYY/MM/DD HH24:MI:SS') = (&GRANT_ALIAS.PARAMETER1)
Example 49-22 shows Date equality formats that you should NOT use.
Example 49-22 Incorrect Date Equality Formats
to_char(&TABLE_ALIAS.ACTION_DATE) = (&GRANT_ALIAS.PARAMETER1) &TABLE_ALIAS.ACTION_DATE = fnd_data_security.to_date(&GRANT_ALIAS.PARAMETER1) &TABLE_ALIAS.ACTION_DATE = to_date(&GRANT_ALIAS.PARAMETER1)
As mentioned previously, to_char() performs best because it is built-in. The format mask is also required to make sure the canonical format is used.
Date Range:
Example 49-23 shows the correct Date range format to use.
Example 49-23 Date Range Format
to_char(&TABLE_ALIAS.HIRE_DATE,'YYYY/MM/DD HH24:MI:SS') > (&GRANT_ALIAS.PARAMETER1)
Example 49-24 shows Date range formats that you should NOT use.
Example 49-24 Incorrect Date Range Formats
&TABLE_ALIAS.HIRE_DATE > fnd_data_security.to_date(&GRANT_ALIAS.PARAMETER1) to_char(&TABLE_ALIAS.HIRE_DATE) > (&GRANT_ALIAS.PARAMETER1) &TABLE_ALIAS.HIRE_DATE > to_date(&GRANT_ALIAS.PARAMETER1)
In this case, you can use to_char() with a format mask because the canonical format maintains proper ordering of the character domain.
For development purposes, you can use the OPSS jazn-data.xml flat file to create users and roles for testing.
Example 49-25 shows an example of the identity store in the flat file used by JDeveloper.
Example 49-25 Oracle Platform Security Services (OPSS) XML Policy Store
<?xml version="1.0" encoding="windows-1252" standalone="yes" ?>
<jazn-data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oraclass/schema/jazn-data-11_0.xsd">
<jazn-realm default="jazn.com">
<realm>
<name>jazn.com</name>
<users>
<user>
<name>admin</name>
<credentials>{903}Qh3td3z2HHlun9ROrbvE6bYJDnNaoGir</credentials>
</user>
<user>
<name>joeUser</name>
<credentials>{903}FarN3p4C9IU9PZODN5RLmrpHf45eCw+W</credentials>
</user>
</users>
<roles>
<role>
<name>adminRole</name>
<members>
<member>
<type>user</type>
<name>admin</name>
</member>
</members>
</role>
<role>
<name>regularUserRole</name>
<members>
<member>
<type>user</type>
<name>admin</name>
</member>
<member>
<type>user</type>
<name>joeUser</name>
</member>
</members>
</role>
</roles>
</realm>
</jazn-realm>
</jazn-data>
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 "Securing Oracle Fusion Applications" chapter in the Oracle Fusion Applications Administrator's Guide.
Oracle Fusion Data Security is part of Oracle Platform Security Services. Hence data security information can be obtained from security context as required while developing the application.
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 Example 49-26.
Example 49-26 Check Action Method
/** * 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)
Where DataContext is a container class that represents the resource and optionally the primary keys of that resource for which data security check needs to 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 Example 49-27.
Example 49-27 Get Security Predicate Method
/**
* 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)
Get all the actions available on a given row instance for the current user, as shown in Example 49-28.
Example 49-28 Get All Actions Available Method
/** * 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)
Get all the aggregate actions available on a given row instance for the current user, as shown in Example 49-29.
Example 49-29 Get All Aggregate Actions Method
/** * 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)
As shown in Example 49-30, static APIs are also provided in the DataSecurityAMImpl class for the above core methods that take in a DBTransaction object.
Example 49-30 Static API Examples
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 Example 49-31. The user is determined from the user session context.
Example 49-31 FUNCTION check_privilege API
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 NUMBER 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 NUMBER DEFAULT NULL,
p_instance_pk3_value IN NUMBER DEFAULT NULL,
p_instance_pk4_value IN NUMBER DEFAULT NULL,
p_instance_pk5_value IN NUMBER DEFAULT NULL
)RETURN VARCHAR2;
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 Example 49-32. The user is determined from the user session context.
Example 49-32 PROCEDURE get_security_predicate
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) */
);
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'.
Note:
'SET' mode does not support aliases.
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.
The WHERE clause associated with a given resource is constructed by doing an OR of all the predicates associated with the conditions granted to a user or role. Therefore, it is important that the predicate for a condition be efficient so that it returns as small a number of rows as possible and it also makes use of an index.
Data security should only be used when the combined predicates (Applications Code + Data Security Predicates) are efficient, and return only relevant rows. Most queries should only return either one row or just a few rows. The maximum number of rows that data security should consider operating on is 100 rows. If you are seeing performance problems with queries that apply data security to more than 100 rows, the query needs to be made more selective. Blind queries against tables secured with data security are not allowed.
Note:
Data security is not designed as a means to limit the number of rows returned; there must always be another selective WHERE clause before the data security predicate.
Condition predicates must be as fast as possible. All predicates that apply to a particular context must go into the SQL statement that gets executed, therefore, all predicates need to be efficient, whether they reject no rows, a few rows, or many rows. Any sub selects in predicates should be on well-indexed columns. Predicates must execute in linear time, doing simply indexed selects. Predicates that involve connect-by or other network, hierarchical operations are not supported. The suggested approach to hierarchical data representations is building and selecting against a compiled representation of the data.
You should use conditions rather than row instance policies. Row instance policies are policies where each policy maps to exactly one row in the resource table. They generally don't scale well because they require one policy row for every resource table row. Performance is best when the number of policies that apply in any particular context is low. Condition policies involve just one policy, which specifies an unlimited number of rows. If the normal use case would involve more than a few row instance policies, then you probably need to be change the design to use conditions.
Note:
There are no plans to provide any APIs to answer the question "What users have access to a particular function on a particular row instance?" The reason being is that the condition predicates can reference context that can be driven by the user, like profiles. The only way to answer that question would be to loop through every user and set up their context (including profiles, and so on), and then see if they had access. That is not practical given the large number of users that are possible. For the same reason, data security does not try to answer the question "Does a particular user have access to a particular function?"
Oracle Fusion Applications provides WLST (Oracle WebLogic Scripting Tool) scripts written in the Python programming language to help administrators verify that data security setup and configuration definitions are correct for a newly deployed application. Other WLST scripts 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.
Note:
The data security diagnostic scripts may be run in the WLST scripting environment or from the Diagnostic Dashboard application of any Oracle Fusion application. The Diagnostic Dashboard provides administrators with a graphical user interface to execute and monitor diagnostic tests. For more information about the Diagnostic Dashboard, see the "Standard Diagnostic Testing Administration Tasks and Tools" section in the Oracle Fusion Applications Administrator's Guide.
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 Section 49.7.2, "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 Oracle Fusion Middleware Extensions for Applications data security task flows are a set of four task flows that provide a simplified user interface for implementing role-based security in Fusion applications. Consider integrating data security task flows into an Oracle Fusion application when your application needs to support an authorized end user's ability to secure business objects in their business domain. For example, these task flows can give Human Resources managers the ability to secure employee records to grant HR representatives access to defined groups of employee records.
Oracle Fusion Middleware Extensions for Applications data security task flows use Oracle Fusion Applications security technology to implement data security policies in Oracle Fusion Applications FND tables and function security policies in the LDAP policy store. At runtime, the task flows implementation performs the necessary backend operations to both secure data exposed by a business object (data security) and to secure the user interface (function security) that displays the business objects.
The following task flows are available and may be integrated using Oracle JDeveloper:
Object-centric task flow lets the end user display and secure a single business object. The flow displays the end user's business object selection and then displays all the application roles that may be granted access to that object. This task flow simplifies the task of securing a business object across the organization.
Role-centric task flow (also called the Profile task flow) lets the end user select an application role profile and secure multiple business objects pertaining to that profile. The flow displays the end user's application role profile selection and displays all the securable business objects that the profile may access. This task flow is also called the profile task flow since every end user is assigned to a profile that corresponds to an enterprise role mapped to a hierarchy of application roles.
Note that the role-centric task flow and the object-centric task flow present the end user with different views of the same security functionality. Both enable data security and functionality security policies for permissions that the end user selects across business objects.
Instance-level task flow lets the end user select an instance of a securable business object (one row) for which they have access and then confer access rights to another user or group of users. This task flow provides a way for end users to share access rights with other members of their organization. The scope of this task flow is different from the role-centric and object-centric task flows in that security is limited to the business object instance. The business object itself must already have grants made to the end user who wishes to share access.
Role management task flow lets the end user create and edit application roles. This task flow is particularly useful when the user creates custom business objects and wishes to grant permission to that object for a custom application role.
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.
To integrate the data security task flows, follow these general steps.
Decide whether you want your application to display the task flow in the primary window or in a popup dialog.
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.
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.
Create a managed bean and define an initialization method to populate the input parameters for the data security task flows, as shown in Table 49-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.
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.
Enable function security grants to be made by the data security task flows.
Grant view permission to an application role that allows the end user to access the task flow.
Configure the application to access the domain LDAP policy store.
Table 49-4 describes the input parameters that your managed bean must initialize for each task flow.
Table 49-4 Data Security Task Flows and Their Input Parameters
| Task Flow Name | Task Flow XML | Parameters Passed | Behavior |
|---|---|---|---|
|
Object-centric task flow (also referred to as ( |
/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/ObjectLevelFT.xml |
Specify the name of the object for which the grant will be managed: objectName Specify the list of role categories from which the available application roles will be fetched: roleCategories Specify the list of securable actions to be displayed in the UI for the object: actions Specify disableViewAll Specify disableUpdateAll |
Create and manage grants to multiple application roles for a single business object. |
|
Role-centric task flow (also referred to as |
/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/ProfileTF.xml |
Specify the list of role categories from which the available application roles will be fetched: roleCategories Specify the list of securable actions to be displayed in the UI for the object: actions Specify disableViewAll Specify disableUpdateAll |
Create and manage grants to a single application role profile for multiple business objects. |
|
Instance-level task flow (also referred to as |
/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/ObjectInstTF.xml |
Specify the name of the parent object from which the object instance will be fetched: objectName Specify the primary key of the object instance for which grants will be shared: instancePk1 instancePk2 instancePk3 instancePk4 instancePk5 Specify the list of securable actions to be displayed in the UI for the object: actions Specify the ID of the customized task flow: taskflowId Specify the holder of the customized task flow parameters: parameterMap |
Confer existing grants for a single instance of a business object to another user (or user group). |
|
Role management task flow (also referred to as |
/WEB-INF/oracle/apps/fnd/ applcore/dataSecurity/ui/ taskflow/RoleManagementTF.xml |
Specify the list of role categories from which the available application roles will be fetched: roleCategories Specify the title of the task flow UI: title |
Create and edit custom application roles. |
When you integrate the task flow as a primary window, your application's task flow invokes the data security task flow using a task flow call activity. A control flow case defines the transition (identified with a particular outcome value) between your application's view activity (for the calling web page) and the call activity. A navigation button in the calling web page invokes a method on the managed bean that initializes the task flow's input parameters and returns the expected value of the control flow case outcome. Your application's task flow invokes the data security task flow through the call activity reference that matches the returned outcome.
To integrate a data security task flow with your application so it appears in the primary browser window of the application:
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.
Drop the desired data security task flow onto the task flow call activity.
Edit your application's task flow configuration file to specify the data security task flow's input parameter values on the call activity.
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.
Register the managed bean in your application's task flow configuration file.
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.
You can use a task flow call activity to call any one of the data security task flows from your application's unbounded or bounded task flow. The task flow call activity allows you to call the data security task flows located within the same or a different application.To pass parameters into the data security task flow, you specify input parameter values on the task flow call activity. These values must correspond to the input parameter definitions on the called data security task flow.
Example 49-33 shows the task flow call activity definition with a reference to the object-centric data security task flow. The task flow call activity also defines the input parameter values required by the object-centric task flow.
Example 49-33 ObjectLevelTF Reference in Calling Task Flow Configuration File
<task-flow-call id="ObjectLevelTF">
<task-flow-reference>
<document>/WEB-INF/oracle/apps/fnd/applcore/dataSecurity/ui/taskflow/
ObjectLevelTF.xml</document>
<id>ObjectLevelTF</id>
</task-flow-reference>
<input-parameter>
<name>objectName</name>
<value>#{pageFlowScope.objectName}</value>
</input-parameter>
<input-parameter>
<name>roleCategories</name>
<value>#{pageFlowScope.roleCategories}</value>
</input-parameter>
<input-parameter>
<name>actions</name>
<value>#{pageFlowScope.actions}</value>
</input-parameter>
<input-parameter>
<name>disableViewAll</name>
<value>#{pageFlowScope.disableViewAll}</value>
</input-parameter>
<input-parameter>
<name>disableUpdateAll</name>
<value>#{pageFlowScope.disableUpdateAll}</value>
</input-parameter>
</task-flow-call>
Example 49-34 shows the task flow call activity definition with a reference to the role-centric data security task flow. The task flow call activity also defines the input parameter values required by the role-centric task flow.
Example 49-34 ProfileTF Reference in Calling Task Flow Configuration File
<task-flow-call id="ProfileTF">
<task-flow-reference>
<document>/WEB-INF/oracle/apps/fnd/applcore/dataSecurity/ui/
taskflow/ProfileTF.xml</document>
<id>ProfileTF</id>
</task-flow-reference>
<input-parameter>
<name>roleCategories</name>
<value>#{pageFlowScope.roleCategories}</value>
</input-parameter>
<input-parameter>
<name>actions</name>
<value>#{pageFlowScope.actions}</value>
</input-parameter>
<input-parameter>
<name>disableViewAll</name>
<value>#{pageFlowScope.disableViewAll}</value>
</input-parameter>
<input-parameter>
<name>disableUpdateAll</name>
<value>#{pageFlowScope.disableUpdateAll}</value>
</input-parameter>
</task-flow-call>
Example 49-35 shows task flow call activity definition with a reference to the role management data security task flow. The task flow call activity also defines the input parameter values required by the role management task flow.
Example 49-35 RoleManagementTF Reference in Calling Task Flow Configuration File
<task-flow-call id="RoleManagementTF">
<task-flow-reference>
<document>/WEB-INF/oracle/apps/fnd/applcore/dataSecurity/ui/
taskflow/RoleManagementTF.xml</document>
<id>RoleManagementTF</id>
</task-flow-reference>
<input-parameter>
<name>roleCategories</name>
<value>#{pageFlowScope.roleCategories}</value>
</input-parameter>
<input-parameter>
<name>title</name>
<value>#{pageFlowScope.title}</value>
</input-parameter>
</task-flow-call>
To create the task flow call activity:
Open your application's task flow (the calling task flow) in the diagram editor.
In the ADF Task Flow page of the Component Palette, drag a Task Flow Call activity and drop it on the calling task flow.
In the ADF Task Flow page of the Component Palette, select Control Flow Case and create the control flow case between the source activity (in your calling task flow) and the call activity.
In the task flow diagram, enter the outcome value for the control flow case.
The value of the outcome must match the return value of the task flow initialization method you create in the managed bean. For details about the managed bean, see Section 49.8.2.2, "Initializing the Data Security Task Flow Using a Managed Bean."
In the Application Navigator, drag the desired data security task flow and drop it on top of the task flow call activity that is located on the calling task flow.
This action references the data security task flow as the called task flow in the <task-flow-call> definition. JDeveloper adds the task flow reference to the calling task flow's configuration file.
In the editor for the calling task flow, click the Source tab to view the new task flow reference.
In the source for the calling task flow, locate the <task-flow-call> element and create the input parameter definitions by copying and pasting from the sample code:
If you dropped the object-centric task flow (the activity references task flow <id>ObjectLevelTF</id>), add the input parameter values from Example 49-33.
If you dropped the role-centric task flow (the activity references task flow <id>ProfileTF</id>), add the input parameter values from Example 49-34.
If you dropped the role management task flow (the activity references task flow <id>RoleManagementTF</id>), add the input parameter values from Example 49-35.
Instead of copying and pasting the input parameter values from the samples, you can also use the Property Inspector to define each input parameter value. However, it is important that the input parameter values you create match the parameter names specified by the called task flow. Copying from the samples ensures the names match exactly.
Managed beans are Java classes that you register with the application in your calling task flow's configuration file. You will create a method on a managed bean to:
Initialize the input parameters of the data security task flows.
Return a value that matches the outcome of the calling task flow.
When your application runs, and the end user clicks the button in the calling web page, the method is invoked and the properties are declared, allowing the called data security task flow input parameters to be populated with the declared values.
Example 49-36 shows the additional source code that your managed bean must include to initialize the object-centric (ObjectLevelTF) task flow.
Example 49-36 Source for Populating the ObjectLevelTF Input Parameters
//Source for managed bean method to populate and pass ObjectLevelTF parameters
String objectName = "TEST_DS_EMP";
List actions = new ArrayList<ActionMap>();
//for action1
List<String> instanceSets1 = new ArrayList<String>();
instanceSets1.add("TEST_EMP_IS1");
instanceSets1.add("TEST_EMP_IS2");
instanceSets1.add("TEST_EMP_IS3");
ActionMap action1 = ActionMap.getActionMapForObjectUI("View", "VIEW_M",
"ViewPermSet", false, instanceSets1);
actions.add(action1);
//for action 2
List<String> instanceSets2 = new ArrayList<String>();
instanceSets2.add("TEST_EMP_IS2");
instanceSets2.add("TEST_EMP_IS3");
instanceSets2.add("TEST_EMP_IS4");
ActionMap action2 = ActionMap.getActionMapForObjectUI("Update", "UPDATE_M",
"UpdatePermSet", false, instanceSets2); actions.add(action2);
//populate role categories
List roleCategories = new ArrayList<String>();
roleCategories.add("Category1");
roleCategories.add("Category2");
roleCategories.add("Category3");
//set the paramters in pageflow scope
AdfFacesContext context = AdfFacesContext.getCurrentInstance();
Map pageFlowScope = context.getPageFlowScope();
pageFlowScope.put("objectName", objectName);
pageFlowScope.put("roleCategories",roleCategories);
pageFlowScope.put("actions", actions); pageFlowScope.put("disableViewAll", false);
pageFlowScope.put("disableUpdateAll", false);
Example 49-37 shows the additional source code that your managed bean must include to initialize the role-centric (ProfileTF) task flow.
Example 49-37 Source for Populating the ProfileTF Input Parameters
//Source for managed bean method to populate and pass ProfileTF parameters
List roleCategories = new ArrayList<String>();
roleCategories.add("Category1");
roleCategories.add("Category2");
List actions = new ArrayList<ActionMap>();
//for action1
List<ProfileActionObject> profileObjects1 = new ArrayList<ProfileActionObject>();
profileObjects1.add(ProfileActionObject.getProfileActionObject("View",
"TEST_DS_EMP", "VIEW_EMP_M","ViewEmpPermSet"));
profileObjects1.add(ProfileActionObject.getProfileActionObject("View",
"TEST_DS_EMP1", "VIEW_EMP1_M","ViewEmp1PermSet"));
profileObjects1.add(ProfileActionObject.getProfileActionObject("View",
"TEST_DS_EMP2", "VIEW_EMP2_M","ViewEmp2PermSet"));
ActionMap action1 = ActionMap.getActionMapForProfileUI("View", profileObjects1);
actions.add(action1);
//for action 2
List<ProfileActionObject> profileObjects2 = new ArrayList<ProfileActionObject>();
profileObjects2.add(ProfileActionObject.getProfileActionObject("Update",
"TEST_DS_EMP1", "UPDATE_EMP1_M","UpdateEmp1PermSet"));
profileObjects2.add(ProfileActionObject.getProfileActionObject("Update",
"TEST_DS_EMP2", "UPDATE_EMP2_M","UpdateEmp2PermSet"));
ActionMap action2 = ActionMap.getActionMapForProfileUI("Update",profileObjects2);
actions.add(action2);
AdfFacesContext context = AdfFacesContext.getCurrentInstance();
Map pageFlowScope = context.getPageFlowScope();
pageFlowScope.clear();
pageFlowScope.put("roleCategories", roleCategories);
pageFlowScope.put("actions", actions);
pageFlowScope.put("disableViewAll", false);
pageFlowScope.put("disableUpdateAll", false);
Example 49-38 shows the additional source code that your managed bean must include to initialize the role management (RoleManagementTF) task flow.
Example 49-38 Source for Populating the RoleManagementTF Input Parameters
//Source for managed bean method to populate & pass RoleManagementTF parameters
AdfFacesContext context = AdfFacesContext.getCurrentInstance();
Map pageFlowScope = context.getPageFlowScope();
pageFlowScope.clear();
List roleCategories = new ArrayList<String>();
roleCategories.add("Category1");
roleCategories.add("Category2");
roleCategories.add("Category3");
pageFlowScope.put("roleCategories", roleCategories);
pageFlowScope.put("title", "Role Management");
Before you begin:
Create an ADF command button component in the web page associated with the source activity of the control flow case you create in the calling task flow. When the end user clicks the button, the button will cause the data security task flow to display. You will need to configure the Action attribute of the button so a click by the end user invokes the initialization method of your managed bean.
Example 49-39 shows a command button component with an Action attribute that invokes the method initializeRoleManagement() on the bean referenced by the bean identifier roleManageBean. The name of the identifier corresponds to the managed bean declaration you create when you edit the calling task flow configuration file, as described in Section 49.8.2.3, "Registering the Managed Bean with Your Application's Task Flow."
Example 49-39 Button Component with Action Attribute to Invoke Bean Method
<af:commandButton text="Manage Roles" id="cb1"
action="#{backingBeanScope.roleManageBean.initializeRoleManagement}"/>
To populate task flow input parameters with a managed bean:
Use the New Gallery to create the managed bean class and name it for the called task flow.
For example, you might create a bean named DSRoleManage.java for the RoleManagementTF task flow.
In the class editor, create a method that you want to use to initialize the task flow input parameters.
For example, you might create a method for the RoleManagementTF task flow, initializeRoleManagement().
In the method definition, create the input parameter property definitions by copying and pasting from the sample code into the method definition:
If you want to initialize the object-centric task flow, add the input parameter property declarations from Example 49-36.
If you want to initialize the role-centric task flow (also called the Profile task flow), add the input parameter property declarations from Example 49-37.
If you want to initialize the role management task flow, add the input parameter property declarations from Example 49-38.
Copying from the samples ensures the input parameters names match those defined by the data security task flow.
In the source you pasted, edit the input parameter property definitions to specify the default values for your application.
Enter a return value for the initialization method that matches the outcome of the control flow case you specified in your calling task flow.
For example, for the outcome value "start", your method should show:
return "start";
For details about creating the control flow case in your application's task flow, see Section 49.8.2.1, "Creating a Task Flow Call Activity in Your Application's Task Flow."
To declare the manage bean in the calling task flow's configuration file, you must enter a bean identifier name, the class path for the bean, and you must specify backing bean scope. Example 49-40 uses the bean identifier roleManageBean to match the Action attribute definition specified on the button component shown in Example 49-39.
Example 49-40 Managed Bean Declaration in Calling Task Flow Configuration File
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
<task-flow-definition id="MyCallingTaskFlow">
<default-activity id="__1">CallRoleManageTF</default-activity>
<managed-bean id="__4">
<managed-bean-name id="__5">roleManageBean</managed-bean-name>
<managed-bean-class id="__2">
oracle.apps.fnd.applcore.dataSecurity.view.RoleManage</managed-bean-class>
<managed-bean-scope id="__3">backingBean</managed-bean-scope>
</managed-bean>
</task-flow-definition>
...
</adfc-config>
To register the managed bean with the calling task flow:
Open your application's task flow (the calling task flow) in the diagram editor.
In the editor for the task flow, click the Source tab.
In the source for the calling task flow, declare the managed bean by creating the <managed-bean> element similar to the sample shown in Example 49-40.
When you integrate a data security task flow as a dialog, your application's task flow invokes the task flow using an executable in the ADF Model layer. This executable is defined by JDeveloper when you drop the data security task flow as region onto a dialog component that you add to your application's calling web page. The web page the defines the region is associated with a view activity in your application task flow; no task flow control flow case is needed to invoke the data security task flow.
A popup button in the calling web page defines a listener that invokes a method on the managed bean to initialize the task flow's input parameters. The button then displays the dialog with a region that invokes the task flow using the executable defined on the calling page's definition. When the user clicks the dialog close button, a listener (for the dialog's close button) saves the end user's sections from data security UI.
To integrate the object instance task flow (ObjectInstTF) with your application so it appears in a dialog (as a secondary browser window):
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.
In the web page, drop an ADF command button component.
Drop an ADF popup component onto the button and configure a popup fetch listener to invoke an initialization method on a managed bean.
Drop an ADF dialog inside the popup component and configure a dialog listener to invoke a method to save grants made by the user.
Drop the object instance task flow as a region onto the dialog component.
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.
Create a managed bean and define a method to initialize the task flow parameters before the dialog displays.
Define another method on the managed bean to trigger the task flow save action and save the grants into the database.
Register the managed bean in your application's task flow configuration file.
When you drop a data security task flow onto a web page to create an ADF region, JDeveloper adds an af:region tag to the page. The af:region tag references an object that implements RegionModel, as shown in Example 49-42.JDeveloper also adds a task flow binding to the <executables> element of the page definition file for the page that defines the ADF region. The task flow binding provides a bridge between the ADF region and the data security task flow. It binds a specific instance of an ADF region to the data security task flow and maintains all information specific to the task flow. The taskFlowId attribute specifies the directory path and the name of the source file for the bounded task flow.To pass parameters into the data security task flow, you must specify input parameter values on the task flow binding. These values must correspond to the input parameter definitions on the called data security task flow.
Example 49-41 shows task flow binding in the page definition file with a reference to the object-instance data security task flow. The task flow binding also defines the input parameter values required by the object-instance task flow.
Example 49-41 ObjectInstTF Call Entry in Page Definition File
<taskFlow id="ObjectInstTF1"
taskFlowId="/WEB-INF/oracle/apps/fnd/applcore/dataSecurity/ui/
taskflow/ObjectInstTF.xml#ObjectInstTF"
Refresh="ifNeeded"
xmlns="http://xmlns.oracle.com/adf/controller/binding">
<parameters>
<parameter id="objectName" value="#{pageFlowScope.objectName}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="actions" value="#{pageFlowScope.actions}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="instancePK1" value="#{pageFlowScope.instancePK1}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="instancePK2" value="#{pageFlowScope.instancePK2}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="instancePK3" value="#{pageFlowScope.instancePK3}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="instancePK4" value="#{pageFlowScope.instancePK4}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="instancePK5" value="#{pageFlowScope.instancePK5}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="taskflowId" value="#{pageFlowScope.taskflowId}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="parameterMap" value="#{pageFlowScope.parameterMap}"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
</parameters>
</taskFlow>
Before you begin:
Create an ADF command button component in the web page associated with the view activity of the calling task flow. Then drop an ADF popup component in the panel that contains the button. Then drop an ADF showPopupBehavior operation onto the button and set it to the ID of the popup component. Finally, drag a dialog onto the popup component. When the end user clicks the button, the button will invoke the show popup operation. You will also need to specify a listener for both the popup component and the dialog component. These listeners invoke methods on the managed bean to initialize the input parameters and save the user selections.
Example 49-42 shows a command button component with the showPopupBehavior operation nested on the button. The popup component appears in the same panel as the button and defines the popupFetchListener property to identify the launchPolicy() method on the bean referenced by the bean identifier objectInstanceBean. The dialog component defines the dialogListener property to identify the okCreatePolicy() method on the bean referenced by the same bean identifier. The name of the identifier corresponds to the managed bean declaration you create when you edit the calling task flow configuration file.
Note that the ADF region component element shown in the example will be created when you drop the data security object instance task flow as a region.
Example 49-42 Button Component with Show Popup Operation to Invoke Dialog
...
<af:panelHeader id="phl12" text="Test Instance UI">
<af:panelGroupLayout id="pgl13" layout="horizontal">
<af:commandButton id="cb6" text="Launch Object Instance Popup"
partialSubmit="true">
<af:showPopupBehavior popupId="objInst"/>
</af:commandButton>
<af:popup id="objInst" contentDelivery="lazyUncached"
popupFetchListener="#{backingBeanScope.objectInstanceBean.launchPolicy}"
childCreation="deferred">
<af:dialog id="polDiag" modal="true" title="Object Instance UI"
affirmativeTextAndAccessKey="Save and Close" resize="on"
contentWidth="600" contentHeight="330"
stretchChildren="first"
dialogListener="#{backingBeanScope.objectInstanceBean.okCreatePolicy}">
<af:region value="#{bindings.ObjectInstTF1.regionModel}" id="r1"/>
</af:dialog>
</af:popup>
</af:panelGroupLayout>
</af:panelHeader>
To create the task flow binding definition:
Open your application's task flow (the calling task flow) in the diagram editor.
In the ADF Task Flow page of the Component Palette, drag a View activity and drop it on the calling task flow.
In the ADF Task Flow page of the Component Palette, select Control Flow Case and create the control flow case between the source activity (in your calling task flow) and the view activity.
In the task flow diagram, enter the outcome value.
The value of the outcome should match the return value of the initialization method you create in the managed bean used to populate the data security input parameters. For details about the managed bean, see Section 49.8.2.2, "Initializing the Data Security Task Flow Using a Managed Bean."
In the Application Navigator, drag the object instance task flow and drop it on top of the task flow call activity that is located on the calling task flow.
This action defines the data security task flow as the called task flow using a <task-flow-call> definition. The task flow call definition appears in the calling task flow configuration file.
In the editor for the task flow, click the Source tab to view the new task flow reference.
In the source for the calling task flow, locate the <task-flow-call> element and create the input parameter definitions by copying and pasting from the sample code:
If you dropped the object-centric task flow (activity will show task flow reference <id>ObjectLevelTF</id>), add the input parameter values from Example 49-33.
If you dropped the role-centric task flow (activity will show task flow reference <id>ProfileTK</id>), add the input parameter values from Example 49-34.
If you dropped the role management task flow (activity will show task flow reference <id>RoleManagementTF</id>), add the input parameter values from Example 49-35.
Instead of copying and pasting the input parameter definitions from the samples, you could also use the Property Inspector to define each input parameter. However, it is important that the input parameter definitions you create match the parameter names specified by the called task flow. Copying from the samples ensures the names match exactly.
Managed beans are Java classes that you register with the application in your calling task flow's configuration file. You will define two methods on a managed bean:
A popup fetch listener method to add properties to the managed bean that will initialize the input parameters of the data security task flows.
A dialog listener method to save the grants made by the end user to the database when the user closes the dialog.
When your application runs, and the end user clicks the button in the calling web page, the popup fetch listener method is invoked and the properties are declared, allowing the called data security task flow input parameters to be populated with the declared values.
Example 49-43 shows additional source code that your managed bean must include to initialize the object-instance (ObjectInstlTF) task flow.
Example 49-43 Source for Populating the ObjectInstTF Input Parameters
//Source for manaaged bean to populate and pass ObjectInstTF parameters
public void launchPolicy(PopupFetchEvent popupFetchEvent)
{
List actions = new ArrayList<ActionMap>();
ActionMap action1 = ActionMap.getActionMapForInstanceUI("View", "VIEW_EMP_M");
actions.add(action1);
ActionMap action2 = ActionMap.getActionMapForInstanceUI("Update",
"UPDATE_EMP_M");
actions.add(action2);
ActionMap action3 = ActionMap.getActionMapForInstanceUI("Create",
"CREATE_EMP_M");
actions.add(action3);
ActionMap action4 =
ActionMap.getActionMapForInstanceUI("Delete", "DELETE_EMP_M");
actions.add(action4);
ActionMap action5 =
ActionMap.getActionMapForInstanceUI("CustomFSOnlyAction",
"CUSTOMFSONLYACTION_EMP_M");
actions.add(action5);
AdfFacesContext context = AdfFacesContext.getCurrentInstance();
Map pageFlowScope = context.getPageFlowScope();
pageFlowScope.clear();
pageFlowScope.put("actions", actions);
pageFlowScope.put("objectName", "TEST_DS_EMP");
pageFlowScope.put("instancePK1", "2");
pageFlowScope.put("instancePK2", null);
pageFlowScope.put("instancePK3", null);
pageFlowScope.put("instancePK4", null);
pageFlowScope.put("instancePK5", null);
// If you want to use a customized task flow instead of people picker to select
// users, you need specify values for the taskflowId and parameterMap.
// Map<String, Object> paraMap = new HashMap<String, Object>();
// paraMap.put("pageTitle", "Custom User Selection");
// pageFlowScope.put("parameterMap", paraMap);
//Taskflow name
// pageFlowScope.put("taskflowId", "/WEB-INF/CustomDSUserTF.xml#CustomDSUserTF");
}
Example 49-44 shows the source code you must add for the method your dialog listener invokes. In this case, the method is named okCreatePolicy() to match the method invoked by the dialog listener in Example 49-42.
Example 49-44 Source for Saving the ObjectInstTF Grants
//Source for managed bean to save end user grant
public void okCreatePolicy(DialogEvent dialogEvent)
{
DataSecurityUIUtils.saveInstanceGrants(dialogEvent);
//Add your custom code if needed
}
To populate task flow input parameters with a managed bean:
Use the New Gallery to create the managed bean class and name it for the called task flow.
For example, you might create a bean named DSObjectInstance.java for the object instance task flow.
In the class editor, create a method that you want the popup listener to invoke to initialize the task flow input parameters.
For example, you might create a method launchPolicy() named for the method invoked by the popup listener (shown in Example 49-42).
In the method definition, create the input parameter property definitions by copying and pasting from Example 49-43 into the new initialization method definition.
Copying from the sample ensures the input parameters names match those defined by the object instance task flow.
In the source you pasted, edit the input parameter property definitions to specify the default values for your application.
In the class editor, create a method that you want the dialog listener to invoke to save the grants after the user closes the dialog.
For example, you might create a method okCreatePolicies() named for the method invoked by the dialog listener (shown in Example 49-42).
In the method definition, create the save operation by copying and pasting from Example 49-44 into the new save grants method definition.
Copying from the sample ensures the method saveInstanceGrants() is called exactly as shown.
To declare the manage bean in the calling task flow's configuration file, you must enter a bean identifier name, the class path for the bean, and you must specify backing bean scope. Example 49-45 uses the bean identifier objectInstanceBean to match the bean references specified in the listener properties shown in Example 49-42.
Example 49-45 Managed Bean Definition in Calling Task Flow Configuration File
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
<task-flow-definition id="MyCallingTaskFlow">
<default-activity id="__1">CallObjectInstTF</default-activity>
<managed-bean id="__4">
<managed-bean-name id="__5">objectInstanceBean</managed-bean-name>
<managed-bean-class id="__2">
oracle.apps.fnd.applcore.dataSecurity.view.DSObjectInstance</managed-bean-class>
<managed-bean-scope id="__3">backingBean</managed-bean-scope>
</managed-bean>
</task-flow-definition>
...
</adfc-config>
To register the managed bean with the calling task flow:
Open your application's task flow (the calling task flow) in the diagram editor.
In the editor for the task flow, click the Source tab.
In the source for the calling task flow, declare the managed bean by creating the <managed-bean> element similar to the sample shown in Example 49-45.
The data security task flows, once integrated into your application, behave like other web application resources secured by ADF Security. By default, ADF Security locks down application resources and therefore requires that you grant access rights to the members of the application roles for the task flows.
To grant view access to the task flows, you define a OPSS permission grant defined by the oracle.adf.controller.security.TaskFlowPermission class. Example 49-46 shows the permission definition that grants the users (identified by <grantee> in your application) view access rights to the task flows.
Note that the resources in the permission grant are identified by regular expression metacharacters .* (dot followed by an asterisk). This expression denote any number of arbitrary characters and effectively grants view rights on all task flows in the Oracle Fusion Applications data security path /WEB-INF/oracle/apps/fnd/applcore/dataSecurity/ui/taskflow/.
Example 49-46 Grant to View Data Security Task Flows
<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>
The grantee of the permission are the application roles that your application specifies. If you are using custom application roles not defined by Oracle Fusion Applications, a security manager will need to configure these application roles using Authorization Policy Manager. For example, an application role requires a role category definition.
To enable function security for the data security task flows:
In JDeveloper, open the jazn-data.xml file in the overview editor.
In the source for the jazn-data.xml file, add the permission definition shown in Example 49-46 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.
Save the jazn-data.xml file.
A grant must be added to the jazn-data.xml policy store to allow your application to provision the LDAP policy store. The LDAP policy store is secured so that only authorized applications can make API calls needed to create and update grants in the store. For this purpose, a code source grant must be made to authorize the implementation code of the data security task flows to make credential store and policy store API calls. Example 49-47 shows the code source grant where <application-name> is the application name specified in the jazn-data.xml policy store.
Example 49-47 Grant to Enable Policy Store Provisioning by Data Security Task Flow Source Code
<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>
To enable the application to access and update the domain policy store:
In JDeveloper, open the jazn-data.xml file in the overview editor.
In the source for the jazn-data.xml file, add the code source grant shown in Example 49-47 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.
Save the jazn-data.xml file.
Before you deploy the application, you need to identify the application stripe in the production environment. Once deployed, the application will make use of the application roles and security policies defined by the application stripe. Example 49-48 shows the web.xml entry to identify the existing application stripe.
Example 49-48 web.xml Parameter Identifies Deployed Application Stripe
<init-param>
<param-name>application.name</param-name>
<param-value><application-name></param-value>
</init-param>
To map the application to the deployed application stripe:
In JDeveloper, open the web.xml file in the overview editor.
In the source for the web.xml file, add the web application initialization parameter shown in Example 49-48 beneath the JPS filter.
The application name you enter must match the application name identified in the policy store definition.
Save the web.xml file.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|