X

Best Practices from Oracle Development's A‑Team

JSF and OES part 3

The third in an ongoing series of posts on securing a JSF based app (in this case using ADF components).

In the part 1 I plugged OES' Security Module into WebLogic Server. In part 2 I showed how to deploy the app and write OES policies to secure URLs and other objects that WebLogic automatically protects. In this post I'm going to rely on the small chunk code of I provided in a post that discussed calling OES from inside a J2EE app. If you haven't seen that post you should probably at least skim through it and grab the code.

If you have an existing JSF based application you probably already have some security logic embedded in it today. In my experience the most common way that people to do that in JSF seems to be abstracting all of that code into a bean and then setting the rendered or enabled attribute to an EL expression that invokes the authorization bean.

What I mean is that the bean has a method to get a boolean value like MaySeePatients:

 public class AuthorizationBean {    public boolean getMaySeePatients() {     // everyone can see patients so I return true        return true;    } } 

You tell JSF to creating and manage an instance of the bean for you by defining it in faces-config.xml

<managed-bean>    <managed-bean-name>Authorization</managed-bean-name>    <managed-bean-class>com.oracle.demo.drapp.view.backing.AuthorizationBean</managed-bean-class>    <managed-bean-scope>session</managed-bean-scope> </managed-bean>

And then in your JSF you would call the bean with something like this:

<af:group rendered="#{Authorization.maySeePatients}">    <af:outputtext value="You are authorized"> </af:outputtext></af:group>

Swapping out the existing authorization logic to use OES instead is simple - add that ALESControl code I shared in my previous post and edit your bean to call OES.

Your bean then looks like this:

public class AuthorizationBean {    public boolean getMaySeePatients() {        AZRequestHandler az = new AZRequestHandler("view", "Patient");        return az.isAuthorized();    } } 

JSF provides a few other simple ways to call this logic, for example c:choose which implements if/then/else logic

<c:choose> <c:when test="${Authorization.maySeePatients}">  <af:outputtext value="You can see patients"> </af:outputtext></c:when> <c:otherwise>  <af:outputtext value="You are not authorized to see patients"> </af:outputtext></c:otherwise> </c:choose>

Simple, huh?

Unfortunately while all of this makes it easy to protect your JSF application with OES, it relies on the developer (a) knowing what to secure and (b) properly calling the security system. Part of the point of OES is that once you plug it into your application you get a bunch of stuff secured automatically and if you need to secure anything else later you don't have to change the source code to the application.

So how do we do that?

Stay tuned!

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha