8 ADF Security Framework

This chapter provides a high-level overview of the ADF Security framework, including its integration with the Oracle Platform Security Services (OPSS) architecture and the securing of ADF applications with declarative resource grants.

This chapter includes the following sections:

8.1 About the ADF Security Framework

In order to simplify the process of ensuring thorough application security, the Oracle Application Development Framework (Oracle ADF) provides the ADF Security framework. ADF Security is built on top of the Oracle Platform Security Services (OPSS) architecture, which in turn incorporates the Java Authentication and Authorization Service (JAAS) and Java EE container-managed security.

As shown in Figure 8-1, ADF Security encompasses the range of other components in the ADF technology stack, such as ADF Faces, ADF Controller, ADF Model, and ADF Business Components.

Figure 8-1 ADF Architecture with ADF Security

This image is described in the surrounding text

OPSS is the underlying security platform that provides security to Oracle Fusion Middleware, including WebLogic Server and Oracle ADF applications. OPSS is designed to be portable to third-party application servers, so developers can use OPSS as the single security framework for both Oracle and third-party environments, thus decreasing application development, administration, and maintenance costs.

Figure 8-2 conceptually illustrates the architecture of the ADF Security framework. The uppermost layer consists of the running ADF application. Below that is the ADF security layer, which implements the OPSS APIs and enables programmatic permission checks on resources from the application. The OPSS API layer serves as an abstraction layer for accessing providers of authentication, authorization, credential store framework services.

Figure 8-2 ADF Security Architecture

This image is described in the surrounding text

8.2 Core Benefits of ADF Security

ADF Security provides the following core benefits:

  • Declarative, permission-based protection for ADF security-aware resources, such as ADF bounded task flows, top-level web pages that use ADF bindings, and attributes defined by ADF entity objects and their attributes.

  • Dynamic user authentication. When you use ADF Security, the application dynamically prompts the user to log in if the user is not yet authenticated and tries to access a page that is not granted to the anonymous-role role. In the application's web.xml file, a security constraint is applied to the ADF authentication servlet so that login is triggered through the Java EE web container before any secured resources can be accessed. After the user successfully logs in, the ADF authentication servlet runs to verify if the authenticated user has view access to the requested page.

  • Permission checking within the web page. At runtime, the security policy you define for ADF resources is enforced using standard JAAS permission authorization to determine the user's access rights. If your application requires it, you can use Expression Language (EL) to perform runtime permission checks within the web page to hide components that should not be visible to the user.

  • Simplifies securing of applications by providing an abstraction layer between the application and various security providers. Calls from the application to the security layer can be made through standards-based APIs, so developers do not have to deal with implementation details of the security providers.

8.3 Key Concepts of ADF Security

The ADF Security framework consists of runtime integration with OPSS plus additional design-time features through JDeveloper that simplify the creation of secure applications. This section provides an overview of the main aspects of ADF Security, including the OPSS features it incorporates and additional ADF-specific features.

8.3.1 Authentication and Authorization

Authentication is the process of validating a user's credentials, such as through a login screen. ADF Security provides an authentication servlet which (through OPSS) delegates authentication to the Java EE web container and also allows the application to dynamically prompt the user to log in.

Authorization is the process of determining the authenticated user's access rights and permissions. ADF Security (through OPSS) offers a fine-grained, permission-based authorization model which protects a resource (such as an ADF task flow) by means of JAAS-based checkPermission calls. OPSS also enables you to use Java EE container-managed security, which provides a more coarse-grained authorization model.

8.3.2 Application Roles

Instead of granting access to individual users, you can group users into application roles and grant permissions to the role.

8.3.3 Security Policies

You grant users (or roles) access rights to a given resource. A security policy is an access right that you grant for a given resource. Ultimately, it is the security policy on the ADF resource that controls the user's ability to enter a task flow or view a web page.

For ease of administration, you can also create entitlement grants, under which you aggregate multiple resources in a security group. This enables you to set the security policy for multiple resources in one place.

8.3.4 Security Awareness in ADF Resources

The ADF Security framework contains permission classes that enable you to protect ADF resources. Resources for which such permission classes exist are known as security-aware resources. Any web page associated with an ADF security-aware resource is protected by default unless you explicitly set a security policy granting access to the resource.

For a list of the types of ADF security-aware resources, see ADF Security-Aware Resources.

8.4 Key Components of ADF Security

This section outlines the features and physical artifacts that are at the core of the ADF Security framework.

8.4.1 Design-Time Integration With OPSS

