Friday, September 4, 2015

Work with the ADF Control State on External Link URL in WebCenter Portal Navigation Model

In the Navigation Model of a WebCenter Portal application (11g), there is an option to define a navigation resource by "external link". In a normal case, you should NOT define any internal JSPX page using this option, but only if there is a need to navigate to a third party site - by what the name means, an external link. The internal JSPX page should be added to the Navigation Model by the "page" type.

The impact of defining internal JSPX page as an external link is, the redundant memory footprint due to the ADF control state token recreations every time this external link is clicked. ADF control token is an identifier used by the Controller to track user's state so that all in process task flows for the same user can be retrieved. Normally, this ADF control state should be not recreated for the same user. With the external link type, the navigation behaves like entering the application in a blank new context so every navigation with external link type will auto generate a new ADF control token. Within the same user session, the recreations of the ADF control token mean redundant memory use. The less negative thing is the ADF control state will be garbage collected after user session is invalidated. So this memory issue is only scoped within user sessions and will not accumulate over time - well this is assuming your application doesn't have a crazy long timeout setting nor your users would stay active for long time (long or short, is relative. It's impossible to name a threshold without doing some load testing and analyses on the application, as at the end of the day every application is different). In this regard, it's not a memory leak in time. However, when there is a high concurrency of users navigating the application, this issue could be a concern.

The main focus of this post is how to get around this memory issue with the external link type for internal JSPX page. You may ask what's the use case for this type of implementation - well, there is always some special unique use case down the road you might come across one day. Let's say one day you cannot use goLink and commandLink on the navigation model, but rather have to a programmatic redirect to some other page in your application with this ADF control state recreation issue.

The foremost thing is to understand the navigation model - why using navigation model API would keep the ADF control token intact throughout the application. Let's start with a new WebCenter Portal framework application and understand what navigation model API would do.

In the home.jspx page, add a navigation model goLink prettyURL syntax as the value of an output text like below.

It's basically printing out the navigation model prettyURL of the home page. When the page renders, you would see -

The navigation model prettyURL returns "/faces/home?_adf.ctrl-state=xxxxx". So the secret of navigation model capable of keeping the same ADF control token around is to attach it as a query string in the URL on every navigation.

After this is figured out, the rest should be easy. To use external link to reference an internal JSPX page, it's necessary to make the URL path relative so that your application can work properly on different environment. When defining an external link in navigation model, the URL field doesn't have the expression language facility (a nice popup that you can build objects using EL trees) but we still can use EL to construct the URL.

Using the home.jspx as an example, here is the syntax we should use:


Here is the External Link definition in the navigation model -

Note we need to add the "_adf.ctrl-state" URL parameter below. Alternatively, you can also define the URL parameters as part of the URL like


The source of the external link definition looks like below:

Note the actual prettyURL is not mandatory. "/faces/home" can also be replaced by "/faces/oracle/webcenter/portalapp/pages/home.jspx".

Now we can run the application. When clicking between the Home and "Home External Link", the ADF control state never changes.

Wednesday, July 29, 2015

Understand WebCenter/ADF Session Invalidation and Removal

There are a couple of ways to invalidate the session in WebCenter Portal (or ADF) application. They are not the same. They all would invalidate the user session which is intended. The main difference is around whether the session will be removed after it's invalidated. In this post, I will walk through this.

In WebCenter Portal framework application, the built-in page template already has a logout function provided. Let's take a look at it.

Create a WebCenter portal application and open up the page template as below

In this JSPX file, you will find a logout command link with action specified as "#{o_w_s_l_LoginBackingBean.doLogout}". The source code of this bean is not available unless you trace back to the shipped libraries that were installed with Jdeveloper.

Let's take a look at the effect of the logout function. Run the portal application.

Open the local weblogic console, navigate to the deployment, find your application, go to application configuration, and select the monitor tab to look at the session statistics.

Before going forward, let's look at the definitions of the 3 columns we are interested in:

  • Sessions: Displays the current number of open sessions associated with this web application.
  • Sessions High: Displays the highest number of concurrent open sessions associated with this web application that have ever been reached since the weblogic instance was started.
  • Total Sessions: Displays the total number of open sessions ever associated with this web application.

We can see there is 1 current open session. At this time the user is not logged in yet. So it's anonymous session. Please note this is true for an type of pages - JSP, JSPX or HTML, as long as they are part of the web application (war or ear). If you may need to avoid this anonymous session, assuming your application entry page is not dynamic, you can consider build such login page in HTML and store it in web server. In this case, there will no session attached when such page is visited.

Let's login.

Check the session statistics again, we can see the current open session is still 1 but the session high and total session is 2. The anonymous session gets removed and a new authenticated user session created. That makes sense.

Let's logout and check the session statistics again. Now the open session is 2, session high is 2 and total session is 4. What does this mean?
Let's review the numbers. Total session increases from 2 to 4. That means 2 new sessions created. But the open session increases from 1 to 2. That means there are 2 current open session, increased only 1 from previous state. One thing to note is after the logout, the page lands on the entry page again just like the page before the login.

The explanation on above behaviors would be the previous authenticate session gets removed, but as soon as it's removed, an anonymous session is created. It's like the authenticated session gets converted to an anonymous session. Since the page is redirected to the login page, it's just like the initial rendering of the login page, there is a new anonymous session created. So it's 2 - one is not associated with the current UI (login page) and the other is associated. When the first anonymous session will be removed? It will be removed after the session timeout setting reached (set in web.xml). The second anonymous session will be removed after the server detects the user is idle for the session timeout setting reached.

Well, you may say that's not desired. Correct, it's not. Let's look how can we avoid the redundant anonymous sessions.

We have reviewed the second anonymous session is associated with page as it's part of the web application. Let's do a test and force the redirection to go to a page outside of the web application. To do such redirect, we will need to put in some custom code. I am going to reuse the WebCenter portal built-in logout function by taking the expression inside my managed bean.

Here is the custom managed bean associated with the command link:

Here is the logic for the custom managed bean:

Basically, I used an utility method to resolve the expression function to logout. Then issue a redirect to the server host. Here is the page landed after the logout.

Let's look at the session statistics again. Since the statistics are the same until the logout, here is just the statistics after issuing a logout.

Now we can see there is only 1 open session with total session of 3. This open session is the anonymous session converted from authenticated users session.

Next, let's look at how to avoid the anonymous session conversion but rather to remove it for good.

After some trials, none of the JEE related methods work as expected. This includes HttpSession.invalidate(), HttpSession.setMaxInactiveInterval(), and a few other methods. No mistaken, the session indeed get invalidated and there is no security concern, but the redundant anonymous session (not associated with any front-end) hanging around is the complaint.

The only working way is to use the ADF authentication servlet. Here is the code snippet to use:

In the code, I used "/adfAuthentication?logout=true&end_url=../" to call the ADF authentication servlet to invalidate the user (and remove the session) and redirect the page to host with parameter "end_url". The ADF authentication servlet is defined in web.xml by default:

Now let's use the new doLogout() method which uses ADF authentication Servlet to logout and review the session statistics after logout:

Great. There is 0 open sessions and no redundant session hanging around.


1. To avoid anonymous session before login or after logout, please redirect to pages outside of web application.
2. To avoid anonymous session hanging around being converted from authenticated session, please use ADF authenticate servlet to logout.

Tuesday, July 21, 2015

Sunday, July 19, 2015

Install JDeveloper on OS X with JDK7

The info is taken from this post:

Thanks to Justin, it saved quite some efforts.

1 If you do not have Apple Java 1.6, download it here (Java for OS X 2014-001).
2 Start the JDeveloper installer using Apple Java 1.6.
3 $(/usr/libexec/java_home -v 1.6)/bin/java -jar ~/Downloads/jdevstudio11119install.jar
4 Follow the screens and when you reach the portion of the installer that asks for the JDK, point it to your JDK 1.7 location. In my case, I have used JDK 7u80.
5 /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home

6 Complete the installation.

Tuesday, October 21, 2014

IE11 Support has come to WebCenter BP5

If you are on edge of using IE as your support browser, IE 11 support on WebCenter has come. The patch for it is initially released via BP4 and included in BP5. Please see the link for the details: 

Tuesday, October 7, 2014

Required Flag for the View Object Bind Variable

When creating a bind variable for a view object in ADF, there are two properties can be configured - Updatable and Required.

The updatable flag should be enabled pretty much all the time as it allows you to change the bind variable value to run the query again. For the Required flag, it should be disabled unless you specifically need it - seems worthless to say ...

When the required is enabled, the bind variable will be defined as "Kind=where" - this can be examined in the view object xml file. This is pretty straightforward. "Kind=where" means this bind variable will always be added into the where clause when this VO is queried. Therefore it's always "required".

When the required is disabled, the bind variable will be defined as "Kind=viewcriteria". This means this bind variable is optional and can be added by applying the corresponding view criteria. Therefore it's not required.

In most cases, the bind variable should be optional. Unless this VO instance is meant to be queried with the specific where clause all the time.

Tuesday, September 2, 2014

Oracle WebCenter Portal Mobilizing – Responsive or Adaptive, or Both?

With today’s quickly evolving web and advanced rendering capabilities, enterprise continues to seek applications with which to run massive amounts of transactional data on mobile devices. Few applications can support the increasing mobility of interfacing technologies, and those that do require teams of engineers to build and maintain them across multiple platforms. This extra layer of complexity and cost can prohibit some enterprises, and dissuade others seeking more flexible and wide-reaching data infrastructure.

Read more ...

Sunday, July 13, 2014

IOUG Speaking - Build Your Responsive & Mobilized Enterprise Portal

Hi there,

For those of you who missed out my Collaborate 14 presentation on WebCenter Responsive Web Design, here is another chance for you to regain the opportunity, for free!

Here is the summary of the talk. You can register the event by the link provided at the bottom.


Thursday, July 17th, 2014 12:00 p.m. - 1:00 p.m. CDT
Mobilizing emerges as a "must-have" feature for modern web experience. Oracle WebCenter Portal introduces multi-channel portal experience to support mobilized web for smart devices. This session reveals the essential secret sauce of the new mobilizing support – responsive web design, and teaches how to extend the responsive template to support your custom needs. The session helps to determine your mobile enterprise portal strategy and teaches how to build the responsive from scratch to create your own mobilized enterprise portal on WebCenter Portal Framework applications. Further, the session analyzes real world customer cases to help you avoid the pitfalls and exploit first hand best practices.
Featured Speakers: JayJay Zheng, Director, Primitive Logic

You can register the event by  clicking | Register Here |

Tuesday, May 27, 2014

Caveats on Using WebLogic Server with JDK7

Now JDK 7 has been out for a while (JDK 8 is out too as of writing). There are some caveats using WebLogic Server with JDK 7 you might want to know, not matter it's on 10.3.6 or 12c.

1. Out of memory error on starting Admin Server. This error is caused by the fact that the new JVM requires more PermGen space. Depending on your RAM, you can set it >350m. In my case, I would set the perm size to 512M.


2. In some cases, the new compiler generates larger byte code. It is possible that a large method may exceed the 64KB limit per method. In this situation, you may need to refactor the method. This seems to only affect WebLogic 10.3.6

3. Classes may have been removed that are from the internal package sun.*, or that have been marked as deprecated in a previous version of the JVM. If an application uses these removed methods, a ClassNotFound exception will occur.

4. JDBC 4.1 is introduced in JDK7. JDBC 4.1 methods are not currently supported in WebLogic Server with JDK 7. Calls to these methods will result in an SQLException indicating that the method is not supported.

If you are using WebLogic 10.3.6, after installing WebLogic Server, copy the following files from WL_HOME/modules to JAVA_HOME/jre/lib/endorsed, where WL_HOME is the WebLogic Server installation home directory:
  • javax.annotation_1.0.0.0_1-0.jar
  • javax.xml.bind_2.1.1.jar
  • javax.xml.ws_2.1.1.jar


Monday, May 26, 2014

FrameworkFolders Support has come to Oracle WebCenter Portal

As of late April 2014, FrameworkFolders support on Oracle WebCenter Portal has been enabled by Oracle WebCenter Previously, Oracle WebCenter Portal only supported Folders_g.

Now it's time to review the essentials on what, why and how.

What's Framework Folders?

Introduced in WebCenter PS5, the framework folders (also called folders component) provide a hierarchical folder interface, similar to conventional file system, for organizing and locating some or all of the content in the repository. It's a scalable, enterprise solution and is meant to be a replacement for contribution folders (folders_g component).

Why it's better than Folders_g (FrameworkFolders vs. Folders_g)?

With the FrameworkFolders component as the underlying folder architecture, many functionalities and features have been made available.
  • Mass metadata updates with folders (metadata propagation):  "Query Folders" is added in the FrameworkFolders component. Query folders are folders that are populated simply by a query. Query folders contain the actual repository content items returned by the query. The contents of query folders can change dynamically as the contents of the repository change. By using the query folder and the propagate function, one can make mass metadata updates of folders in a very easy way.
  • Unlimited content items: There is a limitation of 1000 content items in a folder or subfolders within a folder with Folders_g. There is no such limit with FrameworkFolders.
  • Enhanced search functionality: With frameworkFolders, several enhanced features are available to make search easier and more performant. User can save a query result in a query folder, as well as records management by using RetentionQuery folder. By default, you cannot search folders with folders_g. Now users can search for folders, content items within a folder with FrameworkFolders.
  • Personal folder support: Added personal folder for each user and the content within a personal folder is only available for the user himself/herself.
  • New user interface support: with the FrameworkFolders component, a new look and feel presentation layer of the content server is available. The new UI is built by ADF technology.
How to get it?

For an Oracle WebCenter Portal instance patched from an earlier release, you must continue to use Folders_g. For new installations of Oracle WebCenter Portal, it is recommended that you enable the FrameworkFolders component on Content Server for better performance and so as to be able to use any new Content Server features.

The FrameworkFolders component can be enabled only for the installations that meet the following criteria:

  • You must have a new Oracle WebCenter Portal installation. Oracle WebCenter Portal must not have been patched from a previous release, that is, it should be a completely fresh instance.
  • You must have a new installation of Oracle WebCenter Content, with the FrameworkFolders component enabled. Oracle WebCenter Content must not have been patched from a previous release, that is, it should be a completely fresh instance.
  • Content Server should never have been configured to run with the Folders_g component. You must not enable FrameworkFolders if Folders_g was previously enabled.

To configure FrameworkFolders support for Oracle WebCenter Portal, you need to apply various patches to your new installations of Oracle WebCenter Content and Oracle WebCenter Portal

To prepare Oracle WebCenter Portal for FrameworkFolders support:

  • Ensure there is no content within Oracle WebCenter Content and Oracle WebCenter Portal
  • Download and apply the WebCenter Content MLR04 patch (latest as of today)
  • Download and apply the WebCenter Portal BP3 patch 18085041
  • Download and apply the WebCenterConfigure component patch 18387955


11g Folders – organized, optimized, modernized
Mass Metadata Update with Folders
WebCenter Content FrameworkFolders
Using Folders and WebDAV
Folder Services

Tuesday, April 22, 2014

Interview with Bob Rhubart on Responsive WebCenter Portal @ Collaborate 14

Short after my presentation on Responsive WebCenter Portal @ Collaborate 14 in Vegas, I had a video interview with Bob Rhubart who runs Oracle ArchBeat - the official blog of the OTN Architect Community. In this 10 min talk, I had reviewed my presentation topic, the hot gossips in the hallway and the visions of hot topics in the next coming collaborate.

Sunday, April 20, 2014

Building a Responsive WebCenter Portal Application - Technical Paper Published

In this article I reviewed the essentials of responsive web design, walked through how to design and develop a responsive WebCenter Portal application, and reviewed the essential development considerations. The article covers technical aspects of building a responsive WebCenter Portal as well as the business decision points behind each scenario. It is intended for software architects, developers, and business users who regularly work with Oracle WebCenter Portal.

Monday, April 7, 2014

Build Your Responsive & Mobilized Enterprise Portal

Let’s collaborate at Collaborate14!
Location: Las Vegas, NV – Venetian & Sands Expo Center
Dates: April 7th – April 11th
Build Your Responsive & Mobilized Enterprise Portal, by JayJay Zheng

Date: 04/10/2014
Time: 11:00 AM – 12:00 PM
Location: Level 3, San Polo 3502
Abstract: Mobilizing emerges as a "must-have" feature for modern web experience. Oracle WebCenter Portal introduces multi-channel portal experience to support mobilized web for smart devices. This session reveals the essential secret sauce of the new mobilizing support – responsive web design, and teaches how to extend the responsive template to support your custom needs. The session helps to determine your mobile enterprise portal strategy and teaches how to build the responsive from scratch to create your own mobilized enterprise portal on WebCenter Portal Framework applications. Further, the session analyzes real world customer cases to help you avoid the pitfalls and exploit first hand best practices.

Objective 1: Discover fundamentals utilized in the Oracle WebCenter mobile support.

Objective 2: Describe and explain how to build a responsive template from scratch.

Objective 3: Discuss mobile enterprise portal strategy for various organizations' needs and analyzes the real world customer cases for mobile support.

Monday, February 24, 2014

Bypass the IE Compatibility Mode (IE8/9) in ADF/WebCenter App

Some times the IE compatibility mode is enforced to be used by your system admin at an enterprise level, especially for the intranet sites. Since Jdeveloper, a popup warning is shown to the user when ADF/WebCenter application is running on compat mode. The issues seen in compat mode is not supported by Oracle.

The solution to bypass the compat mode has been documented via Oracle Doc 1555476.1. I'd like to extract the key information of the such solution here:

A new feature has been introduced in JDeveloper/ADF and and backported to,, and through patch 14400317.
It consists of bypassing Compatibility Mode in IE browsers. The ADF framework will force the target document to the maximum document mode supported by the browser using the X-UA-Compatible META tag. This applies to desktop browsers in compatibility view mode and also applications that use the IE WebBrowser component to host content within desktop applications. For more information see ADF Faces Release Notes at

To set this feature, apply the following:

1. For,, 1. and, download and apply patch 14400317 in your JDeveloper/ADF environment.

2. For all the above mentioned versions, add, in the web.xml file of your ViewController project, the following context-param to enabled agent version detection using the Trident version over the browser version:



3. Finally, apply the patch to all environments where the application will also be deployed.

Sunday, February 23, 2014

Inline Style Isn't Just for CSS Styles

Inline styles are CSS styles applied to an user interface element. Multiple properties can be applied to an element and they are separated by semi-colon. Inline styles take highest precedence. Styling rules defined by inlineStyle in ADF are added directly to the JSF page source as part of the component markup. Any styles defined in CSS style class will be overridden by the inline styles on the element. This is an advantage as well as disadvantage. Element styles can be overridden unintentionally. For re-usability and maintenance, extensive use of inline styles should be avoided.

In this post I will discuss another use of inline style which is an uncommon use case in WebCenter Portal. It isn't just for CSS styles as I found in my recent practice. The inline style can set the selected state of a navigation node in WebCenter portal application. This is a very unique use case. It has to satisfy the following scenario:

1. Go link is used to implement the navigation model links. There are a few reasons golink is favored vs. command link in WebCenter Portal application. A team has a blogpost discussing this.

2. Redirect option is set to true for the navigation links.WebCenter by default uses PPR for navigation. The URL in the browser isn't to reflect the current page. Your heaven can be someone else's hell. I have seen this is specifically required by business users. To enable the browser to display the URL of the current page, you will need to set the redirect option to true. There are two ways to do this.
a): set the context parameter oracle.webcenter.navigationframework.REDIRECT_OPTIONS in the web.xml to toPrettyURL.

