ADF UI Shell + ADF Security

This post covers off combining the new ADF UI Shell and ADF Security. Recently Oracle released the UI Shell based on the Oracle Dynamic Tabs Shell for JDeveloper 11g Release1 (aka PS1). I blogged about my initial research around the UI Shell here, and you can follow others' questions and answers on the ADF UI Patterns & Best Practices OTN forum.

It's important for me to note that both my original post and this post constitute my learnings, have not been tested in a production system, they could contain errors. As such your mileage may vary and it's important you do your own testing.

The UI Shell is an interesting concept in that it dictates your application will be composed of separate subsystems, each made up of a number of activities (aka. bounded task flows). The bounded task flows can in turn be shared by the subsystems.

What I wanted to consider in this post is what are the minimum requirements in applying ADF Security, or in other words, what permissions do we need to give to each of the design time parts in order to allow authenticated users to access the application. To discuss this I thought I'd base my example on the UI Shell demonstration application as detailed in the Oracle UI Shell Functional Pattern whitepaper.

In understanding how to apply ADF Security to the UI Shell example application we first need to identify all the moving parts that we need to apply security against:

1) In the UI Shell example application the application is divided into 3 subsystems, namely First, Second and Third. From a design time point of view each of these has an associated page First.jspx, Second.jspx and Third.jspx respectively.

2) In turn the First subsystem has a "welcoming" task flow comprised of a single page fragment called you.jsff. Potentially each subsystem can have its own welcoming task flow with page fragment, though in the example only one exists.

3) The First subsystem makes use of three activities (aka. bounded tasks flows using page fragments) called first, second and third (note the case difference, don't get these confused with the subsystem names which are initcapped), that in turn are simple bounded task flows using a single page fragment one.jsff, two.jsff and three.jsff respectively. The three activities are backed by task flow files first.xml, second.xml and third.xml.

With this in mind let setup a security scenario where we want to allow a user to access the First subsystem and all the associated activities, but not parts of the Second and Third subsystems.

The following steps describe the actions required in doing this:

1) You must first enable ADF Security for your application via the Application -> Secure -> Configure ADF Security menu option that invokes the Configure ADF Security wizard. As this wizard has been described in numerous other blogs I'll paraphase the options here:

Step 1 of 5

ADF Authentication and Authorisation

Step 2 of 5

Web Project: ViewController.jpr
Form-Based Authentication
Login Page: /login.html
Error Page: /error.html

Step 3 of 5

No Automatic Grants

Step 4 of 5

No options (Leave Redirect Upon Successful Authentication unselected)

Step 5 of 5

n/a

2) Via Application -> Secure -> Application Roles, configure a single Application Role "role1"


3) In the same jazn-data.xml editor, select the Users options on the left, then configure a single user "user1" and allocate them to "role1" Application Role you created in the last step.


---

What we need to from here is allocate basic access rights to the moving parts of the UI Shell that aren't specific to any subsystem. In other words the parts of the UI Shell that are shared by all subsystems regardless of the type of user.

You have a choice to make here. If you want your basic application to be available to any user regardless if they've authenticated (ie. logged in) or not, then in the following step you need to grant the "anonymous-role" privilege. Alternatively if you want your users to have to at least log in before accessing any part of the system, then you need to grant the "authenticated-role" privilege. If you're unfamiliar with these concepts please read the Oracle documentation. For this post I'll assume the "authenticated-role" privilege.

4) In the same jazn-data.xml editor, select the ADF Policies tab at the bottom. Select the Web Pages tab. Ensure the "Show web pages imported from ADF libraries" checkbox is selected. Under the Page Definitions table column select the dynamicTabShellDefinition option, then the green plus button in the "Granted to Roles" column, and select the authenticated-role role in the Select Role dialog:


The result in the jazn-data.xml will be:


5) In the same jazn-data.xml editor with the ADF Policies tab still selected at the bottom, select the Tasks Flow tab. Ensure the "Show task flows imported from ADF libraries" checkbox is selected. Similar to the last step allocated the authenticated-role in the Select Role dialog to the "blank" task flow. The result:


---

From here we want to allocate the user1 with role1 privileges against the First subsystem.

6) In the same jazn-data.xml editor with the ADF Policies tab and Tasks Flow tab open, allocate the role1 to the "first" task flow. The result:


7) Ditto, allocate role1 to the "welcome" task flow. The result:


8) Switch back to the Web Pages tab, then allocate role1 to the First page:


---

At this stage if you run your application, you'll note on accessing the First page the user will be hit with the login box straight away. A successful login lands on the First page showing the First subsystem.


If you click on one of the other main tabs such as Second App, the running page will return the following error message as expected as we haven't allocated user1 priviliges to the Second subsystem:

ADFC-0619: Authorization check failed: '/Second.jspx' 'VIEW'.

Ideally to stop this occurring we need to either disable or set the Second App tab's rendered property to false, through the following EL expression:

#{!securityContext.userInRole['role2']}

The result:


You'll need to make this change to every tab into every subsystem's page (First.jspx, Second.jspx, Third.jspx).

---

If we now open the first activity in the First subsystem page we get:


Yet if we open the second activity we get the following empty content:


This is to be expected as we haven't allocated the second.xml (or even the third.xml) to the role1 privilege. As back in step 6, allocate role1 against these under the jaxn-data.xml editor, ADF policies tab, Task Flow tab:


Alternatively if you don't want these activities available to role1, instead change the commandLink's to disable or un-render properties as per the EL securityContext example above.

--

In conclusion we see the UI Shell works pretty seamlessly with ADF Security, with the small caveat that you need to know which parts of the UI Shell to grant privileges to all users/roles.