The ADF Security model for securing Fusion web application resources is not based on the URL mapping of a security constraint as exemplified by the Java EE security model. In actual practice, security constraints are not feasible for securing a JavaServer Faces (JSF) web application where page navigation is not supported by specific page URLs. For example, when the user navigates to the next page in a task flow, the URL remains the same throughout the flow. As each new page is displayed, there is no means to trigger a URL-based security constraint.

Instead, ADF Security implements a Java Authentication and Authorization Service (JAAS) security model. The JAAS model is policy-based since JAAS is built on the existing Java security model and integrates with any JAAS implementation, including the Oracle Platform Security Services (OPSS) implementation of the JAAS service. Whereas applications that utilize URL security constraints are security-unaware because they rely on the Java EE container to manage security, Fusion web applications require an explicit call to the ADF Security framework to authorize access to resources based on user-defined policies. Thus, when you enable ADF Security and define access policies for ADF resources, your application is security-aware.

ADF Security simplifies the implementation of a JAAS authorization model. This implementation minimizes the work needed to create a security-aware application by exposing security policies on ADF resources in a declarative fashion and performing authorization checks on these resources at runtime.

The policy store in JDeveloper is file-based and contains a list of entries known as grants, which define the security policy for the ADF resource. The grant entry includes all the permissions granted to the user to perform operations on the protected resource, for instance, accessing a web page associated with an ADF bounded task flow. Permissions are granted in the policy store to an application role principal.

ADF Security expands on the JAAS model by allowing you to define grants using the actions specified by the ADF Security framework permission classes. These classes are specific to the ADF resource and map the actions to an operation supported by the resource. The policy store for the Fusion web application therefore contains grants that specify:

• One or more permissions that associate an action defined by the resource's permission class with an instance of the ADF resource in the application (currently, only the view action is supported for bounded task flows and page definitions resources)

• The grantee, which is an application role defined by your application that you populate with member users or, optionally, enterprise roles for whom you wish to confer the same access rights

In the case of entity objects, the permission class defines read, delete, and update actions that correspond to the read, removeCurrentRow, and update operations of the entity object.

For a description of the ADF permission classes and supported actions, see ADF Security Permission Grants.

The use of ADF Security enables web applications to easily adjust to real-world business security requirements, because rather than securing paths to application resources, you secure the view operation on ADF resources with JAAS. JAAS-based ADF Security provides:

• Declarative security support for ADF resources, such as the bounded task flow

  Because Java EE security is URL-based or page-based, it is not possible to have a navigation control without custom code. With ADF Security, you can control whether or not the user can enter a task flow. Thus, a single security policy for a task flow can control access to multiple web pages. Additionally, because declarative security lets you secure the ADF resource, not the access path, you can reuse the ADF resource elsewhere in the application and it will remain secured.

• Simplified permission assignment by using application roles that allow for the inheritance of permissions

  While Java EE security roles that are used by Java EE security constraints are flat, JAAS permissions are granted to application roles, which can be nested and may be mapped to enterprise roles that the Oracle WebLogic Server domain defines.

• Utility methods for use in EL expressions to access ADF resources in the security context

  You can use the ADF Security EL expression utility methods to determine whether the user is allowed to perform a known operation. For example, you can determine whether the user is allowed to view a particular task flow.

Additionally, JDeveloper enables you to quickly create test users and passwords to test security in Integrated WebLogic Server. When you are ready to deploy to Oracle WebLogic Server, you can migrate the application-specific authorization policies to the server and the administrator can configure the application to use an LDAP user repository.

Table 47-1 summarizes the effect that enabling ADF Security has on the application and the various ADF security-aware resources. For further discussion about how you can work most effectively with ADF Security, see Best Practices for Working with ADF Security.

You may find it helpful to understand other Oracle ADF features before you start working with ADF Security. Following are links to other functionality that may be of interest.

• To understand the security features of Oracle Platform Security Services, see Introduction to Oracle Platform Security Services in Securing Applications with Oracle Platform Security Services.

1. In the main menu, choose Application and then Secure > Configure ADF Security.
2. In the ADF Security page, leave the default ADF Authentication and Authorization option selected. Click Next.

   When you run the wizard with the default option selected, your application will enforce authorization for ADF security-aware resources. Enforcing authorization for ADF resources means that you intend to define security policies for these resources to make the web pages of your application accessible. Until you do so, all pages that rely on the ADF bounded task flows and ADF page definitions will remain protected.

   The other two wizard options to configure ADF Security should not be used when you want to enable ADF Security. Those options allow you to temporarily disable ADF Security and run your application without security protection, as described in Disabling ADF Security.

   Specifically, the first page of the wizard lets you choose among three options, with the default option set to enable ADF Authentication and Authorization, as shown in Figure 47-2:

   • ADF Authentication and Authorization (default) enables the ADF authentication servlet so that you can redirect to a configured web page when the user logs in and logs out. This option also enables ADF authorization to enforce authorization checking against security policies that you define for ADF resources. This option assumes that you will define application roles and assign explicit grants to those roles to manage access to ADF security-aware resources.

   • ADF Authentication enables the ADF authentication servlet to require the user to log in the first time a page in the application is accessed and supports page redirect by mapping the Java EE application root "/" to the a Java EE security constraint that will trigger user authentication. Since the wizard disables ADF authorization, authorization checking is not performed, whether or not security policies exist for ADF resources. Once the user is logged in, all web pages containing ADF resources will be available to the user.

   • Remove ADF Security Configuration disables the ADF authentication servlet and prevents ADF Security from checking policy grants without altering the existing policy store. In this case, you may require users to log in, become authenticated, and test access rights against URL security constraints using standard Java EE security. Note that running the wizard with this option disables fine-grained security against ADF resources.

   Figure 47-2 Using the Configure ADF Security Wizard to Enable Security-Aware Resources

   
   Description of "Figure 47-2 Using the Configure ADF Security Wizard to Enable Security-Aware Resources"
3. In the Authentication Type page, select the authentication type that you want your application to use when the user submits their login information. Click Next.

   A known issue prevents the ADF authentication servlet from working with Basic type authentication and allows a user to access resources after logout. Use form-based authentication instead of basic authentication. For details about this issue, see What You May Need to Know About Fusion Web Application Logout and Browser Caching.

   If you select Form-based Authentication, you can also select Generate Default Pages to allow the wizard to generate a default login and error page. By default the wizard generates the login and error pages at the top level of the user interface project, as shown in Figure 47-3. If you want to change the location, specify the full path relative to the user interface project.

   Figure 47-3 Using the Configure ADF Security Wizard to Generate a Simple Login Page

   
   Description of "Figure 47-3 Using the Configure ADF Security Wizard to Generate a Simple Login Page"
4. In the Automatic Policy Grants page, leave the default No Automatic Grants option selected. Click Next.

   When you select No Automatic Grants, you must define explicit grants that are specific to your application. The test-all application role provides a convenient way to run and test application resources without the restricted access that ADF authorization enforces. However, it increases the risk that your application may leave some resources unprotected.

   Alternatively, you can use the wizard to grant to the test-all application role. When you enable grants to the test-all role, you can postpone defining explicit grants to ADF resources until you are ready to refine the access policies of your application. If you decide to enable automatic grants, do not let application development progress too far and the content of the application become well-established before you replace grants to the test-all role with the your application's explicit grants. The explicit grant establishes the necessary privilege (for example, view on a page) to allow users to access these resources. For more information about the test-all role, see How to Use the Built-In test-all Application Role.

5. In the Authenticated Welcome page, select Redirect Upon Successful Authentication to direct the user to a specific web page after they log or to define a default destination page after the session is lost due to session timeout. Click Next.

   If you leave the Redirect Upon Successful Authentication option unselected and your application does not explicitly handle login redirect through the AuthenticationService API, then by default the user will be returned to the page from which the login was initiated. However, when the user presses Ctrl-N or Ctrl-T to open a new browser window or tab, they will receive a 403 or 404 error unless a welcome page definition appears in the application's web.xml file. You can use this option to specify a welcome page so the definition appears in the application's web.xml file.

   Note that if the web page you specify contains ADF Faces components, you must define the page in the context of /faces/. For example, the path for adffaces_welcome.jspx would appear in the Welcome Page field as /faces/adffaces_welcome.jspx.

   For details about specifying other redirect options, see How to Redirect a User After Authentication.

6. In the Summary page, review your selections and click Finish.

After you run the Configure ADF Security wizard with the default ADF Authentication and Authorization option selected in the ADF Security page, you will have:

• Enabled ADF authentication to prompt the user to log in and to allow page redirects

• Enabled ADF authorization checking so that only authorized users will have access to ADF resources

The wizard updates all security-related configuration files and ensures that ADF resources are secure by default. Table 47-2 shows which files the Configure ADF Security wizard updates.

Because authentication is delegated to the web container, the wizard only updates the web.xml file to enable the ADF authentication servlet to trigger authentication dynamically. It defines servlet mapping for the ADF authentication servlet and adds two Java EE security constraints, allPages and adfAuthentication, to the web.xml file, as shown in the following example.