The following snippet should be added to web.xml

b). You can also set the individual navigation link redirect option. This is configured in the navigation model xml file. Each navigation link defined in the navigation model has two options "Redirect to URL" and "Render URL in page template". Selecting "Redirect to URL" will also enforce the URL to be displayed in the actual URL of current page. Selecting "Redirect to URL" will add the following in the navigation model xml file:

<attribute value="true" isKey="false" attributeId="Redirect"/>

Setting the oracle.webcenter.navigationframework.REDIRECT_OPTIONS context parameter affects performance by adding an extra request/response for every navigation.

In my example, I used an ADF breadcrumb task flow (either the OOTB one or custom one) to map a navigation model in a WebCenter portal framework application.

We have a home page and it's the default home page for the portal application. After application starts, the breadcrumb works fine and will reflect the landed page correctly if we navigate from one link to another in the navigation. But it breaks when you copy one of the page URL and directly access it from your browser. This time, the breadcrumb will only display the last accessed landed page (not the current one). If the page isn't accessed yet, it will default to the home page node in the breadcrumb. Therefore the deep linked page failed in this case.

To illustrate the issue, I am attaching some images.

Step 1: run the application and the home page renders with "home" breadcrumb.

Step 2:Navigate to a child link

Step 3: The breadcrumb is reflected correctly. Note down the URL of this child link.

