OIM 11g R2 UI Customization Tips and Tricks

Introduction

OIM 11g R2 has finally provided OIM Developers with the means to implement very sophisticated and functional rich customizations to the Out of the Box User Interface of OIM; and the best part is, all these customizations are patching and upgrade transparent, which means that when the OIM installation is upgraded or patched, the customizations don’t have to be re-applied. Everything is stored in the metadata repository (MDS) and it is applied on top of the standard user interface. This article presents a few techniques to implement customizations that go a little beyond the capabilities of Web Composer; but still are within the scope of OIM’s MDS. Each technique will be presented in the context of a use case addressed by the customization implemented using the given technique.

On a recent post by Daniel Gralewski, there was a very nice customization for the Catalog. The purpose of such customization was to filter the resources already provisioned to a user from the results of a catalog search. In a follow up question, one of our readers asked if the search screen could be customized to add a drop down box that can be used to trigger a predefined search, like a catalog search based on role category.

So I thought that would be a nice use case to start, here is what I envisioned based on certain requirements from an actual customer I am helping at the present time.

Protecting a WebCenter app with OAM 11g

Last year I wrote an article on OAM and ADF Applications with Anonymous access. This week I did some work with another A-Team guy building on that previous work.

The new requirement was that the customer wanted two different portions of the app to be protected by different login pages. In other words a user would start on an unprotected page and then choose to go to "A" or "B". If you click on "A" you see one login page and then (after logging in) you see page A. If you click on B you see a different login page and then page B.

If I was doing this with plain old HTML or JSPs I would probably just put A's resources in directory /a/ and B's resources in /b/ and we'd be done. But as you know from the previous post things can get a little bit more complex when you are using ADF.

Martin is going to blog more deeply about the ADF side of the story (link to follow) and I'm blogging about the OAM setup side.

Martin's post is now available on the A-Team's WebCenter blog.

Using OIM 11g APIs in Fusion Web Applications

Introduction

The purpose of this article is to describe the setup needed to build ADF/Fusion Web Applications using JDeveloper that make use of OIM 11g new API's and Services.


Overview

I have encountered many users that are trying to develop applications using the OIMClient classes and face the following Exception:

Can't find wsdl /wsdls/wsat11/wstx-wsat-1.1-wsdl-200702.wsdl
at weblogic.wsee.deploy.WSEEModule.prepare(WSEEModule.java:146)
at weblogic.wsee.deploy.AppDeploymentExtensionFactory.prepare(AppDeploymentExtensionFactory.java:147)
at weblogic.wsee.deploy.AppDeploymentExtensionFactory.access$100(AppDeploymentExtensionFactory.java:27)
at weblogic.wsee.deploy.AppDeploymentExtensionFactory$1.prepare(AppDeploymentExtensionFactory.java:427)
at weblogic.application.internal.flow.AppDeploymentExtensionFlow.prepare(AppDeploymentExtensionFlow.java:23)
Truncated. see log file for complete stacktrace

This happens when trying to deploy the ADF application to a WebLogic Managed Server within a domain. This unfortunately is not documented anywhere and many customers have been very frustrated looking for answers. So here it is.


Solution

The problem is due to a conflict with the class loading of wlfullclient.jar and oimclient.jar. The latter is needed for your OIM code to compile properly. So the solution to the problem is to simply add wlfullclient.jar and oimclient.jar to the lib directory of your domain (i.e. OFMW_HOME/user_projects/domains/myDomain/lib) and you must exclude oimclient.jar from the deployment profile that creates your EAR file and the WAR inside it. Make sure you remove these dependencies in the ViewController project which is the one that creates the WAR file Application Module.

Deploy your application to an EAR file first so you can check that no references to oimclient.jar nor wlfullclient.jar are in the WAR file. JDeveloper lets you look at that by clicking on the link to the generated EAR file provided in the Deployment window at the bottom. Double click the _ViewController_webapp1.war file to look at the content and the included libraries. Make sure there are no references to either oimclient.jar nor wlfullclient.jar.

If you try to deploy this archive using Weblogic's Console it should deploy just fine and when you activate the changes no exceptions about missing wsdls will be thrown.

OAM and ADF applications with Anonymous access

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

