18.6 Implementing Authorization Using Oracle ADF Security

Authorization provides a way to restrict access to a resource based on the user attempting access. Oracle ADF Security implements OracleAS JAAS for authorization of security-aware resources.

Oracle ADF Security provides another level of granularity, allowing object instance access control based on Java Permissions using JAAS. Specifically, certain Oracle ADF Model layer objects are "security-aware," meaning that there are pre-defined component-specific permissions that a developer can grant for a given resource.

Note:

The SRDemo application currently does not demonstrate Oracle ADF Security at the ADF Model layer. To understand how the SRDemo application handles authorization, see Section 18.7, "Implementing Authorization Programmatically".

The following Oracle ADF objects are security-aware as defined by the page definition file associated with each databound web page:

Binding Container
Iterator binding
Attribute binding
MethodAction binding

You set grants on these objects by defining which authenticated users or roles have permission to perform a given action on the object (called a resource). Grantees, which are roles, users, or groups defined as principals are mapped to permissions. Permissions are permission to execute a specific action against a resource, as defined by Oracle ADF Security classes (see the Oracle ADF Javadoc for details). Grants are aggregated. That is if a group's role is granted permissions, and a user is a member of that group, then the user also has those permissions.

Table 18-1 shows permissions you can grant on binding containers, iterator bindings, attribute-level bindings (for example, table, list, boolean, and attribute-value bindings), and method bindings. You use the Authorization Editor to grant permissions for users on the Oracle ADF objects created at runtime from the page definition file.

Table 18-1 Oracle ADF Security Authorization Permissions

ADF Model Object	Defined Actions	Affect on Components in the User Interface
Binding Container for a web page	grant - can administer the permissions on the page	On pages that allow runtime customization, any link or button configured to set access controls will be disabled for users not granted this permission.
	edit - can edit content on the page	If a user is granted permission for the view action, but not for the edit action, then any data in input text boxes will display as read only.
	personalize - allows the user customization of the page	On pages that allow runtime customization, any link or button configured to put the page into personalization mode will be disabled for users not granted this permission.
	view - can view the page	A user not granted this permission will be shown an authorization error.
Iterator Binding	read - can read the returned rows	All rows of data will be returned. However, you can limit what can be displayed or updated by placing grants on the individual attribute bindings.
	update - can update data in a row	If the Commit operation is dropped as a command button from the Data Control Palette, the button will be disabled for users who were not granted this permission. Instead of limiting updates to an entire row, you can instead limit the ability to update individual attributes.
	create - can create a new row	If the Create operation is dropped as a command button from the Data Control Palette, the button will be disabled for any users that were not granted this permission.
	delete - can delete a row	If the Delete operation is dropped as a command button from the Data Control Palette, the button will be disabled for any users that were not granted this permission.
Method Action Binding	invoke - the method can execute	If the method is bound to a command button, that button will be disabled for any users that were not granted this permission. If the method is invoked implicitly, the method will only execute for users granted this permission.
Attribute-level Bindings	read - can read the attribute's value	The value for the attributes will be displayed.
	update - can update the attribute 's value	Any data in input text boxes will display as read only for users who were not granted this permission.

Before you can implement Oracle ADF authorization, you must first:

Configure authentication for the ADF Authentication servlet. For details, see Section 18.3.1, "How to Enable Oracle ADF Authentication".
Configure your application to use Oracle ADF Security authorization. For details, see Section 18.6.1, "Configuring the Application to Use Oracle ADF Security Authorization".

18.6.1 Configuring the Application to Use Oracle ADF Security Authorization

You must first configure the application to use Oracle ADF Security before you can work with ADF authorization in your application.

18.6.1.1 How to Configure Oracle ADF Security Authorization

To enable Oracle ADF Security authorization, you create a configuration file named adf-config.xml that sets the application's container to use Oracle ADF Security. The file initializes the ADFContext and SecurityContext.

To configure an application to use Oracle ADF Security:

Right-click on the project for which security is needed and choose New.
In the New Gallery, select the XML category.

If XML is not displayed, use the Filter By list at the top to select All Technologies.
In the Items list, select XML Document and click OK.
Name the file adf-config.xml, save it in the <application_name>/.adf/META-INF directory, and click OK.

The file opens in the source editor.

Replace the generated code with the following:

<?xml version="1.0" encoding="windows-1252" ?> 
<adf-config xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " 
    xsi:schemaLocation=" http://xmlns.oracle.com/adf/config 
    ../../../../../bc4jrt/src/oracle/adf/share/config/schema/config.xsd" 
    xmlns=" http://xmlns.oracle.com/adf/config " 
    xmlns:sec=" http://xmlns.oracle.com/adf/security/config ">
   <sec:adf-config-child xmlns=" http://xmlns.oracle.com/adf/security/config "> 
     <JaasSecurityContext
        initialContextFactoryClass="oracle.adf.share.security.               JAASInitialContextFactory" 
        authorizationEnforce="true" 
        jaasProviderClass="oracle.adf.share.security.providers.jazn.               JAZNSecurity Context" > 
    </JaasSecurityContext>
   </sec:adf-config-child>
