Introduction to ADF Security in JDeveloper 10.1.3.2
An Oracle JDeveloper Article
Oracle Application Development Framework (ADF) is Oracle's JSR-227 compliant implementation of a generic binding layer for applications that follow the J2EE Model-View-Controller architecture. ADF Security is a key feature of the Oracle ADF binding layer. ADF Security allows developers to declaratively define fine-grained access control to iterators, attributes, and methods exposed by a business services. The goal of ADF Security is to ease and promote secure application development based on standard J2EE security features and the Java Authentication and Authorization Service (JAAS).
Don't put all your eggs into one basket
The defense-in-depth security design pattern demands that application developers implement application security with multiple lines of defense. A typical J2EE application has a minimum of four application layers that can be used to implement security in depth. The layers in the security-in-depth approach behave as follows:
With the Oracle Application Development Framework (ADF), an additional layer, the binding layer, is added to the J2EE application architecture. The ADF binding layer is located between the view/controller layers and the business service.
This article outlines how application developers define security on the ADF binding layer using the ADF Security framework. More in-depth technical information about ADF Security is available in the Oracle WebCenter Framework Developer's Guide.
Container-Managed Security in OC4J (Oracle Containers for J2EE)
ADF Security leverages the JAAS security provider (JAZN) in Oracle OC4J for authentication and authorization. JAZN implements container-managed J2EE security in OC4J and is the default policy provider for JAAS (Java Authentication and Authorization Service).
One of the advanced features in OC4J security is the ability to use JAAS authorization with J2EE container-managed authentication. Using this option, applications can authorize user interaction based on URL patterns and Java Permissions. ADF Security runs within OC4J as part of the Oracle ADF runtime libraries and leverages JAAS for authorization to implement fine-grained access control.
ADF Security is a JAAS-based security framework in Oracle ADF that works with all business services. ADF Security requires the Oracle JAAS (JAZN) security provider in Oracle Application Server and OC4J and integrates with Oracle Single Sign-On and Identity Management. User authentication is performed with J2EE container-managed security while access control is through JAAS. During development and testing, ADF Security is configured in
ADF Security by Example
How ADF Security works at design time and runtime is best explained by a simple example. In this example, the following security policies will be applied to an ADF Faces web application:
Note that a security best practice is to apply protection to an application during development and not after the fact.
Enabling ADF Security for a Web application
The ADF Security framework is a feature of Oracle ADF since JDeveloper 10.1.3.0. New functionality added in JDeveloper 10.1.3.2 includes the ADF Security wizard that guides developers through the configuration of ADF Security for web applications based on ADF Faces and the ADF binding layer.
The Redirect Upon Successful Authentication option specifies a page that the authenticated user is redirected to after login. Using this feature, developers enforce a defined entry to an application, independent of the page requested by the user. The Browse button allows the developer to browse the current web project to select a source file that represents the start of the application.
Note: ADF Security may also be configured for web applications built with JSP and Struts. In contrast to JSP applications, that are accessed relative from the J2EE context, JavaServer Faces applications require the Faces Servlet mapping to be part of the requesting URL to ensure a JavaServer Faces context exists. The Faces Servlet mapping "faces/" is not added by the ADF Security wizard and must be added manually in front of the selected page as shown in the image above.
Authentication in ADF Security is enforced through a Servlet that is configured as
ADF Security supports both JAZN file-based security and the LDAP security provider for authentication and authorization. For application development the
Lightweight XML Provider is the default. Note that selecting the
LDAP Provider option in the wizard does not connect to the Oracle Internet Directory instance but configures the JAZN application deployment descriptor (
If authorization is enforced for web applications, the repository location must be chosen as
OC4J Default Repository, which points to the
ADF Security uses J2EE container-managed authentication with one of the following authentication types: Basic Authentication, Digest Authentication, Forms-Based, Client Certificate.
Form-Based Authentication, an HTML file or a JSP file is required to define the login page and the error page. The login page contains an HTML form with the
Generate Default option generates two HTML files:
If an ADF Faces application is configured to use the JAZN XML provider, then authentication is performed against user accounts defined in the
J2EE security roles are defined in the
Finishing the ADF Security wizard writes the configuration information to the
Configuring the embedded OC4J
The embedded OC4J J2EE container has its bootstrapping configuration files located in the
To configure the
To configure ADF Security, the user and group accounts need to be created under the
The authentication servlet is protected using the same role names in the
Authorization in ADF Security is defined through Java Permissions. The application developer defines authorization declaratively for iterator bindings, action bindings, and method bindings defined in the ADF page definition (
A context menu option
Edit Authorization on all bindings that can have authorization defined. The Authorization editor dialog shows all possible actions for the developer to identify which user roles are allowed to perform which actions. In JDeveloper 10.1.3.2 an application either has security configured or it doesn't. This means that if ADF Security is enabled for a web application, all ADF bindings must have grants configured. All security grants are written as permissions to the
Note: It is important to define authorization for the
Programmatic access control with ADF Security
Developers may need to access user permissions programmatically in their applications for example to hide or to show UI components that execute protected actions or perform navigation. Programmatic access control can be used to implement the 5th security policy in the sample application mentioned above: "All navigation controls are hidden from the user if the user is not authorized to perform the action".
Access through ADF Bindings
ADF Security sets the
Access through Expression Language using the PermissionInfo object
The general use of
In addition, the
Access control through calls to hasPermission()
It is also possible to directly check a specific permission grant using the
Note that using the
ADF Faces security aware components
ADF Faces components, like
ADF Security Deployment
ADF Security is deployed by configuring the JAZN security provider of the target system with the Java security permissions created during web application development. In a deployment to the file-based provider, the Java Permissions need to be added manually to the
To make ADF Security deployment easier, the
To set up ADF Security for the file-based provider, the system administrator copies the user group and permission entries to the
To set up the LDAP provider with ADF Security, the administrator uses the JAZN migration utility to create an
ADF Security is a protection framework in Oracle ADF to authorize user access to iterator bindings, action bindings, and attribute bindings. ADF Security implements application security independent of the business service layer and works with EJB, POJO, ADF Business Components, and web services alike.
For further documentation see