<servlet>
   <servlet-name>adfAuthentication</servlet-name>
   <servlet-class>
        oracle.adf.share.security.authentication.AuthenticationServlet
   </servlet-class>
   <init-param>
      <param-name>success_url</param-name>
      <param-value>faces/welcome</param-value>
   </init-param>
   <init-param>
      <param-name>end_url</param-name>
      <param-value>faces/welcome</param-value>
   </init-param>
   <init-param>
      <param-name>disable_url_param</param-name>
      <param-value>true</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>
...
<servlet-mapping>
   <servlet-name>adfAuthentication</servlet-name>
   <url-pattern>/adfAuthentication</url-pattern>
</servlet-mapping>
...
<security-constraint>
   <web-resource-collection>
        <web-resource-name>allPages</web-resource-name>
        <url-pattern>/</url-pattern>
   </web-resource-collection>
   <auth-constraint>
        <role-name>valid-users</role-name>
   </auth-constraint>
</security-constraint>
<security-constraint>
   <web-resource-collection>
        <web-resource-name>adfAuthentication</web-resource-name>
        <url-pattern>/adfAuthentication</url-pattern>
   </web-resource-collection>
   <auth-constraint>
        <role-name>valid-users</role-name>
   </auth-constraint>
</security-constraint>

The servlet initialization attributes defined by the init-param elements shown in the example control redirects for successful login and logout (respectively, success_url and end_url). These init-param elements provide a default or fallback destination when the application does not specify the redirect target during login and logout. In this sense, they define a fixed destination whitelist on the ADF authentication servlet that prevents unvalidated redirects from occurring. The servlet initialization attribute disable_url_param may be optionally added to the web.xml servlet init-param list to block passing success_url and end_url on the browser URL and provides a level of protection against malicious redirect attacks that might exploit these parameters on the browser URL. This redirect protection works especially well when the application uses the AuthenticationService API to support login and logout redirects, which stores the redirect URL parameters as session attributes that may not be changed by the user.

Note that the protection provided by the servlet init-param element disable_url_param must be opted into and is not enabled by default. Existing applications that rely on the legacy approach of passing redirect parameters on the browser URL Request should not enable the disable_url_param attribute. For new applications, it is recommended that you opt in as the example shows (disable_url_param set to true), to block the usage of success_url and end_url on the browser URL.

Because the allPages constraint maps to the '/' URL, it protects the Java EE application root. This mapping enables the Oracle WebLogic Server web container to trigger user authentication dynamically even before ADF Security is accessed. When the user first accesses the application, it forces the container to challenge the user for the user name and password. Then when the user accesses a page protected by ADF Security, there is no longer a need to authenticate the user and no need to redirect to the ADF authentication servlet.

Because every user of the application is required to be able to log in, the security constraint defined against the adfAuthentication resource allows all users to access this web resource. As such, the security role associated with the constraint must encompass all users. To simplify this task, the Java EE valid-users role is defined. The weblogic.xml file maps this role to an implicit users group defined by Oracle WebLogic Server. This mapping ensures that every user will have this role because Oracle WebLogic Server configures all properly authenticated users as members of the users group, as described in What You May Need to Know About the valid-users Role.

To enable authorization, the wizard updates the adf-config.xml file and sets the authorizationEnforce parameter in the <JaasSecurityContext> element to true, as shown in the following example.

<JaasSecurityContext 
  initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory"
  jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext"
                             authorizationEnforce="true"
                             authenticationRequire="true"/>

When authorization is enabled, the ADF Security Context gets the user principal from the HttpServletRequest once the user is authenticated by the container. The user submits a user name and password and that data is compared against the data in the identity store where user information is stored. If a match is found, the originator of the request (the user) is authenticated. The user principal is then stored in the ADF Security Context, where it can be accessed to obtain other security-related information (such as the group the user belongs to) in order to determine authorization rights. For details about accessing the ADF Security Context, see Getting Information from the ADF Security Context.

The wizard-generated login and error pages are simple HTML pages that are added to the top-level folder of your user interface project. The generated login page defines an HTML form that will submit the user's login request with the standard j_security_check action. This action together with form-based authentication, which is the default option for container authentication provided by the wizard, allows the web container to authenticate users from many different web application resources.

The wizard updates the web.xml file to specify form-based authentication and identify the location of the pages, as shown in the following example.

<login-config>
   <auth-method>FORM</auth-method>
   <form-login-config>
       <form-login-page>/login.html</form-login-page>
       <form-error-page>/error.html</form-error-page>
   </form-login-config>
</login-config>

Your application will display the wizard-generated login page from a server-side redirect in response to the unauthenticated user attempting to access a protected resource. This is known as implicit authentication because the redirect to the login page only occurs when user navigates to a page that contains an ADF security-aware resource.

Note that web applications also have a notion of public pages and allow for explicit, as well as implicit authentication. This means that users should be able to log in to the application by clicking a login link before they navigate to secured content. For information about creating and using a login link, see Creating a Login Page.

The first time you run the Configure ADF Security wizard and enable authentication and authorization, you secure ADF resources at the level of the application. Additionally, you select specific project-level settings for the user interface project, including the authentication type and the authentication welcome. The wizard adds these web application settings to the web.xml file in the project you select. When your application contains multiple user interface projects and web.xml files, you can return to the wizard and configure these settings in the web.xml file for another user interface project that you select.

Fusion web applications that use Java EE container-managed authentication for login and ADF authentication for logout integrate with Oracle Single Sign-On (Oracle SSO) with no special requirements. The ADF authentication servlet handles the details of logout and invalidates the user session. However, when the application uses login and logout methods provided by Servlet 3.0, Oracle SSO is not supported. Additionally, Servlet 3.0 login and logout is only compatible with application servers that fully support Java EE 6 or later.

On the first access to a page that relies on an ADF security-aware resource, when the user is not yet logged in, the application server creates a session and the JpsFilter, configured in the web.xml when you run the Configure ADF Security wizard, creates a subject containing the anonymous user principal and the anonymous-role role principal. With this role principal, the anonymous user session allows the unauthenticated user to access public web pages that are not associated with any ADF security-aware resources (including ADF bounded task flows or page definitions). Upon login, WebLogic Server does not invalidate the existing anonymous user session, and for security reasons, only creates a new session ID for the authenticated user session.

In the case of pages associated with ADF security-aware resources, you must explicitly grant view permission to anonymous-role to make the page accessible to the anonymous user. For details about granting privileges to the anonymous user, see How to Make an ADF Resource Public.

The Configure ADF Security wizard lets you enable automatic grants to the built-in test-all application role for the purpose of granting view permission to all ADF security-aware resources in your application. Without a permission grant, either an automatic view grant or an explicit grant that you define, ADF Security authorization checking enforcement would prevent you from being able to run the application and access its resources. You can run the wizard with the test-all application role feature enabled and then gradually replace automatic view grants with explicit grants. Be aware that you must not deploy the application with grants to the test-all application role in place, since this feature makes all ADF resources public. If you choose to enable the built-in test-all application role in the wizard, see How to Remove the test-all Role from the Application Policy Store, before deploying your application.

The valid-users role is a Java EE security role defined by ADF Security to ensure that all users will access the adfAuthentication servlet web resource defined in the web.xml file. The Configure ADF Security wizard updates the weblogic.xml file to map this ADF Security role to the users principal, as shown in the following example. This mapping ensures that every user will have this role, because Oracle WebLogic Server configures all properly authenticated users as members of the users group.

<security-role-assignment>
   <role-name>valid-users</role-name>
   <principal-name>users</principal-name>
</security-role-assignment>

At runtime, the users principal is added automatically to a successfully authenticated subject by OPSS. From a security perspective, the valid-users role supports ADF authentication only in the case where you need to control access to web resources using security constraints alone. The end result of this mapping relies entirely on Java EE security and does not involve JAAS Permissions.

1. In the main menu, choose Application and then Secure > Application Roles.
2. In the Application Roles page of the jazn-data.xml overview editor, select the policy store for your application from the Security Policy dropdown list.

   The policy store that JDeveloper creates in the jazn-data.xml file is automatically based on the name of your application.

3. In the Roles list, click the New icon.
4. In the Name field, enter the name of the role and click any other field to add the application role to the policy store.
5. If you have already set up test users in the identity store, you can map users and roles, as described in How to Associate Test Users with Application Roles.

When you add an application role to the policy store, JDeveloper updates the jazn-data.xml file located in the src/META-INF directory relative to the application workspace. Application roles are defined in <app-role> elements under <policy-store>, as shown in the following example. Because the policy store <application> element names the application, at runtime all application roles that you create will be visible to your application only. Other web applications may define a policy store with their own set of application roles.

<policy-store>
     <applications>
         <application>
            <name>SummitADFTaskFlows</name>
            <app-roles>
               <app-role>
                  <name>Application Employee Role</name>
                  <display-name>Application Employee Role</display-name>
                  <class>oracle.security.jps.service.policystore.
                                                        ApplicationRole</class>
               </app-role>
               ...
            </app-roles>
            <jazn-policy>
              ...
            </jazn-policy>
         </application>
    </applictions>
</policy-store>

