ADF^H^H^HJSF and OES part 2...

In my first post I started discussing using OES to secure an ADF application. In that post I said that I was using ADF as if it was just a bunch of JSF components. Someone kindly pointed out to me that if someone went searching for ADF and OES that my post wouldn't be all that helpful since they'd likely be interested in ADF's built in security model. So I am renaming this series of posts "JSF and OES". When I finish these posts I'll follow up with some ADF specific posts.


When I finished up last time I had a WebLogic Server domain configured to use the OES WebLogic Security Module. If you want to secure an application deployed to WebLogic Server you'll obviously need an application.

Step 1: Create a web app

Inside JDeveloper you can create a new web app a bunch of ways, but the fastest and best way is, since I want to use some of that sweet, sweet ADF goodness, us to just hit File-New and select "Fusion Web Application (ADF)" from the list of Applications. If you take the defaults for everything else you get two projects Model and ViewController. Congrats, you've created a Web App that has all of the ADF bits (including JSF) pre-wired for you.

Step 2: Deploying your app to WebLogic

This step threw me for a loop the first time...



You want to deploy the app to that WebLogic server we created in the last post. If you did everything right it should just be a matter of picking the right options off the menu. The thing that I goofed up was that I tried to deploy just the ViewController thinking that the Model would come along automatically based on the dependency. What you actually need to do is click the drop down next to the Application Name (not Model or ViewController) and select Deploy from that menu. Work your way through the menus to deploy the app and JDeveloper will create the EAR, deploy it to WebLogic and start it up.

Try accessing the application you created. If you don't know the app's context root you'll need to use the WebLogic console to find it inside the application's config page. You can adjust it there or you can create a weblogic.xml file and specify the context-root there.

Step 3: Secure the app

At this point if you access the application you'll be allowed right in since you didn't tell WebLogic to require user logon. That's easily fixed by just following the standard J2EE steps - edit web.xml either by hand or better yet using JDeveloper's web.xml friendly editor. Basic authentication is evil and I strongly encourage the use of Forms-Based Authentication, but either will work. Just to make sure everything is working try accessing the page and login as "weblogic"

If you're like most developers I know you've already tried to login with a username other than weblogic and you got the standard ugly Error 403--Forbidden page because, shockingly, you are not authorized.

Step 4: Create OES resources and policies

In order to create policies in OES you first have to tell OES about the resources it is protecting. Or at the very least you have to tell OES about some resource above the resources it's protecting and tell OES that anything with that prefix is OK; or in OES' words that parent resource is Virtual.

If you have a whole bunch of resource then Discovery Mode is your friend.
If you're deploying your first "hello world" application then follow along with me.

One of the best new features of OES since I began using it a couple of years ago is a little known logging option called DebugStore. One of my friends in engineering has earned a special place in my heart for the addition and I probably owe him a few lunches for all the time he's saved me with it. The DebugStore logging feature causes OES to spit out a block of data at the end of an Authorization that tells you everything you need to know to figure out why a user was authorized (or why they weren't).

To enable DebugStore open log4j.properties and toggle the comment off the line that contains DebugStore:

### Uncomment the following "log4j" line to enable logging of Policies
### This is helpful if you are having problems with OES policies or if you
### want to understand how OES policies are processed
log4j.logger.com.wles.util.DebugStore=DEBUG

If you uncomment that line, restart WebLogic, and try accessing the URL again with a user other than weblogic you'll get the 403 error again and something like this will show up in your system_console.log

========== BEGIN Policy Evaluation (2009-10-05 17:36:30,895 EDT) ==========
RequestResource is: //app/policy/DrApp/testapp_application1/url/testapp-ViewController-context-root
UserInfo:
Name: //user/DrAppDir/user9001/
Groups: //sgrp/DrAppDir/allusers/
Resource Present: true
Roles Granted: //role/Everyone
Role Mapping Policies:
1. Result: true; Policy Type: grant
   Role: //role/Everyone
   Resource: //app/policy/DrApp
   Subject: //sgrp/DrAppDir/allusers/
   Constraints: NONE
   Delegator: null

ATZ Policies: NONE
========== END Policy Evaluation (2009-10-05 17:36:30,895 EDT) ==========

That log block tells me everything I need to know.

DrApp is the name of the SSM I created, and DrAppDir is the name of the user directory I associated with the SSM. ConfigTool automatically created //app/policy/DrApp and "testapp_application1" is the web app (the EAR) that JDeveloper published. The other parts of the resource string are fairly obvious - "url" is a prefix that all HTTP URLs in the application appear under. And "testapp-ViewController-context-root" is the root of the app. For now the easiest thing to do is to open the OES GUI and create "testapp_application1" and "url" as resources.

You can create as many complicated policies as you want under the test app, but a simple policy will do well enough for me for now. When I created "url" I checked the box "Allow Virtual Resource", then created a simple policy on that resource granting the actions GET,POST, and HEAD to the group //sgrp/DrAppDir/allusers/.

Here's what that policy looks like in the GUI:



Don't forget to Save and Distribute your changes before accessing the site again.

One note of caution when you start writing policies. If there's a Deny policy that matches the resource and applies to the user then access will be denied no matter what other policies you have created. After that if you have any Grant policy that apply to the resource and to the user then access will be granted. These rules sound simple, but when you have 10 policies that apply to a bunch of resources it can get a bit confusing if you're creating them without a plan or design in mind.

In any case DebugStore will help you out.

Now to go buy my engineering friend lunch...