The design-time integration with OPSS for an application is configured declaratively through several metadata files, which are configured automatically when you use JDeveloper's security wizards and visual editors. The following are the key files affected:

  • The user interface project's web.xml file, in which the following things are specified:

    • The JpsFilter, in order to set up the OPSS policy provider.

    • A web resource for the oracle.adf.share.security.authentication.AuthenticationServlet servlet and mappings to require the user to log in the first time the application is accessed and to set the appropriate security constraint to trigger user authentication dynamically.

    • The authentication method for the login configuration.

    • Required security roles, such as valid-users, which is used to trigger the security constraint that enables dynamic authentication.

  • The application workspace's adf-config.xml file, in which the JAAS security context is set and the use of ADF Security security policies is enabled.

  • The application workspace's jps-config.xml file, which holds the OPSS security platform configuration at design time. (Though this file may be deployed as part of the application EAR file, it is not used at runtime. Instead, a version of the file that is stored in the server instance's domain is used.)

  • The application's jazn-data.xml file, which serves as the application's identity and policy store at design time. When you deploy the application to Oracle WebLogic Server, by default the server copies users and groups in jazn-data.xml to the server's identity store and merges policies to the server's policy store (system-jazn-data.xml in Integrated WebLogic Server).

    Before deploying to a production server, you should delete all users and groups that you create in the jazn-data.xml file to prevent the risk that malicious users could use those credentials to gain access to the application.

  • The application's weblogic.xml file, in which the valid-users security role is mapped to users, WebLogic Server's implicit role for all users.

    Figure 8-3 shows the security artifacts that are created and configured in JDeveloper and how they map to the runtime security architecture of Oracle WebLogic Server.

Figure 8-3 ADF Security Configuration and Deployment

This image is described in the surrounding text

8.4.2 ADF Security-Aware Resources

The following types of resources in ADF applications are security-aware and can be configured with individual security policies:

  • ADF bounded task flows. You can set a security policy to protect the entry point to a bounded task flow, which in turn controls the user's access to the pages contained by the flow. It is recommended that you set security policies for all bounded task flows.

    To make sure that pages contained by a bounded task flow cannot be accessed directly, you must not grant access to the contained pages through 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.

  • ADF page definition files, which contain bindings for web pages and which map to individual pages. You might need to set a security policy for a page definition file if its page is not encompassed by a bounded task flow. If you want to secure a page that does not have a corresponding page definition file, you can create an empty page definition file for the page.

  • ADF Business Components entity objects and attributes of entity objects that reference rows of data and help define collections for display in the user interface. You can set permissions for the read, update, and delete operations that the entity object initiates on its data source.

    When you enable authorization for an entity object, all rows of data defined by the entity object are 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 provide security policies by individual attribute.

8.4.3 ADF Authentication Servlet

When ADF Security authorization is enabled, all user interaction with the application is mediated by the oracle.adf.share.security.authentication.AuthenticationServlet servlet. This servlet requires that the user successfully log in before being able to access any of the application's secured resources. It is specified as a resource in the user interface project's web.xml file and referenced from filter mapping and security constraint tags.

8.4.4 ADF Security Context

Information about authenticated users can be accessed with calls to the ADF security context with Java code, Groovy expressions, or from the user interface components via EL. You can determine things such as whether the user is authenticated and whether or not a user is granted permissions for given resources. You can then use this information to determine which content and controls to display to the user. The security context is represented by the SecurityContext object in Java, the securityContext namespace in EL, and the SecurityContext object in Groovy.

8.5 Overview of the ADF Security Process Flow

Using the ADF Security framework consists of the following basic steps:

  1. In JDeveloper, run the Configure ADF Security wizard to configure security for the application. This step enables you to set the security model, configure an authentication type for the web project, grant view access to a test-all role, and set up a welcome page for successfully authenticated users.

    It is recommended that you run this wizard early in the development cycle so that you can iteratively test security and make design decisions that best take security into account.

  2. Create one or more application roles.

    Application roles you create are specific to the application and let you confer the same level of access to a set of users (also known as member users). In the test phase you create some users and add them as members to the application roles you created.

  3. Set security policies to associate any ADF security-aware resources (such as bounded task flows) with one or more application roles that you have created and set the access rights for those roles.

  4. Create test users for the various roles.

  5. Run the application in JDeveloper and test access to the various resources using the test users that you have created.

  6. Before deploying the application, remove any policy grants and users that you had added in order to test the application.

  7. Migrate the finalized policy store and credentials store to the target server. Application policies and credentials can be automatically migrated to the domain stores when the application is deployed to Oracle WebLogic Server.

8.6 Learning More About ADF Security

The following resources provide more information about using the ADF Security framework and OPSS.