An enterprise role is a role that is maintained in the domain identity store (as opposed to an application identity store). Enterprise roles are available to every application deployed in the domain and are therefore also called external roles.

An application role is a role used by a Fusion web application. It is specific to the application, defined by the application policy, and not necessarily known to the Java EE container. Application roles are scoped in the sense that they can contain only users and roles defined in the application. Application roles must be mapped to enterprise roles.

You use the overview editor for the jazn-data.xml file to create enterprise roles to group users that you add to the identity store. You can use this mechanism to assign entire groups of users to application roles that you have defined for the purpose of conferring access rights defined by ADF security policies, as described in How to Associate Test Users with Application Roles.

However, Integrated WebLogic Server does not require you to create enterprise roles to run the application within JDeveloper. For the purpose of testing the application, it may be sufficient to create a few test users and assign them directly to application roles. When you run the application in JDeveloper, the users and any enterprise roles you defined will be created in the default security provider (which is embedded LDAP for Integrated WebLogic Server).

Typically, when you deploy the application for staging, you will migrate only the policy store to the target server. You can configure JDeveloper deployment options so that the identity store, including test users and enterprise roles, is not migrated, as described in How to Configure, Deploy, and Run a Secure Application in JDeveloper.

After you deploy the secure application, Oracle Fusion Middleware will merge your application's policy store with the policies of the domain-level policy store. To complete this task, the administrator for the Oracle WebLogic Server will eventually map the application roles of your policy store to the existing domain-level enterprise roles. This application role mapping at the domain level allows enterprise users to access application resources according to the ADF security policies you have defined. The domain-level application role mapping by the administrator also allows you to develop the ADF security policies of your application without requiring any knowledge of the identity store in the production environment.

1. In the main menu, choose Application and then Secure > Resource Grants.
2. In the Resource Grants page of the overview editor for security policies, select one of the following resources from the Resource Type dropdown list:

   • Task Flow when you want to make a bounded task flow public. The application displays the web pages under the permission you define for the task flow itself. Thus, all constituent web pages of the bounded task flow will become public.

   • Web Page when you want to make individual web pages public. Typically, these pages are defined by an unbounded task flow and are top-level pages in the application, such as a home page.

3. In the Resources column, select the ADF resource for which you want to grant access rights.

   The resource you select should display the lock icon in the first column next to the resource name. The lock icon indicates that the resource has no security policy defined and therefore is "locked"—which means it remains inaccessible to users until you define a grant. For example, in Figure 47-4, the ADF resource customer-registration-task-flow (a bounded task flow) shows the lock icon since no grant has been made.

   Tip:

   Click the key toggle icon in the header for the overview editor's first column to hide or show resources that already have grants and display only the resources without grants. The key icon indicates that the resource has a grant that will make the resource accessible to users with sufficient access rights.

   Figure 47-4 Selecting an ADF Security-Aware Resource in the Overview Editor

   
   Description of "Figure 47-4 Selecting an ADF Security-Aware Resource in the Overview Editor"
4. In the Granted to column, click the Add Grantee icon and choose Add Application Role.
5. 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 a web page associated with an ADF security-aware resource accessible before a user logs in. For example, you would grant to anonymous-role for a 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 employee registration task flow.

6. In the Select Application Roles dialog, click OK.
7. In the Resource Grants page of the overview editor, in the Actions column, leave the view action selected.

   By default, the overview editor shows view selected, as shown in Figure 47-5. The view action is the only action currently supported for Fusion web applications.

   Figure 47-5 Granting to anonymous-role in the Overview Editor

   
   Description of "Figure 47-5 Granting to anonymous-role in the Overview Editor"

When you define a security policy, the overview editor for security policies updates the jazn-data.xml file located in the /src/META-INF node relative to the web application workspace.

The overview editor writes the policy information to the <policy-store> section of the file. The security policy, or grant, contains both a grantee and one or more permissions. The grantee is the application role that the policy is being defined for—in this case, the anonymous role. Each permission defines the resource being secured and the action that can be performed against that resource.

The following example shows a security policy in the jazn-data.xml file that makes a customer registration task flow public. The grant to anonymous-role contains a single view permission for a bounded task flow, customer-registration-task-flow. With this grant, all users will be able to enter the customer registration task flow and complete the customer registration process. Additional grants to the anonymous role may be made and will appear in the <permissions> section of the anonymous role grant.

<policy-store>
   ...
   <jazn-policy>
      <grant>
         <grantee>
            <principals>
                <principal>
                   <class>oracle.security.jps.internal.core.
                                         principals.JpsAnonymousRoleImpl</class>
                   <name>anonymous-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>

The anonymous-role and authenticated-role names are special roles defined by Oracle Platform Security Services (OPSS).

When you run the Configure ADF Security wizard, the wizard configures the JpsFilter definition in the web.xml file to enable support for the anonymous role. The enabled anonymous role allows ADF Security to support browsing of the site by anonymous users—those users who have not yet logged in. In contrast, the authenticated role is not declared and is always recognized by default. ADF Security supports both of these roles.

When an end user first accesses an ADF security-aware resource, the system creates a subject and populates it with the anonymous role principal. As long as the ADF security-aware resource being accessed has the view grant to anonymous role, the user is permitted access. If the anonymous role is not a grantee of the ADF resource, the user is prompted to log in. After logging in, the authenticated role is added to the subject. The wizard also adds the JpsFilter definition to the web.xml file, where remove.anonymous.role set to false ensures that the anonymous role principal is available even after the user logs in. With the authenticated role principal, the user may access resources that have an explicit grant to the authenticated role.

1. In the main menu, choose Application and then Secure > Resource Grants.
2. In the Resource Grants page of the overview editor for security policies, select Task Flow from the Resource Type dropdown list.

   The overview editor displays all the task flows that your application defines. Task flows are defined by task flow definition files (.xml) that appear in the Web Content/Page Flows node of the user interface project.

3. In the Resources column, select the task flow for which you want to grant access rights.

   The first time you make a grant to a bounded task flow, the first column should display the Resources without any grants icon (represented by a "lock") next to the task flow name. The overview editor displays the lock icon to indicate that a resource has no security policy defined and therefore is "locked"—which means it remains inaccessible to users until you define a grant.

   Tip:

   Click the Resources with grants icon (represented by a "key") in the header for the Resources column to hide all task flows that already have grants. This will display only task flows without grants, as shown in Figure 47-6. Additionally, you can type a partial task flow name in the search field to display only the task flows with character-matching names.

   Figure 47-6 Hiding Task Flows with Grants in the Overview Editor

   
   Description of "Figure 47-6 Hiding Task Flows with Grants in the Overview Editor"
4. In the Granted to column, click the Add Grantee icon and select Add Application Role.
5. In the Select Application Roles dialog, select the application role that you want to make a grantee of the permission.

   The Select Application Roles dialog displays application roles from the jazn-data.xml file. It also displays the built-in OPSS application roles, anonymous-role and authenticated-role, as described in What Happens at Runtime: How the Built-in Roles Are Used.

   If you do not see application roles that are specific to your application, create the role, as described in Creating Application Roles.

6. In the Select Application Roles dialog, click OK.
7. In the Resource Grants page of the overview editor, in the Actions column, leave the view action selected.

   By default, the overview editor shows the view action selected, as shown in Figure 47-7. The view action is the only action currently supported for Fusion web applications. Do not select customize, grant, or personalize actions—they are reserved for future use and will not be checked by ADF Security at runtime.

   The TaskFlowPermission class defines task flow—specific actions that it maps to the task flow's operations, as described in Table 47-4.

   Figure 47-7 Granting to an Application Role for a Bounded Task Flow Definition in the Overview Editor

   
   Description of "Figure 47-7 Granting to an Application Role for a Bounded Task Flow Definition in the Overview Editor"
8. You can repeat these steps to make additional grants as desired.

   The same task flow definition can have multiple grants made for different application roles. The grants appear in the policy store definition of the jazn-data.xml file, as described in What Happens When You Define the Security Policy.

1. In the main menu, choose Application and then Secure > Resource Grants.
2. In the Resource Grants page of the overview editor for security policies, select Web Page from the Resource Type dropdown list.

   The Resource Grants page of the overview editor displays all web pages, including those that have an associated ADF page definition. This includes any web page that uses ADF bindings or any web page for which you have created an empty page definition. Page definitions are defined by PageDef.xml files that appear in the Application Sources node of the user interface project.