In the last post here we pointed to Olaf's blog on integrating your ADF app with OAM. That post covers taking an ADF app that was protected with Forms auth and switching it over to be protected in its entirety by OAM. In other words to access any part of the app you have to log into OAM. Once you're logged in to OAM you access the app and OAM sends your identity down.

But what if you want to let users access part of the app anonymously, but require them to log in to access some of the apps features? I don't know what anyone else calls this sort of flow, but I call it the shopping cart model (browse around tossing stuff in your card, then sign in to check out).

I recently wired this flow up in an ADF application (I started with Olaf's sample app). All in all it was pretty easy once I got everything setup, but I couldn't find any docs spelling the process out step by step. So without further ado...

This is what Olaf's app looks like before you login:

When you click on the Action menu there's one option - "Login". If you look at the source you'll see that this triggers a pop-up for you to enter your credentials:

                    <af:menuBar id="pt_mb1">
                      <af:menu text="Action" id="pt_m2"
                               textAndAccessKey="&Action">
                        <af:commandMenuItem text="Login" id="pt_cmi2"
                                            rendered="#{!securityContext.authenticated}"
                                            >
                          <af:showPopupBehavior popupId="loginPopup"
                                                triggerType="action"/>                                                
                        </af:commandMenuItem>
                        <af:commandMenuItem text="Logout" id="pt_cmi3" action="#{login.performLogout}"
                                            rendered="#{securityContext.authenticated}"/>
                      </af:menu>

We're going to get rid of that pop-up login box and switch over to an OAM login page. To do that there's only three simple things that need to be changed:

1. Configure OAM to protect the ADF authentication URL but leave everything else unprotected
2. Configure the OAM Identity Asserter
3. Change the web.xml to work with OAM
4. Change the login menu option to force you through the ADF authentication URL which is protected by OAM

Click through for a step-by-step

Oracle Access Manager 11g, Oracle Forms, and a little ADF

While this post is mostly a link to an external blog, it contains good information, so I’ll be including this post in my OAM 11g Academy Series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html


Our friend from Europe, Olaf Heimburger, has written a couple good blog posts on integrating OAM 11g with Oracle Forms. In the 2nd post he’s thrown in a little about OAM/ADF integration (though there is more to cover on that subject).

His posts can be found here:

https://blogs.oracle.com/olaf/entry/ofm_11g_implementing_oam_sso_w
https://blogs.oracle.com/olaf/entry/ofm_11g_oam_sso_for_forms_and

Old links that no longer work for some reason:
http://blogs.oracle.com/olaf/2011/01/ofm_11g_implementing_oam_sso_w.html
http://blogs.oracle.com/olaf/2011/02/ofm_11g_oam_sso_for_forms_and.html

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

   Authorization
   com.oracle.demo.drapp.view.backing.AuthorizationBean
   session

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!

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...

ADF and OES, part one of many

Before I get into the guts of a post allow me to introduce myself. I'm Chris Johnson (nice to meet you) and, like Josh and Brian, am a member of the Fusion Middleware Architecture Group; AKA the A-Team (cue theme music here). When Josh started this blog he invited me to join in and I promised to do so. Today I make good on that promise with this, the first of a number of posts on using OES to secure an ADF Web Application. This post will cover getting an OES enabled WebLogic domain to startup properly and run your ADF based web app. The second post will show how to write OES policies to protect URLs. And finally in the third post I'll discuss how to really dig down into the app and apply OES' fine grained access control to secure links, buttons, tabs and other components.

Oracle Entitlements Server is a product that we've discussed here before. For new readers the quickest way to describe OES is as a way to take all of the authorization logic out of your application and put it in a better tool with central configuration and management. OES is to the authorization logic as something like OAM or SiteMinder is to the login code you used to keep in your application.

Oracle Application Development Framework (ADF) is "an end-to-end Java EE framework that simplifies development by providing out of the box infrastructure services and a visual and declarative development experience." ADF is a complete framework for developing applications, but the easiest bit to bite off first is ADF Faces. If you're familiar with JSF you can think of ADF as a bunch of really high quality AJAX based UI components for JSF plus a great development environment (JDeveloper) plus a bunch of other stuff to make your life easier.

ADF has a security framework can be used on its own or in conjunction with OES but in these posts I'm going to pretend that ADF just JSF. I'm doing this intentionally for a number of reasons, the most important of which is a desire to document and describe how to use OES with JSF alone. Truth be told another part is that while I know quite a bit about OES I actually know fairly little about ADF since I just began using it to build my OpenWorld demonstration part time a couple of weeks ago. I'll be telling you more about my session in another post soon enough.

As with all posts on this site please remember to check the current support status of the products before planning a production deployment. As of this writing the OES Security Module for WebLogic is not currently supported on WebLogic 11g R1, but as Josh mentioned in the first of his OES + SOA Suite posts it does seem to work just fine.

The basic environment I'm using is:

• Oracle Enterprise Linux
  
• WebLogic 11g R1
  
• Oracle Entitlement Server 10gR3 Admin Server (with CP2)
  
• Oracle Entitlement Server 10gR3 Security Module (with CP1)
  
• JDeveloper 11g R1
  

I created my application in JDeveloper and was able to test as I went along with the built in WebLogic Server. Once I reached a reasonable point I wanted to deploy it into a standalone OES-enabled WebLogic Server domain. The steps I took were:

1. Create a WebLogic domain using the Configuration Wizard
   
2. use the OES Config Tool to create your SSM instance and load the basic policies needed to boot the domain
   
3. switch the default security realm back to myrealm
   
4. boot the domain
   
5. use the WebLogic console to adjust the security providers so that OPSS will work
   
6. switch the default security realm back to OES
   
7. boot your domain
   
8. celebrate
   

The first couple of steps are well documented elsewhere, but I'll cover them quickly here just for completeness.

Create WebLogic Domain
The Fusion Middleware Configuration Wizard will create a new WebLogic Server domain or extend an existing domain. On Windows you can find that tool in your Start Menu, on Unix it's in Oracle/Middleware/wlserver_10.3/common/bin/config.sh. Because ADF uses the Java Runtime Framework (JRF) if you're using ADF rather than simple JSF pages remember to check the JRF box when creating your WebLogic Domain!

Use the Config Tool to create an SSM
The OES ConfigTool will create an SSM instance, load the policies necessary to boot the WebLogic domain and will configure WebLogic to use the OES Database Authenticator as well as the Authorization, Role Mapping and Audit Providers.

If you try to start your WebLogic Server at this point you'll get an exception from oracle.security.jps.JpsException "Exception while getting default policy Provider". If you read through the error you'll see another error "No Default or LDAP Authenticator configured on WLS". Josh discussed using the Default Authenticator and I want to use LDAP anyway so...

Switch the default security realm back to myrealm
Make a backup of the config/config.xml file, then edit the original with Notepad, vi, emacs or any other plain text editor. Search for the line that contains default-realm and change the value from whatever it currently says to myrealm but take careful note of the value you have there as you will need it later.

Boot your domain
run startWebLogic.sh/.bat and boot your domain

Adjust the WebLogic Security Providers
I already mentioned that Josh discussed the DefaultAuthenticator so here's my shameless copy/paste of what he said:

Next, log into the weblogic console http://localhost:7001/console, and create the DefaultAuthenticator and the DefaultIdentityAsserter. Set the JAAS Control Flag on both the DefaultAuthenticator and the DatabaseAuthenticator to SUFFICIENT and order the DefaultAuthenticator first (I'll explain why in a second).

Oh, so the reason for having to have a specific ordering on the authentication providers, and having the DefaultAuthenticator first and sufficient is that the DatabaseAuthenticator adds a special IdentityDirectoryPrincipal, that JDeveloper doesn't have the classes - so I simplified this by "tweaking" the realm. In practice, the DatabaseAuthenticator is not really used, but it is the authentication provider that is created by default in the configtool. This is really just a minor issue, but I wanted people to understand why the change.

If you're going to use JDeveloper to deploy your app to the domain then you should follow his instructions. If you've already deployed the application to the domain or don't plan to use JDeveloper to do that you can go ahead and plug in an LDAP Authenticator instead.

In any case remember to set the order properly and make the DefaultAuthenticator sufficient if you use it. Once you've made the changes shut the WebLogic Server down.

Switch the default security realm back to OES
Edit config.xml again, being sure to reload it from disk to pick up the changes we made a moment ago. Again find the default-realm and change the value back to what was there originally.

Boot your domain
Run startWebLogic again and the domain should startup normally. Wait until you see it reach the RUNNING state before pouring your margarita, martini or beer, then by all means enjoy!

Next up - securing your JSPs, Servlets and JSF pages with OES.