</adf-config>

Save and close the file.

18.6.1.2 What Happens When You Configure An Application to Use Oracle ADF Security

The authorizationEnforce parameter in the <JaasSecurityContext> element set to true will allow the authenticated user principals to be placed into ADF SecurityContext once the user is authenticated. <<Yvonne: The default anonymous user is not used in 10.1.3 except by WS URL Data Control. Will be used in 10.1.3.2 Virtual Content Repository.>><<Yvonne: credentialStore is not used in 10.1.3. But is used internally by the connection architecture. It will be exposed for VIrtual Content Repository in 10.1.3.2.>> The credentialStoreDefaultUser parameter designates the named user (in this case guestUser) as the anonymous user (any user not yet authenticated) for the application. You can edit this value as necessary.

Tip:

If you want to run the application without using Oracle ADF Security, simply set the authorizationEnforce parameter to false.

18.6.1.3 What You May Need to Know About the Authorization Property

Because security can be turned on and off, it is recommended that an application should determine this property setting before invoking an authorization check. The application can check if Oracle ADF Security is enabled by checking the authorization property setting. This is exposed through the isAuthorizationEnabled() method of the SecurityContext under the ADFContext. For example:

if (ADFContext.getCurrent().getSecurityContext().isAuthorizationEnabled()) 
  {
    Permission p = new RegionPermission("view.pageDefs.page1PageDef", "Edit");
    AccessController.checkPermission(p);
    // do the protected action
  } catch (AccessControlException ace) {
    // do whatever's appropriate on an access denied
}

18.6.2 Setting Authorization on ADF Binding Containers

You use the Authorization Editor to grant permissions for users on the binding container as it is defined by the entire page definition. See Table 18-1 for details about available Oracle ADF permissions.

To grant permissions on the binding container using the Authorization Editor:

Create your web page. From the Visual Editor, right-click the page and choose Go to Page Definition.
In the Structure window, right-click the root node, PageDef, and choose Edit Authorization.
The Authorization Editor shows the pre-defined permissions for the binding container, along with the principals (roles and users) as defined by your resource provider.

Click Help or press F1 for more help on using this dialog.

18.6.3 Setting Authorization on ADF Iterator Bindings

You use the Authorization Editor to grant permissions for users on iterator bindings. See Table 18-1 for details about available Oracle ADF permissions.

To grant permissions on iterators using the Authorization Editor:

Create your web page. From the Visual Editor, right-click the page and choose Go to Page Definition.
In the Structure window, expand the executables node.
Right-click on the iterator you wish to grant a permission for and choose Edit Authorization.
The Authorization Editor shows the pre-defined permissions for the iterator, along with the principals (roles and users) as defined by your resource provider.

Click Help or press F1 for more help on using this dialog.

18.6.4 Setting Authorization on ADF Attribute and MethodAction Bindings

You use the Authorization Editor to grant permissions for users on attribute and method action bindings.

Note that permissions granted on an attribute reflect the ability to execute operations such as Create, Delete, and Commit. Therefore, do not set authorization on the operations, but instead on the attribute or iterator. See Table 18-1 for details about Oracle ADF permissions.

To grant permissions on attribute and method bindings using the Authorization Editor:

Create your web page. From the Visual Editor, right-click the page and choose Go to Page Definition.
In the Structure window, expand the bindings node.
Right-click on the attribute or method action binding you wish to grant a permission for and choose Edit Authorization.
The Authorization Editor shows the pre-defined permissions for the attribute or method action binding, along with the principals (roles and users) as defined by your resource provider.

Click Help or press F1 for more help on using this dialog.

18.6.5 What Happens When Oracle ADF Security Handles Authorization

When a user attempts to execute an action against a resource which has a defined grant, Oracle ADF Security checks to see if the user is a principal defined in the grant. If the user is not yet authenticated, the application displays the login page or form. If the user has been authenticated, and does not have permission, a security error is displayed.

Example 18-6 shows grants for the attribute binding and method binding if you are using the Oracle JAZN lightweight XML provider, these grants are written in the system-jazn-data.xml file. Note that in these grants, the role users has been granted a MethodPermission to invoke the deleteDepartments method, and also an AttributePermission to read the DepartmentID attribute value.

Example 18-6 Sample system-jazn-data.xml File Oracle ADF Permissions

<grant>
  <grantee>
    <principals>
      <principal>
        <realm-name>jazn.com</realm-name>
        <type>role</type>
        <class>oracle.security.jazn.spi.xml.XMLRealmRole</class>
        <name>jazn.com/users</name>
      </principal>
    </principals>
  </grantee>
  <permissions>
    <permission>
      <class>oracle.adf.share.security.authorization.MethodPermission</class>
      <name>SessionEJB.dataProvider.deleteDepartments</name>
      <actions>invoke</actions>
    </permission>
    <permission>
      <class>oracle.adf.share.security.authorization.AttributePermission</class>
      <name>EmployeesView1.DepartmentId</name>
      <actions>read</actions>
    </permission>
  </permissions>
</grant>

Users or roles are those already defined in your resource provider.