Step 4:  Navigate back to home page.

Step 5: Paste the child link (from step3) to a second tab and hit enter.

You will find the breadcrumb is still showing the home tab, which is incorrect. In this case, the breadcrumb is not "notified" of the current selected navigation node (page 3, in this case) and still think "home" node (last visited) is the current state of the breadcrumb.

The solution to the above issue is to define the following in the inline style of the each go link navigation implementation to enforce the selected state to be updated.

inlineStyle="#{node.selected ? '' : ''}"

In the above, both the expression for the inline style is empty no matter the node is selected or not, this is because I do not need to define any css styling for this element.

You can download the example application here.

Sunday, November 3, 2013

Reentrantlock Caused Content Presenter Performance Issues for > 1000 Concurrent Users

Thanks Martin Deh from A-Team for identifying it is a recently reported bug.

To summarize the problem: during a load testing (>1000 users attempt) on a WebCenter framework application developed with content presenter task flows, the performance (page response time) was greatly impacted by a series of parked threads. The issue was not produced in the 1000 users test. The parked threads took from >30 seconds to minutes to resume. By investigating the stack trace, the culprit is pointed to java.util.concurrent.locks.ReentrantLock.lock() which is called by UCMBridge.getAccessLevel(IdcContext, DataObject, ITrace).