3. In the Resources column, select the page definition for which you want to grant access rights.

   The first time you make a grant to a page definition, the first column should display the Resource without any grants icon (represented by the "lock" icon) next to the page definition name. The editor displays the lock icon to indicate that a resource has no security policy defined and therefore is "locked"—which means it remains inaccessible to users until you define a grant. For example, the page definition account_updateUserInfo shown in Figure 47-8 displays the lock icon since no grant has been made. Other page definitions in Figure 47-8 show the Page included in bounded task flow icon because they are not top-level pages and thus are securable by the containing bounded task flow.

   Do not create grants for individual web page definitions that display the Page included in bounded task flow icon. Security policies for the associated web pages are secured by their bounded task flow. For example, in Figure 47-8, the page definition associated with the account_addressDetails.jsff region will be secured by the containing bounded task flow.

   Tip:

   You can type a partial page definition name in the search field to display only the page definitions with character-matching names. For example, a search on the word general would display only the page definitions that begin with the word general, as shown in Figure 47-8.

   Figure 47-8 Matching Page Definitions by Name in the Overview Editor

   
   Description of "Figure 47-8 Matching Page Definitions by Name in the Overview Editor"

   Tip:

   You can click the Resources with grants icon (represented by the "key" icon) to hide all page definitions that already have grants. Confirm that the Show pages included in a bounded task flow toggle button in the header for the Resources column is toggled off to hide all page definitions that are included in a bounded task flow (by default, it is set to hide these pages). This will display top-level pages that have no grants (and unsecurable pages, if any), as shown in Figure 47-9.

   Figure 47-9 Hiding Web Pages with Grants in the Overview Editor

   
   Description of "Figure 47-9 Hiding Web Pages with Grants in the Overview Editor"
4. In the Granted to column, click the Add Grantee icon and select Add Application Role.
5. In the Select Application Roles dialog, select the application role that you want to make a grantee of the permission.

   The Select Application Roles dialog displays application roles from the jazn-data.xml file. It also displays the built-in OPSS application roles, anonymous-role and authenticated-role, as described in What Happens at Runtime: How the Built-in Roles Are Used.

   If you do not see application roles that are specific to your application, create the role, as described in Creating Application Roles.

6. In the Select Application Roles dialog, click OK.
7. In the Resource Grants page of the overview editor, in the Actions column, leave the view action selected.

   By default, the overview editor shows view selected, as shown in Figure 47-10. The view action is the only action currently supported for Fusion web applications.

   The actions customize, grant, or personalize are implemented for use in WebCenter Portal: Framework applications or custom applications that are enabled to use Oracle WebCenter Portal's Composer.

   The RegionPermission class defines page definition—specific actions that it maps to the page's operations, as described in Table 47-6.

   Figure 47-10 Granting to an Application Role for an ADF Page Definition in the Overview Editor

   
   Description of "Figure 47-10 Granting to an Application Role for an ADF Page Definition in the Overview Editor"
8. You can repeat these steps to make additional grants as desired.

   The same page definition can have multiple grants made for different application roles. The grants appear in the policy store definition of the jazn-data.xml file, as described in What Happens When You Define the Security Policy.

1. Create a resource grant for a custom resource type and resource.
2. Enforce the permission grant in the user interface.

<af:button actionListener="#{bindings.myMethodName.execute}" 
     text="myMethodName"
     disabled="#{!securityContext.userGrantedPermission
       ['resourceName=CancelShipmentButton,resourceType=CancelShipment,
             action=invoke']}
     id="cb1"/>

When you define a security policy, the overview editor for security policies updates the jazn-data.xml file located in the /src/META-INF node relative to the web application workspace.

The overview editor writes the policy information to the <policy-store> section of the file. The security policy, or grant, contains both a grantee and one or more permissions. The grantee is the application role that the policy is being defined for. Each permission defines the resource being secured and the action that can be performed against that resource.

The following example shows a security policy in the jazn-data.xml file that grants unauthenticated users access to an employee registration task flow and a top-level web page used to access the task flow. The grant to the anonymous-role application role contains a view permission for a bounded task flow, emp-reg-task-flow, and a view permission on the web page with the indexPageDef page definition. With this grant, unauthenticated users will be able to enter the employee registration task flow and view the welcome page.

For the web page, notice that permission has been defined on the indexPageDef page definition created for the welcome page (index.jsf). Also, note that this is a top-level web page that is not already secured by a bounded task flow.

<policy-store>
    ...
    <jazn-policy>
        <grant>
            <grantee>
                <principals>
                    <principal>
                         <name>anonymous-role</name>
                         <class>oracle.security.jps.internal.core.principals.
                                       JpsAnonymousRoleImpl</class>
                     </principal>
                 </principals>
             </grantee>
             <permissions>
                  <permission>
                      <class>oracle.adf.controller.security.TaskFlowPermission</class>
                      <name>/WEB-INF/flows/emp-reg-task-flow-definition.xml#
                                                  #emp-reg-task-flow-definition</name>
                      <actions>view</actions>
                  </permission>
                   <permission>
                        <class>oracle.adf.share.security.authorization.RegionPermission</class>
                        <name>oracle.summit.view.pageDefs.indexPageDef</name>
                        <actions>view</actions>
                  </permission>
                  ...
             </permissions>
        </grant>
        ...
    </jazn-policy>
</policy-store>

Grants that you make for ADF resources are standard JAAS Permissions. When you enable ADF Security in your application, Oracle Platform Security Service (OPSS) running in Oracle WebLogic Server will utilize the grants to allow authorization. In authorization mode, ADF Security uses fine-grained authorization, implemented with JAAS Permissions to perform security checks for access rights to pages. The ADF Security enforcement logic checks to see whether the user, represented by the JAAS subject, has the right permissions to access the resource.

The subject contains the user's principals, which include a user principal that contains their name (could be anonymous, before logging on, or some user name after logging on), and their list of role principals, which would include authenticated-role and some number of other roles that are obtained from the policy and identity stores. The principal is created to represent all of the user's memberships in application roles defined in the policy store. In turn, each application role may have multiple Permissions associated with them. These are the ADF security policies that are created through the overview editor for the jazn-data.xml file.

Before you run the application using Integrated WebLogic Server, you will need to provision the identity store with test users and add these users to the application roles that you want to configure. The application roles can define members that are specific users or groups of users (also known as enterprise roles), as described in Creating Test Users.

Then at runtime, whether the current user has view permission on the page they are trying to access will be determined by the context of the page:

• If the page is an activity of a bounded task flow, the task flow controller determines the permission.

• If the page is a top-level page with an associated page definition file, the ADF Model layer determines the permission.

Oracle Platform Security Services then checks to see whether the subject contains the roles that have the corresponding permissions needed to access the page. If the user is authorized, then the task flow is entered.

In the case of a bounded task flow and top-level pages (defined by an unbounded task flow), if the user is not authorized, ADF Controller throws an exception and passes control to an exception handler that the task flow configuration specifies. For details about specifying an error page, see How to Redirect a User After Authentication.

The default Configure ADF Security wizard option ADF Authentication and Authorization enables authorization checking and secures a web page whenever the page is associated with an ADF security-aware resource. Therefore, after you run the wizard, a web page will not be secured if both of these conditions exist:

• The page does not display databound ADF Faces components and therefore no ADF page definition exists for the page.

• The page is not a constituent page of a bounded ADF task flow. (Any page that the user accesses as a process of a bounded task flow is checked under the permission of the task flow.)

JDeveloper will generate an ADF page definition file for you whenever you design a web page using the Data Controls panel to create databound ADF Faces components. However, if your web page does not use ADF bindings, you can still create an empty page definition file by right-clicking the web page in the user interface project and choosing Go to Page Definition. The page definition file can remain empty because the page does not need to work with ADF bindings to support databound ADF Faces components.

Once you associate a web page with an ADF page definition file, empty or not, authorization checking will be enforced when the user accesses the associated web page. You can define security policies for the page as you would any other ADF page definition. For details about making grants to an empty ADF page definition, see How to Define Policies for Web Pages That Reference a Page Definition.

Before you begin:

It may be helpful to have an understanding of security for individual page definition files. For more information, see How to Define Policies for Web Pages That Reference a Page Definition.

You may also find it helpful to understand how JDeveloper normally generates page definition files. For more information, see Working with Page Definition Files.

To create an empty page definition that you can define security policies for:

1. In the Applications window, locate the web page you want to secure, right-click the node and choose Go to Page Definition.

2. In the confirmation dialog, click Yes to create a new page definition for the page.

   The page definition will be added to the pageDefs package.

When you want to define a grant that applies to multiple resources at once, you can create patterns as defined by the java.util.regex.Pattern class to form a regular expression that gets evaluated at runtime. For example, to match a grant to a set of resources, you can enter the expression .* (specifies any character zero or more times) on the name of the permission. ADF Security does not support the use of regular expressions on other security objects, such as the principal name.

You might use this feature to group bounded task flows that would have the same permissions into their own subfolders of WEB-INF and define the grant for the entire folder, as shown in the following example. In this case, the expression uses the dot character (defined as, any character) followed by the asterisk quantifier (defined as, zero or more times).

...
<grant>
   <grantee>
      <principals>
         <principal>
            <class>oracle.security.jps.service.policystore.ApplicationRole</class>
            <name>anonymous-role</name>
         </principal>
      </principals>
   </grantee>
   <permissions>
       <permission>
          <class>oracle.adf.controller.security.TaskFlowPermission</class>
          <name>/WEB-INF/.*</name>
          <actions>view</actions>
       </permission>
   </permissions>
</grant>

As the overview editor for the jazn-data.xml file does not support the use of regular expressions in the user interface, you must edit the file directly. Do not edit the policy store of the system-jazn-data.xml file directly. Instead, add grants using regular expressions to the jazn-data.xml file. These grants will then be merged to the policy store when you run or deploy the application.

The use of more complex regular expressions enables you to define business rules in the policy, thus creating a very targeted set of permissions. For example, you can grant the view permission on all page definitions and deny specific page definitions at the same time by defining an exclusion set in your regular expression. The following example shows how the view permission is granted to anonymous-role for all pages except those for which the page definition name starts with custom.

<grant>
   <grantee>
      <principals>
         <principal>
            <class>oracle.security.jps.service.policystore.ApplicationRole</class>
            <name>anonymous-role</name>
         </principal>
      </principals>
   </grantee>
   <permissions>
      <permission>
         <class>oracle.adf.share.security.authorization.RegionPermission</class>
         <name>[^(custom)].*</name>
         <actions>view</actions>
      </permission>
   </permissions>
</grant>

Table 47-7 shows some of the basic regular expression metacharacters that you can use in your policy definitions.

1. Define a permission map for the specific actions of the entity object or the attributes of the entity object that you want to secure.
2. Grant the permission to an application role that you have added to the policy store.

1. In the main menu, choose Application and then Secure > Entitlement Grants.
2. In the Entitlement Grants page of overview editor for security policies, click the Add Entitlements icon in the Entitlements section.

   The overview editor displays all the resources that your application defines.

3. In the Entitlement Grants page, click the Resources tab and then click the Add Member Resource icon to add a member resource to the entitlement.
4. In the Select Resources dialog, select the resource from the Resource Type dropdown and then select the desired project in the Source Projects section.

   The dialog displays all the projects in your application workspace.

5. In the Available Resources section, select the resource and click the Add icon.

   The dialog displays all the resources define by your selected project.

6. In the Actions lists, select the desired action for the selected resource.

   Figure 47-15 shows the overview editor with the View action selected for the task flow and added to MyEntitlement.

   Figure 47-15 Adding a Bounded Task Flow as a Resource in an Entitlement Grant

   
   Description of "Figure 47-15 Adding a Bounded Task Flow as a Resource in an Entitlement Grant"
7. Add other desired resources to the list.
8. In the Entitlement Grants page, click the Grants tab and then click the Add Role Grants icon to grant the entitlement to an application role.
9. 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.

10. Click OK.
11. 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 the following example illustrates, 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.

<?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>

When you provision the identity store with user identities and enterprise role groups, JDeveloper updates the jazn-data.xml file located in the /src/META-INF node relative to the web application workspace.

The dialog writes the user information to the <jazn-realm> section of the file corresponding to the identity store. Each user identity has a user name and a user login password. Each enterprise role contains one or more member users.

The following example shows the identity store in the jazn-data.xml file with two users and two enterprise roles. The user cmagee is a member of the Enterprise Employee Group enterprise role, while user 214 is a member of the Enterprise Customer Group enterprise role.

<jazn-data>
   <jazn-realm default="jazn.com">
      <realm>
         <name>jazn.com</name>
         <users>
            <user>
               <name>cmagee</name>
               <display-name>Colin Magee</display-name>
               <description>Sales Rep</description>
               <credentials>{903}5AUHlE+qvDxxAhxIMoXJ/WLhMF0ynue7</credentials>
            </user>
            <user>
               <name>214</name>
               <display-name>Ojibway Retail</display-name>
               <description>Customer</description>
               <credentials>{903}rijN2KQCBSeBQ/JNZlv8GwwUiGWk5IQa</credentials>
            </user>
            ...
         </users>
         <roles>
            <role>
               <name>Enterprise Employee Group</name>
               <members>
                  <member>
                     <type>user</type>
                     <name>cmagee</name>
                  </member>
               </members>
            </role>
            <role>
               <name>Enterprise Customer Group</name>
               <members>
                  <member>
                     <type>user</type>
                     <name>214</name>
                  </member>
                  ...
               </members>
            </role>
            ...
         </roles>
      </realm>
      ...
   </jazn-realm>
</jazn-data>

When you associate users with application roles, JDeveloper updates the jazn-data.xml file located in the /src/META-INF node relative to the web application workspace.

The dialog writes the user information to the <policy-store> section of the file. Each application role contains one or more member users or enterprise roles.

The following example shows the policy store in the jazn-data.xml file with the Application Employee Role application role, which contains two members, Enterprise Employee Group and Enterprise Manager Group.

<policy-store>
     <applications>
         <application>
            <name>SummitADF</name>
            <app-roles>
               <app-role>
                  <name>Application Employee Role</name>
                  <class>oracle.security.jps.service.policystore.ApplicationRole</class>
                  <display-name>Application Employee Role</display-name>
                  <members>
                     <member>
                        <class>oracle.security.jps.internal.core.principals.
                                                               JpsXmlEnterpriseRoleImpl</class>
                        <name>Enterprise Employee Group</name>
                     </member>
                     <member>
                        <class>oracle.security.jps.internal.core.principals.
                                                               JpsXmlEnterpriseRoleImpl</class>
                        <name>Enterprise Manager Group</name>
                     </member>
                     ...
                  </members>
               </app-role>
               ...
            </app-roles>
            <jazn-policy>
              ...
            </jazn-policy>
         </application>
    </applictions>
</policy-store>

1. In the Applications window, double-click the web page that will display the component.
2. In the ADF Faces page of the Components window, from the Common Components panel, drag a Link and drop it on the page.
3. In the Structure window, right-click af:link and choose Go to Properties.
4. In the Property window, to specify the label for the Link component, enter an Expression Language (EL) expression in the Text field.

   For example, you can enter an EL expression similar to this to conditionally render the link text:

   #{securityContext.authenticated ? "Click to log out" : 
                                     "Click to log in"}
   

   The authenticated property of the securityContext bean will evaluate to true and render the log out option if the current user is authenticated. Otherwise, the link is rendered with the login option.

