Monday, October 19, 2009

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


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

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

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!


  1. Hi Chris,
    We are planning to use OES in one of our deployments and want to use OES managment API's but I couldn't find any examples either to use webservice calls or java api's.
    Can you post an example to use management api or web service with steps to configure the client?


  2. Sagar: Examples of both local and remote calls to the management APIs are included in the Admin server's installation directory. In ales32-admin/examples you should see three directories of interest policymgtapi, policymgtwsapi, and policymgtwsapi4dotnet. The first two are Java examples of local and remote Web Services based interfaces. The last one is a .NET example calling the Web Services interface.

    I am curious about what you're planning to do with the interface since most deployments of OES have no need to use the management interface. Could you post a comment letting us know?

  3. Thanks Chris,
    I am totaly new to OES and did found the examples after I wrote the comment.

    Let me explain you something about the use case I am trying to achieve.

    We have an existing admin interface through which we have to manage everything which is dynamic. The underlying products involve OIM, OID, OAM, OAAM, OWSM and OES. All of them integrated with each other. Let me explain you how.
    1. User is created from the front end -> web service calls to OIM to create user, set access permissions, set roles etc..
    2. OIM provision the information in OID
    3. OID is the user store for OAM and OES
    4. User accesses application protected by OAM
    5. OAAM is integrated with OAM for authentication.
    6. User profile information is passed along with the risk analysis information to the underlying application.
    7. The underlying application calls OES for authorization of its resources with the inforamtion from OAM i.e. userid, role, risk score etc...
    8. If the application needs to make any web service calls OWSM comes into picture which is again integrated with OAM for authentication.

    Everything here is managed from a single front-end. except the OES stuff. Policies are a static thing here and will hardly change, but who has access to what changes often, To automate that change I need to expose OES management api's /web service calls to the front end.

  4. sags: Hmm.

    I'm writing a longer article on how to write manageable OES policies, but it sounds like you MAY have a use case that COULD POSSIBLY have some instances where calling the BLM from your app MIGHT be sensible.

    Note how many qualifiers I have in that sentence? Your use case feels like "when all you have is a hammer" uses and I'd hate to see you waste your time with the wrong approach.

    For now I'd suggest two things:
    1) get in touch with OCS or one of our integrator partners that has experience with OES. They're well equipped to help you figure out the best way to attack your requirements in your environment

    2) consider using the BLM and add users as you need them. What I mean is let your policy manager person enter the username or pick off a list of users you generate from OIM or OID. After they pick some permissions for that user and go to save their changes back you check OES to see if the user exists in OES's user database - if they don't add them then. Finally go ahead and create/update your policies as needed.

    Please contact me offline at christopher dot johnson at oracle dot com. I'd like to help you find a better way.

  5. Chris,

    Great post! Looking forward for the next entry!

    []s! :-)

  6. Hi Chris,
    I have created a sample Web Service and deployed in web logic server and test it.

    Now the requirement is to secure the web Service using OES, i have configured the web service in OES , and created a policy in OES. Now when i access the web service from SOAP UI, I am getting the following exception, Please advice

    weblogic.wsee.util.AccessException: Access Denied to operation getInstrumentList
    at weblogic.wsee.handler.HandlerIterator.handleRequest(
    at weblogic.wsee.server.servlet.SoapProcessor.handlePost(
    at weblogic.wsee.server.servlet.SoapProcessor.process(
    at weblogic.wsee.server.servlet.BaseWSServlet$
    at weblogic.wsee.server.servlet.BaseWSServlet.service(
    at javax.servlet.http.HttpServlet.service(
    at weblogic.servlet.internal.StubSecurityHelper$
    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(
    at weblogic.servlet.internal.ServletStubImpl.execute(
    at weblogic.servlet.internal.ServletStubImpl.execute(
    at weblogic.servlet.internal.WebAppServletContext$
    at Source)
    at weblogic.servlet.internal.WebAppServletContext.securedExecute(
    at weblogic.servlet.internal.WebAppServletContext.execute(

  7. Sridar: Can you post to OTN or open a support case? Those would be better forums to help you get this resolved.

  8. This comment has been removed by a blog administrator.

  9. I am helping a client who wants to use OES to protect standalone ADF applications running on weblogic for fine grained access control. Based on my research , here is what I found -

    1. ADF , Webcenter and SOA use JRF template.
    2. OES Policy Client is currently not supported to be installed in Weblogic container extended with JRF.

    Based on above ,that would mean that OES SSM ( Embedded PDP ) cannot be used for ADF applications . Am I missing something here ?

    My second question is - Can ADF really use OES Policies ? As I understand , Fine grained security with ADF applications ( e.g. enabling or disabling a command button ) is driven by ADF Security Framework ( consumes OPSS ) which basically uses enterprise/application roles to protect ADF components. How can we use OES Policies to protect ADF components using declarative approach ?

    Please advice.

  10. The above post was talking about OES 10g.

    You are right - OES 11g is currently not supported in a domain with JRF.


Note: Only a member of this blog may post a comment.