Oracle® Fusion Applications Developer's Guide 11g Release 1 (11.1.1.5) Part Number E15524-01 |
|
|
View PDF |
This chapter describes how to use JDeveloper to create function security policies in a jazn-data.xml
file that an IT security manager exports from the application domain policy store. Function security authorizes end user to access securable application artifacts created using Oracle Application Development Framework (Oracle ADF).
This chapter contains the following sections:
An important principle of Oracle Fusion function security ensures that end users do not have unintended access to web pages and application resources in an application that is created using Oracle Application Development Framework (Oracle ADF).
To enable access to application resources, you can use JDeveloper to create security policies to specify "who can perform what operations on what specific application artifacts."
To create the security policy, you must consider the additional duties the end users of the application will perform and then grant the desired roles specific rights to:
Access the web pages of a custom ADF task flow that supports the duty
Initiate only those operations on the data required by the duty
Note:
Securing the data of the application requires creating data security policies. For details about creating data security policies, see Chapter 47, "Implementing Oracle Fusion Data Security."Function security controls access to securable application artifacts including ADF task flows and top-level web pages backed by ADF page definition files. Users who do not have the required privilege cannot view the task flow. For example, in a sales organization, duties such as Manage_Accounts
and Manage_Invoices
exist for roles, such as Sales_Manager
or Sales_Associate
. A function security policy might give end users who belong to the Sales_Manager
role the ability to view and edit customer invoices. Whereas, end users who do not belong to the Sales_Manager
role, may not enter the task flow.
Before you can implement function security for custom application resources, an IT security manager must export the function security definitions from an LDAP-based policy store (typically from a staging environment) into a file-based policy store that you can work with in JDeveloper. The exported file will contain the function security artifacts that will enable you to run your application and access the resources that may otherwise have been secured by predefined function security policies.
The file you receive is formatted as XML and named jazn-data.xml
. The XML definitions of the exported file comprise two major sections: an identity store to define valid end users of the application and a policy store to define the security policies that are specific to the application. Initially, only the policy store will be populated with security artifacts from the LDAP stores. The exported jazn-data.xml
file will not contain the end user identities of the enterprise, thus the identity store section will initially appear empty.
Important:
As an Oracle Fusion security guideline, do not modify the predefined function security definitions contained in thejazn-data.xml
file. Predefined security definitions include the security definitions of the Oracle security reference implementation and must not be modified. You should always add custom application roles to grant access rights. For details about restrictions when working with the file-based policy store, see Section 49.3.7, "What You May Need to Know About Actions That Developers Must Not Perform."As an security implementation guideline, you should only use Oracle JDeveloper tools to work on the exported file-based policy store, and you should not edit the security definitions directly. JDeveloper supports iterative development of security so you can easily create, test, and edit security policies that you create for Oracle ADF application artifacts.
After you customize security, you use JDeveloper to add end user identities to the identity store of the exported file for the purpose of running and testing the application in JDeveloper's Integrated WebLogic Server. You provision a few test end user identities by defining user groups and then assign those groups to application roles to simulate how the actual end users of the enterprise will access the secured application artifacts. When you deploy the application in your development environment, JDeveloper migrates the identity store you created to the embedded LDAP of Integrated WebLogic Server. The application policy store is migrated to a system-jazn-data.xml
file that aggregates the security policies definitions of all applications in your workspace.
After testing in JDeveloper, you must consult with the IT security manager to merge the LDAP-based application policy store in the staging environment with the security policies that you added to the exported jazn-data.xml
file. The staging environment is an LDAP-based Oracle WebLogic Server configured to use Oracle Internet Directory (OID) for the enterprise's application policy store and identity store (note that the stores of the staging server are LDAP-based and not file-based). Initially, the staging environment allows further testing using that server's identity store before deploying to the production environment. Thus, end user identities created in JDeveloper are not migrated to standalone Oracle WebLogic Server and are used only in Integrated WebLogic Server to test the extended application.
As an Oracle Fusion security guideline, when you secure the functions of your application, you should not modify the predefined security definitions specified by the Oracle Fusion security reference implementation. When you modify the file-based policy store, always create new security definitions.
Note:
The term protected in this chapter refers to the default Oracle Fusion application condition that denies end users access to database resources and application artifacts. In contrast, the term secured refers to resources that have been made accessible to end users through security policies created for this purpose. Therefore, a security policy specifically enables access to the resource based on the access rights it confers to the end user.To gather background information about function security, refer to these documents:
Oracle Fusion Applications Extensibility Guide
The main document addressing how to customize and extend Oracle Fusion applications. For details about how data security and function security work together to control access to the data and functions of the application, see the "Customizing Security for Business Objects and Application Artifacts" chapter.
Oracle Fusion Applications Security Guide
The main document addressing the concepts and best practices of the Oracle Fusion security approach.
Oracle Fusion Middleware Application Security Guide
The main document addressing the concepts and best practices of Oracle Platform Security Services (OPSS) upon which Oracle Fusion security is based.
Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework
Describes ADF Security, through which ADF components interact with OPSS.
Table 49-1 summarizes the function security scenarios that Oracle Fusion security supports. The "Application Developer Tasks" column of the table provides a brief description of the security artifacts involved in each scenario.
Table 49-1 Oracle Fusion Function Security Use Cases
Security Goal | Security Policy Requirement | Application Developer Tasks |
---|---|---|
Control whether the end user associated with a particular role may access a new task flow and view all the web pages of the flow. |
Create a new entitlement grant. The new task flow will be inaccessible by default (also called protected) and will require a new function security policy to grant end users access. Because the end user duty being secured is rarely addressed by grants to a single resource, the Oracle Fusion security best practice is to create entitlement grants. Entitlement grants provide the means to aggregate multiple securable resources into a named security group so that privileges for the entire group can be granted to application roles through a single statement. |
Enable ADF Security on the user interface project to protect all task flows (and the web pages they contain). Then, in the file-based policy store, create a resource definition for the task flow and assign the definition as a member of an entitlement (defined in the policy store as a permission set) that you name. Then, create the security policy by granting the entitlement to a custom application role that you either created or consulted with an IT security manager to create for you. For more information, see Section 49.3.1, "How to Create Entitlement Grants for Custom Application Roles." |
Control whether the end user associated with a particular role may access a new top-level web page. In Oracle Fusion applications, a top-level web page is one that is not contained by a task flow. |
Create a new entitlement grant. The new top-level web page will be inaccessible by default (also called protected) and will require a new function security policy to grant end users access. The ability to secure individual web pages in Oracle Fusion applications is reserved for top-level web pages backed by an ADF page definition file only. |
Enable ADF Security on the user interface project to protect all top-level web pages backed by ADF page definition files. Then, in the file-based policy store, create a resource definition for the web page and assign the definition as a member of an entitlement (defined in the policy store as a permission set) that you name. Then, create the security policy by granting the entitlement to a custom application role that you either created or consulted with an IT security manager to create for you. For more information, see Section 49.3.1, "How to Create Entitlement Grants for Custom Application Roles." |
Control whether a new task flow or a new top-level web page is publicly accessible. Publicly accessible means the application resource may accessed by guest users (those who do not need to log into the application) or it can mean to all authenticated users who are not provisioned with the privileges conferred by a custom application role. |
Create a new resource grant. The new ADF artifact will be inaccessible by default (also called protected) and will require a new function security policy to grant end users access. Because the publicly accessible artifact is a single resource, the Oracle Fusion security best practice is to create resource grants (rather than entitlement grants) for publicly accessible artifacts. |
Enable ADF Security on the user interface project to protect all ADF-backed application artifacts. Then, in the file-based policy store, grant an action (defined in the policy store as a permission) directly to the artifact. Then, create the security policy by granting the permission to a built-in OPSS application role. For more information, see Section 49.3.3, "How to Define Resource Grants for OPSS Built-In Roles." |
Determine whether the end user associated with a particular role has the right to select create, edit, or delete buttons in the displayed web page. |
Do not create a security policy. Access to user interface components, such as buttons, is not controlled by a security policy, but can be controlled by rendering the button in the user interface based on the end user's role. |
Conditionally render the component by entering ADF Security Expression Language (EL) utility methods on the For more information about rendering components using EL utility methods, see the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework. |
When you create a Fusion web application, JDeveloper creates specific files that are needed to secure the application. Additionally, when you run the Configure ADF Security wizard, JDeveloper updates these files to reflect the selections you make in the wizard.
Table 49-2 lists the file related to Oracle Fusion security that are created for you when you secure your application in JDeveloper. For more information about the security-related files, see the Oracle Fusion Middleware Application Security Guide.
Table 49-2 Oracle Fusion Application Security-Related Files
File Name | Location | Security Purpose |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
An ADF bounded task flow that you add to your application is one of the main ADF artifacts that you that you can secure. You can also directly secure top-level web pages that are backed by ADF page definitions to specify data bindings. Although you can secure a variety of application resources, implementing function security follows a similar pattern.
To implement function security:
Decide the names of custom application roles that your application will specify as the grantee of security privileges.
For information about application roles, see the "Understanding Security Concepts" part of Oracle Fusion Middleware Application Security Guide.
Optionally, ask the IT security manager to create custom application roles with the names you supply.
If a security manager creates the application roles you identify, then those custom application roles will already appear in the policy store section of the exported jazn-data.xml
file. For details about how the IT security manager creates application roles using Oracle Authorization Policy Manager, see the "Managing Security Artifacts" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
If you do not ask the security manager to create custom application roles, then you must create them in JDeveloper before you define security policies.
Consult an IT security manager to export all predefined function security policies of the application that you are customizing into a jazn-data.xml
file.
For details about how the security manager exports the application policy store, see the "Securing Oracle Fusion Applications" chapter in the Oracle Fusion Applications Administrator's Guide.
Copy the exported jazn-data.xml
file into your application workspace.
This is the file that JDeveloper will update when you create function security policies. In order for JDeveloper to use the file, copy the file to your application workspace in the <JDevAppHome>/src/META-INF
folder.
Determine which ADF artifacts should be secured and grant entitlement privileges to custom application roles to specify the access rights of end users.
Although ADF Security permits you to define function security policies for ADF artifacts using only resource privilege grants, an Oracle Fusion security best practice is to define access policies using entitlement grants except for publicly accessible application artifacts.
For details about securing application functions, see Section 49.3.1, "How to Create Entitlement Grants for Custom Application Roles."
Determine which ADF artifacts should be public and grant resource privileges to an appropriate OPSS built-in application role.
For details about making application functions public, see Section 49.3.3, "How to Define Resource Grants for OPSS Built-In Roles."
Opt into the previously defined function security policies by running the Configure ADF Security wizard to enforce OPSS authorization checking.
For details about enabling security on the user interface project, see Section 49.3.5, "How to Enforce Authorization for Securable ADF Artifacts."
Determine which user interface components you want to associate with user entitlements, and enter EL utility methods on the component to make it logically consistent with its target.
ADF does not enforce security on user interface components, such as buttons or links that navigate to securable artifacts (pages and task flows). For details about using EL utility methods, see the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Define test user identities and run the application in JDeveloper to simulate the privileges of the enterprise users who will eventually interact with the application.
For details about adding test user in JDeveloper, see Section 49.3.6, "How to Enable Authentication and Test the Application in JDeveloper."
After testing is complete, remove the test users from the jazn-data.xml
file and provide the updated jazn-data.xml
file to the IT security manager to merge the file-based policy store with the application policy store in the staging environment.
JDeveloper must not be used as an identity store provisioning tool, and you must be careful not to deploy the application with user identities that you create for testing purposes. Deploying user identities with the application introduces the risk that malicious users may gain unintended access.
For information about how the IT security manager merges the policies using Oracle Authorization Policy Manager, see the "Upgrading Oracle Fusion Applications Policies" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
The IT security manager provisions enterprise users by mapping enterprise roles defined in the staging environment identity store to the custom application roles.
For information about how the IT security manager provisions enterprise users using Oracle Authorization Policy Manager, see the "Managing Security Artifacts" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
Before running the application in the staging environment, the IT security manager must reconcile the application roles GUIDs of any data security policies that were created based on new custom application roles.
When the file-based policy store is merged, the GUIDs of application roles are not preserved. For information about how the IT security manager reconciles GUIDs using a WLST command, see the "Securing Oracle Fusion Applications" chapter in the Oracle Fusion Applications Administrator's Guide.
Continue testing the application in the staging environment before deploying the application to production and merging the policies into the production environment application policy store.
For details about how to modify the application to use the identity store and policy store of the staging environment, see Section 49.3.8, "What You May Need to Know About Testing."
You implement function security by identifying the type of resource that corresponds to the ADF artifact whose function you intend to secure. You then select a resource instance of that type and select the action that corresponds to the artifact function you intend to grant to end users. Function security aggregates these resource / action pairs as an entitlement that serves as the grantable entity. Each entitlement can include as many resource / action pairs as needed to describe a particular duty to be performed by the end user. To support this goal, entitlements can include resources of different types. To create a function security policy, you then grant the entitlement to a custom application role, also called a duty role in Oracle Fusion applications.
In cases where a resource should be publicly accessible, you will not need to aggregate multiple resources to define a particular duty. Instead, you can create a resource-based function security policy with a single resource /action pair defined as the grantable entity.
Best Practice:
Although ADF Security permits you to define function security policies for ADF artifacts using only resource privilege grants, an Oracle Fusion security best practice is to define access policies using entitlement grants except for publicly accessible application artifacts.To simplify the task of securing the functions of your application, ADF provides the ADF Security framework. ADF Security defines a containment hierarchy that lets you define a single security policy for the ADF bounded task flow and its contains web pages. In other words, the security policy defined at the level of the bounded task flow, secures the flow's entry point and then all pages within that flow are secured by the same policy. For example, a series of web pages may guide new end users through a registration process and the bounded task flow controls page navigation for the process.
Specifically, the ADF artifacts that you may secure are:
ADF bounded task flow protects the entry point to the task flow, which in turn controls the end user's access to the pages contained by the flow
The ADF unbounded task flow is not a securable application artifact and thus does not participate in OPSS authorization checks. When you need to secure the constituent pages of an unbounded task flow, you define policies for the page definition files associated with the pages instead.
ADF page definition files associated with top-level web pages and regions
For example, a page may display a summary of products with data coordinated by the ADF bindings of the page's associated ADF page definition file.
Best Practice:
Do not create entitlement grants for the individual web pages of an ADF bounded task flow. When the end user accesses the bounded task flow, security for all pages will be managed by the entitlements you create for the task flow. This supports a well-defined security model for task flows that enforces a single entry point for all end users. For additional best practice information about ADF and function security, see Section 49.3.9, "What You May Need to Know About Security Best Practices."To add function security to the application:
Determine which ADF artifacts should be secured and grant entitlement privileges to custom application roles to define the duties of end users.
Determine which ADF artifacts should be public and grant resource privileges to an appropriate OPSS built-in application role.
Opt into the previously defined function security policies by running the Configure ADF Security wizard to enforce OPSS authorization checking.
Determine which user interface components you want to associate with user entitlements, and enter EL utility methods on the component to make it logically consistent with its target.
ADF does not enforce security on user interface components, such as buttons or links that navigate to securable artifacts (pages and task flows). For details about using EL utility methods, see the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Define test user identities and run the application in JDeveloper to simulate the privileges of the enterprise users who will eventually interact with the application.
Because the particular end user duty you want to secure is rarely addressed by grants to a single resource, you define the access policy for securable ADF artifacts by creating entitlement grants. Resource grants should be used only to define publicly accessible application artifacts, as described in Section 49.3.3, "How to Define Resource Grants for OPSS Built-In Roles."
You create entitlement grants in the Entitlements Grants page of the jazn-data.xml
file overview editor. The grants you create will appear as metadata in the policy store section of the jazn-data.xml
file. This metadata defines an entitlement (identified in the XML definition as <permission-set>
) comprised of resource instance /action pairs that you select. This entitlement is a grantable entity that you then grant to a custom application role.
The list of resource types appears in the security policy overview editor. The resource type you select filters the resource instances defined within the projects of your application's workspace. The resource type selection also determines the list of available actions displayed by the overview editor. For example, when you select the Task Flow Permission resource type, the overview editor will display all of the task flows in the user interface projects that you select and also displays the view action that you can associate with the available ADF bounded task flow resources.
Table 49-3 lists the resource types displayed in JDeveloper and identifies the associated resource and actions.
Table 49-3 Resource Types of Securable ADF Artifacts
Resource Type | Supports These Resources and Actions |
---|---|
|
Defines personalize, customize, grant, edit, and view actions on ADF bounded task flows in a Fusion Web application. |
|
Defines personalize, customize, grant, edit, and view actions on regions and web pages backed by an ADF page definition file in a Fusion Web application. |
|
Not used by Oracle Fusion Applications. Data security is provided by Oracle Fusion Data Security, as described in Chapter 50, "Securing Web Services Use Cases." |
|
Defines execute, invoke, and view actions on ADF methods in a Fusion web application. |
|
Defines invoke actions on Fusion Web services. For more details about securing Web services, see Section 50.5, "Authorizing the Web Service with Entitlement Grants." |
To define an entitlement grant for a securable ADF artifact, use the Entitlement Grants page of the overview editor for the jazn-data.xml
file. This editor is also called the security policy overview editor.
Before you begin:
It may be helpful to have an understanding of ADF Security. For more information, see the "Understanding Users and Roles" chapter in the Oracle Fusion Middleware Application Security Guide.
It may also be helpful to understand the details of the ADF Security containment model. For more information, see Section 49.3.9, "What You May Need to Know About Security Best Practices."
You will need to complete these tasks:
Consult the IT security manager for the enterprise to obtain the jazn-data.xml
file that contains the predefined function security policies for your application. You must add the file to your application workspace, as explained in Section 49.2, "Function Security Implementation Process Overview."
Create application roles as described in the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
To define an entitlement grant for an ADF artifact:
In the main menu, choose Application and then Secure > Entitlement Grants.
In the Entitlement Grants page of security policy overview editor, click the Add Entitlements icon in the Entitlements list.
The overview editor displays all the resources that your application defines.
In the Resources section, click the Add Member Resource icon to add a member resource to the entitlement.
In the Select Resources dialog, select the resource from the Resource Type dropdown and then select the desired project in the Source Projects list.
The dialog displays all the projects in your application workspace.
In the Available Resources list, select the resource from and click the Add icon.
The dialog displays all the resources define by your selected project.
In the Actions lists, select the desired action for the selected resource.
Figure 49-1 shows the overview editor with the View action selected for the task flow and added to MyEntitlement.
Add other desired resources to the list.
In the Grants section of the security policy overview editor, click the Add Role Grants icon to grant the entitlement to an application role.
In the Select Application Roles dialog, select one or more custom application roles.
The dialog displays all the application roles from the jazn-data.xml
file. You must not add a grant to a predefined application role (also called duty roles in the terminology of Oracle Fusion Applications). Only select custom application roles that either you created in JDeveloper or that were created by an IT security manager for this purpose.
Click OK.
You can repeat these steps to add other resources and make grants on those resources to the same entitlement for the same custom application role.
When you use the security policy editor in JDeveloper to create an entitlement grant, JDeveloper modifies the source for the application policy store in the jazn-data.xml
file. The policy store section of the file contains a <resource-type>
definition (that identifies the actions supported for resources of the selected type), a <resource>
definition (to identify the resource instance that you selected from your application and mapped to a resource type), a <permission-set>
definition (to define the resources and actions to be granted as an entitlement), and a <grant>
definition with one or more entitlements (defined in the XML as a permission set) granted to the desired application roles (the grantee).
As Example 49-1 shows, entitlement-based security policies in the Oracle Fusion application are defined in the <jazn-policies>
element and consist of one or more entitlements granted to a single application role.
Example 49-1 Entitlement-Based Policy Definition in the jazn-data.xml File
<?xml version="1.0" ?> <jazn-data> <policy-store> <applications> <application> <name>MyApp</name> <app-roles> <app-role> <name>AppRole</name> <display-name>AppRole display name</display-name> <description>AppRole description</description> <guid>F5494E409CFB11DEBFEBC11296284F58</guid> <class>oracle.security.jps.service.policystore.ApplicationRole</class> </app-role> </app-roles> <role-categories> <role-category> <name>MyAppRoleCategory</name> <display-name>MyAppRoleCategory display name</display-name> <description>MyAppRoleCategory description</description> </role-category> </role-categories> <!-- resource-specific OPSS permission class definition --> <resource-types> <resource-type> <name>APredefinedResourceType</name> <display-name>APredefinedResourceType display name</display-name> <description>APredefinedResourceType description</description> <provider-name>APredefinedResourceType provider</provider-name> <matcher-class>oracle.security.jps.ResourcePermission</matcher-class> <actions-delimiter>,</actions-delimiter> <actions>write,read</actions> </resource-type> </resource-types> <resources> <resource> <name>MyResource</name> <display-name>MyResource display name</display-name> <description>MyResource description</description> <type-name-ref>APredefinedResourceType</type-name-ref> </resource> </resources> <!-- entitlement definition --> <permission-sets> <permission-set> <name>MyEntitlement</name> <display-name>MyEntitlement display name</display-name> <description>MyEntitlement description</description> <member-resources> <member-resource> <type-name-ref>APredefinedResourceType</type-name-ref> <resource-name>MyResource</resource-name> <actions>write</actions> </member-resource> </member-resources> </permission-set> </permission-sets> <!-- Oracle function security policies --> <jazn-policy> <!-- function security policy is a grantee and permission set --> <grant> <!-- application role is the recipient of the privileges --> <grantee> <principals> <principal> <class> oracle.security.jps.service.policystore.ApplicationRole </class> <name>AppRole</name> <guid>F5494E409CFB11DEBFEBC11296284F58</guid> </principal> </principals> </grantee> <!-- entitlement granted to an application role --> <permission-set-refs> <permission-set-ref> <name>MyEntitlement</name> </permission-set-ref> </permission-set-refs> </grant> </jazn-policy> </application> </applications> </policy-store> </jazn-data>
A common requirement of the application is that some web pages be available to all end users, regardless of their specific access privileges. For example, the home page should be seen by all visitors to the site, while a corporate site should be available only to those who have identified themselves through authentication.
In both cases, the page may be considered public, because the ability to view the page is not defined by the end users' specific privileges. Rather, the difference is whether the end user is anonymous or a known identity.
In the OPSS security model, you differentiate between the absence of security and public access to content by granting access privileges to the anonymous-role
principal. The anonymous-role
allows access to a resource by unauthenticated users, for example, guest users. To provide access to authenticated users only, the policy must be defined for the authenticated-role
principal.
The built-in OPSS role authenticated-role
stands for any authenticated user and is useful to implement authorization checks for end users who do not need to be explicitly assigned to specific custom application roles to get access to a resource. The authenticated-role
can be directly granted any resource grants.
Before you begin:
It may be helpful to have an understanding of OPSS support for public, unprotected resources. For more information, see the "Understanding Users and Roles" chapter in the Oracle Fusion Middleware Application Security Guide.
It may also be helpful to understand the details of the ADF Security containment model. For more information, see Section 49.3.9, "What You May Need to Know About Security Best Practices."
You will need to complete this task:
Consult the IT security manager for the enterprise to obtain the jazn-data.xml
file that contains the predefined function security policies for your application. You must add the file to your application workspace, as explained in Section 49.2, "Function Security Implementation Process Overview."
To grant public access to securable ADF artifact:
In the main menu, choose Application and then Secure > Resource Grants.
In the Resource Grants page of security policy overview editor, select the resource from the Resource Type dropdown and then select the desired project in the Source Projects list.
The overview editor displays all the projects in your application workspace.
In the Resources column, select the ADF artifact for which you want to grant access rights.
Tip: Click the lock icon to show only those resources that do not yet have grants.
In the Granted to column, click the Add Grantee icon and choose Add Application Role.
In the Select Application Roles dialog, select one of these built-in application roles:
anonymous-role means the resource will be accessible to anyone who visits the site. A grant to this role is necessary if you want to make web pages backed by securable ADF artifacts accessible before an end user logs in. For example, you would grant to anonymous-role
for an ADF bounded task flow that manages customer registration.
authenticated-role means the resource will be accessible only to authenticated users (ones who visit the site and log in). For example, you would grant to authenticated-role
for an ADF bounded task flow that manages employee registration.
In the Select Application Roles dialog, click OK.
In the Resource Grants page of the overview editor, in the Actions column, select the desired action.
Figure 49-2 shows the overview editor with the View action selected for the task flow and granted to authenticated-role.
When you use the security policy editor in JDeveloper to create a resource grant, JDeveloper modifies the source for the application policy store in the jazn-data.xml
file.
Example 49-2 shows a resource-based security policy in the jazn-data.xml
file that makes a customer registration task flow public to all authenticated users. The grant to the OPSS built-in role authenticated-role
contains a single view permission for a bounded task flow, customer-registration-task-flow
. With this grant, any authenticated user will be able to enter the employee registration task flow.
Example 49-2 Resource-Based Policy Definition in the jazn-data.xml File
<policy-store> ... <jazn-policy> <grant> <grantee> <principals> <principal> <class>oracle.security.jps.internal.core. principals.JpsAuthenticatedRoleImpl</class> <name>authenticated-role</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.controller.security.TaskFlowPermission</class> <name>/WEB-INF/customer-registration-task-flow.xml# customer-registration-task-flow</name> <actions>view</actions> </permission> ... </permissions> ... </grant> ... </jazn-policy> </policy-store>
You run the Configure ADF Security wizard to enable authorization and make the function security policies you define effective. When you run the Configure ADF Security wizard, it has the following affect:
It configures your application to enable OPSS security when running in the JDeveloper test environment.
It allows the Integrated WebLogic Server to use the file-based security policies to authorize access to application resources by the end user (where OPSS determines at runtime whether the end user (represented by the JAAS subject) has the privileges necessary to access the resources they intend.
Once you run the wizard, you are effectively enforcing authorization checking for all securable ADF artifacts. The wizard also enables the ADF authentication servlet to require the end user to log in the first time a page in the application is accessed.
This configuration requires a valid user in order to access the pages of your application. This assumes that you will define custom application roles and assign explicit grants to those roles to manage access to securable ADF artifacts, as described in Section 49.3.1, "How to Create Entitlement Grants for Custom Application Roles." Alternatively, when you want to make a page pubic and accessible by unauthenticated user, you must explicitly grant to a built-in OPSS role, as described in Section 49.3.3, "How to Define Resource Grants for OPSS Built-In Roles."
Before you begin:
It may be helpful to have an understanding of the configuration changes made by the Configure ADF Security wizard. For more information, see the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
To enforce authorization:
In the main menu, choose Application and then Secure > Configure ADF Security.
Update the wizard pages as follows:
ADF Security: Select ADF Authentication and Authorization (default), as shown in Figure 49-3. Click Next.
Authentication Type: Select HTTP Basic Authentication (default). Click Next.
Automatic Policy Grant: Select No Automatic Grants (default), as shown in Figure 49-4. Click Next.
Note:
When you select No Automatic Grants, you must define explicit grants that are specific to your application. Thetest-all
application role provides a convenient way to run and test application resources without the restricted access that ADF authorization enforces. For more information about the test-all
role, see the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.Authenticated Welcome: Do not make a selection. (The Redirect Upon Successful Authentication option should not be selected). Click Next.
Summary: Review your selections. Click Finish.
Authentication is enabled when you run the Configure ADF Security wizard, as described in Section 49.3.5, "How to Enforce Authorization for Securable ADF Artifacts." This means you when you run your application, you will be prompted to log in upon accessing any page backed by securable ADF artifacts.
To test your application, you will need to create test user identities and provision them with the custom application roles that you defined. The end user's membership in an application role defines their access privileges to the resources. If you prefer to be consistent with the Oracle Fusion standard for provisioning users and simulate how the actual end users of the enterprise access resources, you can optionally provision test users by defining enterprise roles consisting of groups of users (called job roles in Oracle Fusion applications) and then assign those groups to application roles (called duty roles in Oracle Fusion applications).
For details about creating test users, see the "Enabling ADF Security in a Fusion Web Application" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Note that if you enabled the option to grant to a test role when you run the Configure ADF Security wizard, your grants may be of the following two types:
For the task flows that you create before running the Configure ADF Security wizard, the wizard automatically assigns them to the test-all
role. You will need to remove these grants and create valid grants to your custom application roles. For each entitlement granted to a specific role, the equivalent grant to the test-all
role must be removed.
The new task flows you create after running the Configure ADF Security wizard are not granted to the test-all
role automatically. You need to manually grant the entitlements for the new task flows to your custom application roles.
Security definitions that are predefined in the Oracle Fusion security reference implementation must not be changed by developers. When modifying the file-based policy store, always create custom application roles and define new entitlement grants.
Specifically, developers must not make the following changes to the predefined security definitions of the Oracle Fusion security reference implementation.
Add or remove entitlement grants on predefined application roles (those supplied by Oracle).
Add or remove resources on predefined entitlements (those supplied by Oracle).
Add or remove actions on resources on predefined entitlements (those supplied by Oracle).
For more information about the Oracle Fusion security reference implementation, see Oracle Fusion Applications Security Guide.
When the application needs to undergo testing either in your local environment or on a staging server, the following changes will ensure that the application uses the LDAP-based identity and policy stores configured on the staging server.
To configure the deployed application to use the security repositories on the target server:
Set the application name in the web.xml
file to point to the application stripe on the target server.
Set the jps.policystore.applicationid
in the weblogic-application.xml
file to point to the application stripe on the target server.
If you want the policies to persist on the staging server after the application is undeployed, then set the jps.policystore.removal
flag in the weblogic-application.xml
file.
Note that the jps-config.xml
file in the application does not need to be modified. When the application is deployed, the staging server will have its own instance of the jps-config.xml
file which is configured through a WLST command (the reassociateSecurityStore
command). Therefore, the application jps-config.xml
file can remain unchanged.
If you use JDeveloper to deploy to the application to standalone Oracle WebLogic Server, then you must ensure the Users and Groups checkbox is not selected in the application deployment properties (Menu Application > Secure > Configure Security Deployment…), as shown in Figure 49-5.
As a security best practice, you should not migrate users and groups that you create in JDeveloper. If the Users and Groups checkbox is selected, test users and groups in jazn-data.xml
will be merged into the target server with different GUIDs than those used to grant data security privileges.
Note:
JDeveloper must not be used as an identity store provisioning tool, and you must be careful not to deploy the application with user identities that you create for testing purposes. Deploying user identities with the application introduces the risk that malicious users may gain unintended access. Instead, rely on the system administrator to configure user identities through the tools provided by the domain-level identity management system.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.
ADF implements a particular security model. Follow these rules to address problems you encounter when adding security to the application:
Bounded task flows are secured by default. Secured by default means OPSS will check authorization on all bounded task flows once ADF Security has been enabled.
Pages and page fragments backed by an ADF page definition file are also secured by default when not embedded in a bounded task flow. Keep in mind that OPSS will not check authorization for pages or page fragments that do not have a corresponding ADF page definition file.
Pages and page fragments embedded in bounded task flows will not be checked by OPSS for authorization. Instead, they are granted or denied as a single unit depending on the entitlement granted to the bounded task flow. That means those pages and page fragments do not need to be explicitly granted in the policy store.
Bounded task flows embedded in bounded task flows will by checked by OPSS for authorization.
ADF does not enforce security on user interface components, such as buttons or links) that navigate to securable artifacts (pages and task flows). An explicit EL expression must be attached to the component to make it logically consistent with its target.
The test-all
role is just a means of not breaking the application once ADF Security is enabled. Therefore, it should never be deployed, since it grants access to the application for non-authenticated users.