5. In the Property window, to specify the URL for the Link component, enter an EL expression in the Destination field.

   For example, this EL expression conditionally renders a URL to forward the user depending on whether or not they are authenticated:

   #{securityContext.authenticated ? \"Logout\" : \"Login\"}" id="gl2" destination="#{securityContext.authenticated ? 
                                                  \"/adfAuthentication?logout=true\" : \"/adfAuthentication?login=true\"}
   

   When the user clicks the link, the destination will be determined by the success_url and end_url settings on the ADF authentication servlet init-param. Note that these settings should specify the view activity name instead of the web page name to ensure control flow rules are enforced for page navigation after login. The authenticated property of the securityContext bean will evaluate to true and forward to the page defined by success_url if the current user is authenticated. When the user is not authenticated, there is no need to forward to the login page because the ADF authentication servlet triggers log in, which is handled by the container-managed security configuration. Note that log out is handled by the ADF authentication servlet which invalidates the session.

6. In the Property window, to specify the link component image for the Link component, enter an EL expression in the Icon field.

   For example, this EL expression conditionally renders the link component image as the lock GIF if the user is not authenticated; otherwise, renders the image with the key GIF:

   #{securityContext.authenticated ? '/images/lock.gif' : '/images/key.gif'}
   

   Figure 47-18 shows how the login link component appears when added to the global menu facet of the page.

   Figure 47-18 Login Link Component on the Page

   
   Description of "Figure 47-18 Login Link Component on the Page"

Because web applications are generally secured, there is always a need for a starting point or home page for unauthenticated users. To create this public welcome page, you create an ADF Faces page to act as the entry point for the application, which contains links to other pages within the application. However, only links to public pages should be rendered to unauthenticated users and, conversely, links to secured pages should be rendered only after the user has logged in and has the appropriate privileges to view the target page.

<af:panelGroupLayout inlineStyle="width:100%; height:15px;" id="ptpgl3">
     <af:spacer width="7" height="10" id="pts2"/>
     <af:outputText value="Welcome #{securityContext.userName}!"
                           inlineStyle="font-weight:bold; width:100px" id="ptot2"
                           rendered="#{securityContext.authenticated}"/>
     <af:image source="#{securityContext.authenticated ? '/images/lock.gif' : '/images/key.gif'}"
               id="pti2" inlineStyle="width:16px; height:16px;" shortDesc="switchable icon"/>
     <af:link text="Logon" id="l1" action="#{securityBean.logon}"
                rendered="#{!securityContext.authenticated}"/>
     <af:link text="Logoff" id="l2" action="#{securityBean.logoff}"
                rendered="#{securityContext.authenticated}"/>
     <f:facet name="separator">
         <af:spacer width="5" height="10" id="pts1"/>
     </f:facet>
</af:panelGroupLayout>