This issue has been filed as a bug (Bug 17330713) and the patch/fix is to be provided soon (Update: the patch is available as of date 11/4/2013 for

The following shows a graphic indication of the parked threads (gray) through the tests. As you can see, the gray areas took the majority of the timeline.

Here is the stack track of one particular parked thread:

Look further down the stack trace, you will find the issue was from a call on ContentPresenterBackingBean. So it's obvious enough to tell it's caused by content presenter task flow. There is so far no evidence that other document task flow would cause the same issue.

Sunday, October 27, 2013

WebCenter Portal HA and Performance Tuning Checklist

Performance is a broad topic which is never out of date. I'd like to itemize a checklist with specific topics, links and references. Some topic may be more generic and some may be more specific. But this list mainly focuses on WebCenter Portal applications and its relevant products.

This is not intended to be a complete list and there will never be.

WebCenter Performance Tuning Guide

HA for WebCenter Portal and ADF application

Configure JOC for WebCenter Portal services

Configure Coherence Caching for Content Presenting

WebCenter Performance Study (Including Enable Client Caching and Compression)

Tuning JVM

Weblogic Capacity Planning

Middleware Performance Tuning Roadmap

Oracle HTTP Server Performance Tuning

MDS Performance Tuning

Using Cluster and HA Features

Some Useful A-Team Blog Posts:

High availability considerations for WebCenter Portal and ADF 
Improving ADF Page Rendering Time : Progressively Loading Taskflows
Configure Coherence for Oracle WebCenter Portal Framework Content Presenter Task Flow 

Non-programmatic Authentication Using Login Form in JSF (For WebCenter & ADF)

My previous post described a scenario that the OAM DCC programmatic authentication is not supported yet, and here I am presenting a nice alternative to do the DCC authentication non-programmatically.

You may have a read on Frank's book "Oracle Fusion Developer Guide" and there is a section in the ADF security talking about "Creating a login form in JSF" programmatically. This approach works for JEE contained security but would not work well with your WebCenter Portal or ADF app integrated with OAM authentication. I am introducing an approach that does not require any programmatic authentication and can be used safely with any type of authentications (contained security or OAM authentication).

Note: You can create HTML form in JSF but there are many limitations, such as only one form component can be allowed in a page. Due to this, it's impossible to support a complicated login page in JSF. It induced extra pitfalls and challenges on the skinning as well.

If you create a WebCenter Portal application in Jdeveloper, you will have a loginProxy.jspx page already created in your application. This loginProxy.jspx is our solution here. This pre-built page is coded in HTML form and I experienced in some cases it is not well supported for WebCenter portal applications, although it does seem ok with a pure ADF application (this page is not shipped with an ADF fusion application, so you have to create it for ADF app). I would recommend to re-code this page using ADF Faces component.

The process flow is simple:

1. Create an actual login page in JSF (.jspx) page. In this JSF page, it contains the input text for user name, password and a button for submit/login. All these components are coded with ADF faces components. In the value fields, specify a parameter in request scope so they can be passed onto the loginProxy page.

2. Re-code the loginProxy.jspx page using <f:verbatim> which will wrap the form post with the username/password parameters passed from login page. Depending on the authentication type, you may have different form post actions. This page uses the JavaScript to auto submit the form.

For JEE contained security:
 <?xml version='1.0' encoding='UTF-8'?>
 <jsp:root xmlns:jsp="" version="2.1" xmlns:f=""
  < contentType="text/html;charset=UTF-8"/>
   <af:document title="login" id="d1">
    <af:clientListener method="formSubmit" type="load"/>
    <af:resource type="javascript">
     function formSubmit(evt) {
       var form = document.getElementById("loginData");
     <form id="loginData" name="loginData" method="POST" action="j_security_check">
      <input id="userid" type="hidden" name="j_username" value="${requestScope.userid}"/>
      <input id="password" type="hidden" name="j_password" value="${requestScope.password}"/>

For OAM authentication:
 <?xml version='1.0' encoding='UTF-8'?>  
 <jsp:root xmlns:jsp="" version="2.1" xmlns:f=""  
  < contentType="text/html;charset=UTF-8"/>  
   <af:document title="login" id="d1">  
    <af:clientListener method="formSubmit" type="load"/>  
    <af:resource type="javascript">  
     function formSubmit(evt) {  
       var form = document.getElementById("loginData");  
     <form id="loginData" name="loginData" method="POST" action="/oam/server/auth_cred_submit">  
      <input id="userid" type="hidden" name="userid" value="${requestScope.userid}"/>  
      <input id="password" type="hidden" name="password" value="${requestScope.password}"/>  

3. Last step is to create a navigation rule from login page to loginProxy page. The navigation rule is specified in the "login" button on the login page.

This approach avoids the programmatic authentication and works great for having a custom login page developed in WebCenter Portal integrated with OAM authentication. It works for both ECC and DCC authentication. As of now, the programmatic authentication on OAM DCC is not supported, so this approach fits right in the gap.

Tuesday, October 15, 2013

Difference on Getting Error Code from OAM ECC and DCC

In case of OAM authentication failures, the OAM server will send the error codes back to the client. It's up to the client to decide what actual error message needs to be displayed on different types of authentication failures. For the list of the standard error codes, you can refer to here. To getting the error code on the client side, they are different based on whether it's ECC or DCC authentication. I have not found this difference documented in anywhere yet. So I am putting it in this blog post.

DCC (Detached Credential Collector) is introduced in OAM 11gR2. ECC is embedded credential collector. My previous post has described its concept and advantages, so I will not repeat it here.

For ECC, the link above also shows a code snippet to get the error code parameter "p_error_code". The error code is returned back as one of the request parameters on the browser URL. So it can be accessed by calling request.getParameter("p_error_code").

 <%@page import="mytest.error.ExampleErrorMsg"%>  
  //initializing the messageBundle first  
  String defaultResourceBundle = "mytest.error.ExampleErrorMsg";  
  java.util.Locale myLocale = request.getLocale();  
  ResourceBundle msgBundle=  
 String errCode = request.getParameter("p_error_code");  
 String secondaryErrMessage = request.getParameter("p_sec_error_msg");  
     if(errCode != null && errCode.length() > 0) {  
      try {  
        simpleMessage = msgBundle.getString(errCode);  
      } catch(Exception e) {  
        //get the default authn failed message  
        simpleMessage = msgBundle.getString("OAM-8");  
  <div class="message-row">   
    <p class="loginFailed"> <%=simpleMessage%> </p>   

For DCC, it's not returned on the request parameter but on the request header. Actually there is no request parameter returned at all for DCC, as the returned url is "http://host:port/oam/server/auth_cred_submit" with no actual parameters, in case of authentication failure. To get the error code from the request header, simply by:

 String errCode = request.getHeader("p_error_code");  

Sunday, October 13, 2013

Does OAM DCC Support Programmatic Authentication? - Maybe not yet!

Credential Collection is the process of collecting the end user's credentials through a login page. When OAM Webgate intercepts a requests and detects the user is not authenticated yet, it would redirect the user to the login page. In OAM, when the login page is hosted on the OAM server, it's called Embedded Credential Collector (ECC).

Another form - Detached Credential Collector (DCC) - is introduced in OAM 11gR2. As the name explains, DCC can be decoupled from the OAM server, which provides the flexibility of deploying the login page in either trusted internal network or DMZ. It uses a specific WebGate to collect he user credential and communicate to the OAM using secure Oracle Access Protocol (OAP). It offers a solution that isolates the OAM serve from any unauthenticated network connection, such as public access.

It is my interest to discuss on whether DCC supports programmatic authentication. Usually the login page for OAM authentication would be form based JSP page with the following snippet:

  <form id="loginData" name="loginData" method="POST" action="/oam/server/auth_cred_submit">  
      <table cellspacing="2" cellpadding="3" border="1">  
         <input id="userid" type="text" name="userid" autocomplete="off"/>  
         <input id="password" type="password" name="password" autocomplete="off"/>  
       <input type="submit" name="submit" value="Login"/>  
      <!--<input type="hidden" name="request_id" value="${param.request_id}" id="reqid1"/>-->  
      <!--<input type="hidden" name="OAM_REQ" value="${param.OAM_REQ}" id="oamreq1"/>-->  
Note the important thing in the snippet is the HTML form component with "POST" method and "/oam/server/auth_cred_submit" action. The user id input id and password input id have to match the settings on OAM server. You might notice the "request_id" and "OAM_REQ" parameter is commented out and they are not required by the DCC (but they are required by ECC authentication though).

Oracle documentation did talk about the programmatic authentication here - "Programmatic authentication using HTTP client APIs is supported for both OSSO 10g and 11g OAM Server". This is true for ECC authentication, but not for DCC. I will explain why.

In case of DCC, the user sends a request to access an OAM protected resource. The webgate will detect that and redirect to the login page with a DCCCtxCookie. The cookie looks like this:

Cookie: DCCCtxCookie_host:port=encdata%3DK1%2Fz6ZK1yVCemO56M9Zs9DfIY%2Fui4r%2BQaoWbA8rxRf%2FgJ68egTxUyOC4G%2F2Ufj8gQwEgL36wlEEevfNm5ETfaw4PwDVMVj3MRkHfvZSmBCPsFC6T4z9tS98ehpAxZjhx8cJN2ELvMycCrgqQFNEd23WbRzRq4YCLt9edz%2Ba1gekDhjIMKLYMZrNrlmv1krsIV4PYnQWydY5pmfpYfh%2BYPyumYWMt%2Bm6syK9nmruSM%2BOSKu39PxBV6TL1S3wWpWgXLFmpS6Jq5Xt6cBGWaMbCaVnfcQQdN%2BSIfFLz0kA8u8Fxq9Z4dB9MGQoWzE165KDHRKsVPgMN81M%2F84ju3Cximw%3D%3D;

This cookie is sitting on the path "/oam/server/auth_cred_submit" but not on the domain "/" like JSESSIONID. This makes the cookies not accessible from Http Client API. Without this DCCCtxCookie, submitting the login page with action "/oam/server/auth_cred_submit" would result in 404 - page not found.

Different from ECC, the cookies generated for ECC authentication are sitting on the domain path so it can be accessed from the Http Client API.

Due to this cookie path challenge, I am making a conclusion that the DCC is not supporting programmatic authentication yet. I hope others can correct me and show me an alternative or workaround for this matter.

Assuming DCCCtxCookie is present, OAM will authenticate the credentials on submitting the login form. If the credential passed the authentication, a cookie "OAMAuthnCookie" will be set and available on the response header.

Set-Cookie: OAMAuthnCookie_host:port=qLhahoJixOlOMO%2F9mCzrd80IPFoaswuOA%2F59re%2Bo%2FREiXuKMFfzicypCssemSZLLBwaGIZawYc6TnymVPUppQQKolyt015hJuas5xYIbK3rCT4SgI%2BMYdlsPpeyy1IFvpFEHWVbLJ%2Fkd94SYoiBwUWlNo7dEa7jVltmz8k8h2sJ4id%2FriGn2JCtxgUfPNGsF8FrIvO3xIkXCqo7c4LMPlZJrgxz5vW1Dt9FARC1eQ%2BzhNK4p9XYpogcuKEfGSwSEyzrQdiVPU82zx108uVKhNvlUvBPwwqhY38Dkpnecaouv6Gzo5XqEnac%2Bz8GB84UmVen6UXca8knu9lNzC2iRLi0356JSR27%2Fft4ESr%2Fpnlk%3D; 

Note to Jmeter test with the DCC cookie

The following info is provided by Flavia from the comments below: 

It's true that Jmeter cannot see the DCCCtxCookie_host:port by default, but if you set
In or, Jmeter can see the cookie. You need to restart Jmeter.

Another import thing that I found is set the "Follow Redirects" in the HTTP Request. I did for all my pages (specially "/oam/server/auth_cred_submit")