1. In the Applications window, expand WEB-INF and double-click web.xml.
2. In the overview editor for the web.xml file, click the Security navigation tab.
3. In the Security page, expand the Login Authentication section, and set the login page to include a reference to the ADF Faces servlet such that the login page can be part of the ADF Faces lifecycle /faces/ADFlogin.jspx page.

   When you add a page using the file browser, the path entered in the web.xml file will not specify /faces. Modify the entry so that the path references the servlet mapping path for the ADF Faces servlet. For example, if the URL pattern specified by the mapping is /faces/*, then your path should look like /faces/yourpage.jspx, as shown in Figure 47-26.

   Figure 47-26 Adding a Reference to the Faces Servlet in the Login Configuration

   
   Description of "Figure 47-26 Adding a Reference to the Faces Servlet in the Login Configuration"

When the ADF authentication servlet directs the user to login, it puts the redirect destination defined by the success_url on the Session map. However, in the case where the session times out before the user has authenticated, the Session map looses the value of success_url and the application looses the ability to navigate to the destination page.

1. In the web.xml file, add the init-param named oracle.adf.share.security.authentication.connections to the ADF authentication servlet definition and specify the param_value as the connection reference name that appears in the connections.xml file, located in the adf/META-INF folder, as the following example shows.

   <servlet>
     <servlet-name>adfAuthentication</servlet-name>
       <servlet-class>
         oracle.adf.share.security.authentication.AuthenticationServlet
       </servlet-class>
       <init-param>
         <param-name>
           oracle.adf.share.security.authentication.connections
         </param-name>
         <param-value>my_connection_name</param-value>
       </init-param>
      ...
   </servlet>

2. In the connections.xml file, define the success_url and, optionally, end_url in the named connection reference, as the following example shows.

   <References xmlns="http://xmlns.oracle.com/adf/jndi">
     <Reference name="my_connection_name"
                className=
               "oracle.adf.share.security.authentication.AuthenticationConnection"
                xmlns="">
       <Factory className=
            "oracle.adf.share.security.authentication.AuthenticationConnection"/>
       <RefAddresses>
         <StringRefAddr addrType="success_url">
           <Contents>
              http://localhost:port/context_root/faces/welcomePage</Contents>
         </StringRefAddr>
         <!-- end_url for logout -->
         <StringRefAddr addrType="end_url">
           <Contents>
              http://localhost:port/context_root/faces/publicPage</Contents>
         </StringRefAddr>
       </RefAddresses>
     </Reference>
   </References>

During logout it may be necessary to redirect the user to an arbitrary web page or host server that differs from the originating server of the Fusion web application. In this scenario, the application should be protected from a malicious redirect by ensuring the destination page URL is not placed by the application on the Request and will instead use the Session map. To accomplish this, a best practice is to block passing ADF redirect parameters on the browser URL by adding the servlet init-param element disable_url_param set to true to the ADF authentication servlet definition in the web.xml file as this example shows.

<servlet>
   <servlet-name>adfAuthentication</servlet-name>
   <servlet-class>
        oracle.adf.share.security.authentication.AuthenticationServlet
   </servlet-class>
   <init-param>
      <param-name>success_url</param-name>
      <param-value>faces/welcome</param-value>
   </init-param>
   <init-param>
      <param-name>end_url</param-name>
      <param-value>faces/welcome</param-value>
   </init-param>
   <init-param>
      <param-name>disable_url_param</param-name>
      <param-value>true</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>
...

Legacy applications that were built before ADF enforced passing the redirect parameters on the Session map that would otherwise expose the parameters on the browser URL Request should not set the disable_url_param to true and should instead consider implementing a security bean using the ADF interface oracle.adf.share.security.AuthenticationService to handles ADF-specific login and logout methods by placing the target destination on the Session map.

The following example illustrates how to use the logout() method of the AuthenticationService interface. This method will internally put the passed in URL on the Session map and will ignore the end_url parameter that might explicitly be set on the URL by a user. Similarly, the login() method places the login URL destination on the Session map. When you need logout to redirect to a web page on a different server, your method implementation may pass the URL of the desired web page and still be protected from a malicious redirect.

import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import oracle.adf.share.security.AuthenticationService;
import oracle.adf.share.security.authentication.AuthenticationServiceUtil;

public class SecurityBean {
    public SecurityBean() {
        super();
    }
    
    public boolean isAuthenticated() {
        ExternalContext ectx =
                          FacesContext.getCurrentInstance().getExternalContext();
        return ectx.getUserPrincipal() != null;
    }
    
    public void logon() {
        if (!isAuthenticated())
        {
            FacesContext ctx = FacesContext.getCurrentInstance();
            AuthenticationServiceUtil.getAuthenticationService().login("/faces" +
                                       ctx.getViewRoot().getViewId(), null, null);
        }    
    }
    
    public void logoff() {   
        if (isAuthenticated())
        {
            AuthenticationServiceUtil.getAuthenticationService().
                                                 logout("/faces/index", null);
        }    
    }
}

An alternative to the programmatic approach handles placing the destination URL on the Session map by invoking the ADF authentication servlet in an explicit link with null value success_url and end_url parameters. In this case, the ADF authentication servlet will try to obtain the redirect values from the web.xml file (or the connections.xml file) and will ignore any values that a user might attempt to enter on the URL. This approach requires configuring the ADF authentication servlet definition in the web.xml by specifying an init-param element for the success_url and end_url parameters. In effect, this is a declarative approach that results in a whitelist with a single destination for login and logout redirects.

When basic type authentication is in effect as specified in the Fusion web application's web.xml file, the browser caches authentication credentials. This is a known issue with basic authentication that re-authenticates users after the logout redirect is performed by the ADF authentication servlet. In this scenario, in order to complete the logout session and prevent users from accessing resources, it is necessary to close the browser and restart a new browser session.

To ensure the ADF application completes logout and prevents a user from being able to access resources after logout, use form-based authentication instead of basic authentication. You can select form-based authentication when you run the Configure ADF Security wizard, as described in How to Enable ADF Security.

When you enable ADF Security to display a custom error page, any HTTP errors that the application generates in response to a request to view a page, should result in the error page being displayed. However, in certain versions of Internet Explorer, the browser will display either the custom error page or an error message built into Internet Explorer. If Internet Explorer displays only an error message you can disable the option to display error message numbers in the Advanced settings of the Internet Options dialog. In Internet Explorer 10, this option is enabled by default. You should disable Show friendly HTTP error messages when you want to display a custom error page that you enabled with the Configure ADF Security wizard.

To ensure custom error pages display in Internet Explorer 10:

1. In Internet Explorer toolbar, click the Tools button.

2. In the Internet Options dialog, click the Advanced tab.

3. In the Advanced tab, scroll and locate Show friendly HTTP error messages.

4. Click the option to disable it and click OK.

1. In the main menu, choose Application and then Secure > Configure Security Deployment.
2. In the Application Properties dialog, in the Deployment page, in the Security Deployment Options section, select the security objects that you want to deploy to Integrated WebLogic Server.

   By default, each time you run the application, JDeveloper will overwrite the application policies and system credentials at the domain level with those from the application. If you prefer not to overwrite either of these repositories, deselect Application Policies or Credentials. When deselected, JDeveloper will merge only new polices or credentials into the domain-level stores.

   By default, each time you run the application, JDeveloper will migrate new user identities you create for test purposes and update existing user passwords in the embedded LDAP server that Integrated WebLogic Server uses for its identity store. You can disable migration of the application identity store by deselecting Users and Groups.

3. Click OK.
4. In the Applications window, right-click the user interface project that contains the secured web pages and choose Run.

   When you choose Run on the user interface project, JDeveloper will run the application using the default run target you configured for the project. For example, you can configure a task flow activity as the run target to start your application. To configure the default run target, see Testing Task Flows.

   The Create Default Domain dialog appears the first time you run the application and start a new domain in Integrated WebLogic Server. Use the dialog to define an administrator password for the new domain. Passwords you enter can be eight characters or more and must have a numeric character.

When you run the application using Integrated WebLogic Server, JDeveloper migrates the security policies and credentials to the domain level based on security deployment configuration settings specified in the Application Properties dialog. During the deployment process, JDeveloper updates the weblogic-application.xml file that it adds to the deployment archive file with the Application Properties settings, as shown in the following example. Note that these settings are not added to the weblogic-application.xml file in the application source directory and thus are not visible.

<application-param>
    <param-name>jps.credstore.migration</param-name>
    <param-value>OVERWRITE</param-value>
</application-param>
<application-param>
    <param-name>jps.policystore.migration</param-name>
    <param-value>OVERWRITE</param-value>
</application-param>

The OVERWRITE value allows you to modify the security policies and credentials in your application and redeploy either to Oracle WebLogic Server running in development mode or to Integrated WebLogic Server (set up to run in development mode by default).

JDeveloper also updates the weblogic-application.xml file with OPSS lifecycle listeners, as shown in the following example. To initiate the migration process before the application runs, the lifecycle listeners observe the migration settings for policies and credentials and overwrite the security objects at the domain level.

<listener>
    <listener-class>
        oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
    </listener-class>
</listener>
<listener>
    <listener-class>
        oracle.security.jps.wls.listeners.JpsAppVersionLifecycleListener
    </listener-class>
</listener>

During the migration process, JDeveloper maps the Oracle Platform Security Services (OPSS) application role member classes to the Integrated WebLogic Server member classes and migrates the users to WebLogic Server identity store users and migrates the roles to WebLogic Server identity store groups. In Oracle WebLogic Server, users is an implicit group equivalent to OPSS authenticated-role.

Identity store migration is not controlled by the application lifecycle listener settings in the weblogic-application.xml file. Instead, an Oracle WebLogic Mbean handles migrating the identities when running in Integrated WebLogic Server or when deploying from JDeveloper. If the user already exists, the Mbean will not migrate the entire user definition. Only the user password will be updated.

When you test the application in JDeveloper using Integrated WebLogic Server, the identity store is migrated to the embedded LDAP server, with information stored in Oracle Internet Directory.

Figure 47-27 illustrates the authentication process when users attempt to access an ADF bounded task flow or any web page containing ADF bindings (such as mypage.jspx) without first logging in. Authentication is initiated implicitly because the user does not begin login by clicking a login link on a public page. In the case of the secured page, no grants have been made to the anonymous user.

In Figure 47-27, the implicit authentication process assumes that the resource does not have a grant to anonymous-role, that the user is not already authenticated, and that the authentication method is Form-based authentication. In this case, the process is as follows:

1. When the bounded task flow or web page (with ADF bindings) is requested, the ADF bindings servlet filter redirects the request to the ADF authentication servlet (in the figure, Step 1), storing the logical operation that triggered the login.

2. The ADF authentication servlet has a Java EE security constraint set on it, which results in the Java EE container invoking the configured login mechanism (in the figure, Step 2). Based on the container's login configuration, the user is prompted to authenticate:

   1. The appropriate login form is displayed for form-based authentication (in the figure, Step 2a).

   2. The user enters their credentials in the displayed login form (in the figure, Step 2b).

   3. The user posts the form back to the container's j_security_check() method (in the figure, Step 2c).

   4. The Java EE container authenticates the user, using the configured pluggable authentication module (in the figure, Step 2d).

3. Upon successful authentication, the container redirects the user back to the servlet that initiated the authentication challenge, in this case, the ADF authentication servlet (in the figure, Step 3).

4. On returning to the ADF authentication servlet, the servlet subsequently redirects to the originally requested resource (in the figure, Step 4).

   Whether or not the resource is displayed will depend on the user's access rights and on whether authorization for ADF Security is enforced, as explained in What Happens at Runtime: How ADF Security Handles Authorization.

Figure 47-28 illustrates the explicit authentication process when the user becomes authenticated starting with the login link on a public page.

In an explicit authentication scenario, an unauthenticated user (with only the anonymous user principal and anonymous-role principal) clicks the Login link on a public page (in the figure, Step 1). The login link is a direct request to the ADF authentication servlet, which is secured through a Java EE security constraint in the web.xml file.

In this scenario, the current page is passed as a parameter to the ADF authentication servlet. As with the implicit case, the security constraint redirects the user to the login page (in the figure, Step 2). After the container authenticates the user, as described in Step a through Step d in the implicit authentication case, the request is returned to the ADF authentication servlet (in the figure, Step 3), which subsequently returns the user to the public page, but now with new user and role principals in place.

When ADF authorization is enabled, the ADF bounded task flows and web pages outside of a task flow that have an ADF page definition will be secure by default. When a user attempts to access these web pages, ADF Security checks to determine whether the user has been granted access in the policy store. If the user is not yet authenticated, and the page is not granted to the anonymous-role, then the application displays the login page or form. If the user has been authenticated, but does not have permission, a security error is displayed. If you do not configure the policy store with appropriate grants, the pages will remain protected and therefore stay unavailable to the authenticated user.

Figure 47-29 illustrates the authorization process.

The user is a member of the application role staff defined in the policy store. Because the user has not yet logged in, the security context does not have a subject (a container object that represents the user). Instead, Oracle Platform Security Services provides ADF Security with a subject with the anonymous user principal (a unique definition of the user) and the anonymous-role principal.

With the anonymous-role principal, typically the user would be able to access only pages not defined by ADF resources, such as the public.jsp page, whereas all pages that are defined either by an ADF task flow or outside of a task flow using an ADF page definition file are secure by default and unavailable to the user. An exception to this security policy would be if you were to grant anonymous-role access to ADF resources in the policy store. In this case, the user would not be allowed immediate access to the page defined by an ADF resource.

When the user tries to access a web page defined by an ADF resource, such as mypage.jspx (which is specified by an ADF page definition, for example), the ADF Security enforcement logic intercepts the request and because all ADF resources are secured by default, the user is automatically challenged to authenticate (assuming that the anonymous-role is not granted access to the ADF resource).

After successful authentication, the user will have a specific subject. The security enforcement logic now checks the policy store to determine which role is allowed to view mypage.jspx and whether the user is a member of that role. In this example for mypage.jspx, the view privilege has been granted to the staff role and because the user is a member of this role, they are allowed to navigate to mypage.jspx.

Similarly, when the user tries to access secpage.jsp, another page defined by ADF resources, for which the user does not have the necessary view privilege, access is denied.

Users and roles are those already defined in the identity store of the resource provider. Application roles are defined in the policy store of the jazn-data.xml file.

1. In the main menu, choose Application and then Secure > Resource Grants.
2. In the Resource Grants page of the overview editor for security policies, select Task Flow from the Resource Type dropdown list and then select the Show task flows with test-all grants only checkbox to view the list of task flows with grants to this built-in role.

   If no grant exists for the test-all role, then the Resources list in the overview editor will appear empty. The test-all role is defined only when enabled in the Configure ADF Security wizard. If it is enabled, you will see those task flows with test-all grants listed, as shown in Figure 47-30.

   Figure 47-30 Showing Task Flows with test-all Grants in the Overview Editor

   
   Description of "Figure 47-30 Showing Task Flows with test-all Grants in the Overview Editor"
3. In the Resources column, select the first task flow in the list.
4. In the Granted to column, select test-all and click the Remove Grantee icon.
5. In the Granted to column, click the Add Grantee icon and choose Add Application Role and then use the Select Application Roles dialog to add the desired role.
6. Repeat these steps to remove the test-all role and substitute your own application role for all remaining task flows.
7. In the Resource Grants page of the overview editor, select Web Page from the Resource Type dropdown list and repeat these steps to remove the test-all role for all web pages and their ADF page definitions.
8. With the Show task flows/web pages with test-all grants only checkbox selected, verify that the overview editor displays no resources with test-all grants.

1. In the main menu, choose Application and then Secure > Users.
2. In the editor window for the jazn-data.xml file, click the Source tab.
3. In the source for the jazn-data.xml file, click the - icon next to the <jazn-realm> element so the entire element appears collapsed as shown in Figure 47-31.

   Figure 47-31 Selecting the <jazn-realm> Element in the XML Editor

   
   Description of "Figure 47-31 Selecting the <jazn-realm> Element in the XML Editor"
4. With the element selected, press Delete and save the file.

1. In the main menu, choose Application and then Secure > Configure ADF Security.
2. In the ADF Security page, select either the ADF Authentication option or the Disable ADF Security Configuration option. Click Next.

   After you run the wizard with either of these options, the ADF resources of your user interface projects will no longer be security-aware.

3. Click Finish.

If you run the Configure ADF Security wizard with the Remove ADF Security Configuration option selected, it removes the ADF-specific metadata in the web.xml file and adf-config.xml file, as described in Table 47-2.

Similarly, running the wizard with the ADF Authentication option selected to disable only authorization checking performs the following updates:

• Leaves the ADF-specific metadata in the web.xml file unchanged and adds the allPages security constraint.

  With the allPages security constraint present, users will be expected to authenticate when they first access the application.

• Sets the authorizationEnforce parameter in the <JaasSecurityContext> element of the adf-config.xml file to false, as shown in the following example.

<JaasSecurityContext 
  initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory"
  jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext"
                             authorizationEnforce="false"
                             authenticationRequire="true"/>

The adf-config.xml file is located in the /.adf/META_INF folder of your workspace. In JDeveloper, you can locate the file in the Application Resources panel of the Applications window by expanding the Descriptors-ADF META-INF node. Note that if you view the adf-config.xml file in an editor outside of JDeveloper, you must save the workspace to see the wizard-applied changes in the file.

You can use Expression Language (EL) to evaluate the policy directly in the UI, while the use of Java enables you to evaluate the policy from within a managed bean. ADF Security implements several convenience methods for use in EL expressions to access ADF resources in the security context. For example, you can use the EL expression and ADF Security Context API methods to determine whether the user is allowed to access a particular task flow. Good security practice dictates that your application should hide resources and capabilities for which the user does not have access. And for this reason, if the user is not allowed access to a particular task flow, you would evaluate the user's permission grant to determine whether or not to render the navigation components that initiate the task flow.

#{securityContext.taskflowViewable['MyTaskFlow']}

#{securityContext.taskflowViewable
 ['/WEB-INF/audit-expense-report.xml#audit-expense-report']}

#{securityContext.regionViewable['MyPagePageDef']}

#{securityContext.userName}

#{securityContext.authenticated}

#{securityContext.userInRole['roleList']}

#{securityContext.userInAllRoles['roleList']}

#{securityContext.userGrantedPermission['permission']}

#{securityContext.userGrantedResource['resource']}

<af:commandNavigationItem
   text="#{res['global.nav.checkout']}"
   action="globalCheckout"
   id="cni3"
   rendered="#{securityContext.taskflowViewable
                       ['/WEB-INF/checkout-task-flow.xml#checkout-task-flow']}"
/>

public boolean isAuthorized() 
{
 if (_targetPageDef != null) {
  FacesContext fctx = FacesContext.getCurrentInstance();
  ADFContext adfCtx = ADFContext.getCurrent();
  SecurityContext secCtx = adfCtx.getSecurityContext();
  boolean hasPermission = secCtx.hasPermission(new RegionPermission
     (_targetPageDef, RegionPermission.VIEW_ACTION));
     if (hasPermission) {
        return hasPermission;
     }
     else {
        fctx.addMessage(null, new FacesMessage (
        FacesMessage.SEVERITY_WARN, "Access Permission not defined! " , null));
        return false;
     }
}

1. Create the custom resource type for the UI component you want to protect.
2. Create the resource grant for the custom resource.
3. Associate the rendering of a UI component with a role's granted resource permission.

<grant>
  <grantee>
    <principals>
      <principal>
         <name>AccountManagersadmin</name>
         <class>oracle.security.jps.service.policystore.ApplicationRole</class>
      </principal>
     </principals>
  </grantee>
  <permissions>
     <permission>
       <class>oracle.security.jps.ResourcePermission</class>
       <name>resourceType=MenuProtection,resourceName=CancelShipment</name>
       <actions>process</actions>
     </permission>
   </permissions>
</grant>

#{!securityContext.userGrantedResource
       ['resourceName=CancelShipment;resourceType=MenuProtection;action=process']}

The implementation of security in a Fusion web application is by definition an implementation of the security infrastructure of the ADF Security framework. As such, the security context of the framework allows access to information that is required as you define the policies and the overall security for your application.

if (ADFContext.getCurrent().getSecurityContext().isAuthorizationEnabled()){
  //Authorization checks are performed here.
}

// ============ User's Authenticated Status =============
private boolean _authenticated;
public boolean isAuthenticated() {
  _authenticated = ADFContext.getCurrent().getSecurityContext().isAuthenticated();
  return _authenticated;
}

// ============ Current User's Name/PrincipalName =============
     public String getCurrentUser() {
      _currentUser = ADFContext.getCurrent().getSecurityContext().getUserName(); 
      return _currentUser;
     }

public boolean checkIsUserInRole(String roleName){
        return 
(FacesContext.getCurrentInstance().getExternalContext().isUserInRole(roleName));
}

public boolean isCustomer() {
        return (checkIsUserInRole("Application Customer Role"));
 }

private boolean TestPermission (String PageName, String Action)  {
  Permission p = new RegionPermission("view.pageDefs." + PageName + "PageDef",
                                         Action);
  if (p != null) {
     return ADFContext.getCurrent().getSecurityContext().hasPermission(p);
  }
  else {
     return (true);
}

//Button Definition
<af:button text="Goto Your Group Home page"
  binding="#{backing_content.commandButton1}"
  id="commandButton1"
  action="#{backing_content.getSecureNavigationAction}"/>

//Backing Bean Code
    public String getSecureNavigationAction() {
      String ActionName;
      if (TestPermission("ManagerPage", "view"))
        ActionName = "goToManagerPage";
      else if (TestPermission("EmployeePage", "view"))
        ActionName = "goToEmployeePage";
      else
        ActionName = "goToWelcomePage";
      return (ActionName);
    }

These best practices summarize the rules that govern enforcement of security by the ADF Security framework. Understanding these best practices will help you to secure the application to allow users to access the web pages you intend.

Do build your application with ADF Security enabled from the start.

When you enable security, you essentially lock down the application and you will be required to make explicit permission grants to specific ADF security-aware resources you create. Knowing about these resources and making grants on them as you build the application will enable you to iteratively test security to ensure that you structure your application in a way that achieves the desired result.

Do define permission grants for bounded task flows.

Pages that the user accesses within the process of executing a bounded task flow will not be individually permission-checked and will run under the permission grants of the task flow. This means that any page that you add to the task flow should not have its own page definition-level security defined. Upon requesting a flow, the user will be allowed either to view all the pages of the task flow or to view none of the pages, depending on their level of access.

Do not define permission grants for individual pages of a bounded task flow.

It is important to realize that task flows do not prevent users from accessing pages directly. Any web page that is located in a directory that is publicly accessible can be reached from a browser using a URL. To ensure that pages referenced by a bounded task flow cannot be accessed directly, remove all permission grants that exist for their associated page definition file. When pages require additional security within the context of a bounded task flow, wrap those pages in a sub-task flow with additional grants defined on the nested task flow.

Do use task flows to reduce the number of access points exposed to end users.

When you use task flows you can reduce the number of access points that you expose to end users. For example, configure an unbounded task flow to display one page that provides navigation to the remaining pages in your application. Use bounded task flows for the remaining pages in the application. By setting the URL Invoke property of these bounded task flows to url-invoke-disallowed, your application has one access point (the page on the unbounded task flow). For more information about the URL Invoke property, see How to Call a Bounded Task Flow Using a URL.

Do specify an alternative task flow for unauthorized users.

End users who attempt to invoke a bounded task flow in a region for which they do not have the necessary permission will see a region that renders as blank in place of the requested task flow. The region when left blank may confuse end users as it does not provide feedback as to why the requested task flow does not appear. Consider configuring an alternative task flow that does not require authorization when this scenario occurs. For more information configuring an alternative task flow, see Handling Access to Secured Task Flows by Unauthorized Users.

Do define permission grants for individual pages outside of a bounded task flow.

Page-level security is checked for pages that have an associated page definition binding file only if the page is directly accessed or if the page is accessed in an unbounded task flow. There is a one-to-one relationship between the page definition file and the web page it secures.

If you want to secure a page that uses no ADF bindings, you can create an empty page definition binding file for the page.

Do define custom permissions to render UI component based on the user's access rights.

Custom ADF permission classes let you extend ADF Security to define custom actions for use in grants. This gives you the flexibility to define security policies to manage the user's ability to view UI components without having to overload the built-in actions defined by the ADF resources' permission classes.

Do define entity object attribute permissions to manage the user's access rights to row-level data displayed by UI components.

Entity objects and entity object attributes both define permission classes that let you define permissions for the read, update, and delete operations that the entity object initiates on its data source. In the case of these data model project components, you must explicitly grant permissions to an application role in order to opt into ADF Security authorization. However, once you enable authorization for an entity object, all rows of data defined by the entity object will be protected by the grant. At this level of granularity, your table component would render in the web page either with all data visible or with no data visible—depending on the user's access rights. As an alternative to securing the entire collection, you can secure individual columns of data. This level of granularity is supported by permissions you set on the individual attributes of entity objects. When entity objects are secured, users may see only portions of the data that the table component displays.

Do use task flow or page-level permission grants to avoid exposing row-level create/insert operations to users with view-only permission.

The correct way to control access to a page that should allow only certain users to update new rows in a table is to use task flow or page-level permission grants. However, as an alternative, it is possible to secure table buttons corresponding to particular operations by specifying an EL expression to test the user's access rights to view the button. When the custom permission is defined and the userGrantedPermission expression is set on the Rendered property of the button, only users with sufficient privileges will see the button. This may be useful in a case where the user interface displays a page that is not restricted and view-only permission for row-level data is defined for the entity object. In this case, when viewed by the user, the Delete button for the editable table associated with the entity object will appear disabled. However, in the case of an input table, the user interface does not disable the button for the CreateInsert operation even though the user may not have update permission.

Do not use JDeveloper as a user identity provisioning tool.

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, always rely on the system administrator to configure user identities through the tools provided by the domain-level identity management system. You should delete all users and groups that you create in the jazn-data.xml file before deploying the application.

Do not allow users to access a web page by its file name.

When you deploy the Fusion web application, you should always permit users to access the web page from a view activity defined in the ADF Controller configuration file. Do not allow users to access the JSPX file directly by its physical name (for example, similar to the file name AllDepartments.jspx.

Assuming the view activity is named AllDepartments, then there are two ways to call the page:

1. localhost:7101/myapp/faces/AllDepartments

2. localhost:7101/myapp/faces/AllDepartments.jspx

The difference is that the call 1) is in the context of the ADF Controller task flow, which means that navigation on the page will work and any managed beans that are referenced by the page will be properly instantiated. The call in 2) also serves the page, however, the page may not function fully. This may be considered a security breach.

To prevent direct JSPX file access, move the JSPX file under the /public_html/WEB-INF directory so that direct file access is no longer possible. To access a document, users will have to call its view activity name.

Note that this suggestion does not protect documents that are unprotected in ADF Security. It only helps to lock down access to the physical file itself.

Thus, the following security guidelines still apply:

1. Apply ADF Security permissions to all JSPX documents associated with view activities defined in the adfc-config.xml file.

2. Move all JSPX documents in the user interface project under the /public_html/WEB-INF directory to prevent direct file access.

3. Limit the pages in the adfc-config.xml to the absolute minimum and place all other pages into bounded task flows.

4. Make bounded task flows inaccessible from direct URL access (which is the default configuration setting for new task flows).

5. Apply ADF Security permissions to bounded task flows.