Including Custom MANIFEST.MF File in NetBeans jar Building Process

OAM custom authentication module requires a custom manifest.mf file to be included in your custom plugin jar file. It is is easy to include your own manifest.mf file during jar building process in eclipse. But it not that easy if you are using Netbeans .  If you do a clean build using Netbeans, you will end in having a default manifest.mf file in the jar file.

Here are the steps to include your OAM plugin specific manifest.mf file in the jar.
(1)  Keep your custom manifest.mf file in /src/META-INF/ directory.
(2) Open /YourProject/nbproject/project.properties
comment this line
#manifest.file=manifest.mf

add this two lines that will do the magic
manifest.available=true 
manifest.file=${src.dir}/META-INF/manifest.mf 

(3) Now do a NetBean build, the generated jar file should have "/src/META-INF/manifest.mf" included already.

Japanese (non-ASCII) Character Issues in OAM headers variable

I have few user records with Japanese character (like 高山) in their attributes. Querying these users in OVD through ODSM displays it correctly . However, the same attributes when passed as OAM header variable through OAM-Authorization-Scheme spit out garbage like '=?UTF-8?B?6auY5bGx?=' .

This happens because the Webgate will encode any non-ASCII characters in header variables according to RFC 2047. It is the receiving OAM-protected application that will decode the encoded characters. The following java sample code will be a quick rescue. This will transform the non-ASCII character to a readable one.
:
import javax.mail.internet.MimeUtility ;
System.out.println("The Actual Value is := " + MimeUtility.decodeText("=?UTF-8?B?6auY5bGx?=")) ;
:

Your result will be =
The Actual Value is := 高山

FIXING BLUE SCREEN ERROR WHEN COMING FROM BOOK-MARKED LOGIN PAGE

This issue is very familiar to all OAM experts. End User very often bookmark the OAM-form login page thinking that it is an inseparable piece of their protected application.  So, when User comes from this bookmarked login page , he ends in the OAM default blue screen as OAM does not where to redirect the user after successful authentication.

DETAIL ISSUE DESCRIPTION:-

To understand this issue , lets understand the OAM (Oracle Access Manager) flows that protects web resources in lay man terms.

1     (1) User access the protected resource (say https://MyApp.abc.com) thru browser.

2     (2) The request hits webserver where Webgate examines every URL pass thru it. It checks, if the requested URL is configured as a protected resource in OAM server. If yes, Webgate  takes the instruction from OAM server and show the configured  login page (https://sso.abc.com/oam-form/login.jsp). User then submits his/ her user-id and password thru the login page.

3    (3) OAM server validates the credential .  If authentication is successful,  OAM server then instructs the Webgate to redirect the user to “Originally Requested URL” (https://MyApp.abc.com).

Note that the login page mentioned in step 2 is a generic login page serve many other applications too. User often thinks that the login page is application (MyApp.abc.com) specific and book marks it. Ideally, user should bookmarks the application (MyApp.abc.com) home page only after successful authentication.

When User comes from the book marked login page , it starts the process from step 2 mentioned above. Webgate does not have the “Original Requested URL”, so it does not know where to redirect the user after successful authentication.  Thus,  Webgate fails to redirect to the protected resource after successful authentication and ends in dirty default blue screen.

SOLUTION :-

We cannot educate user about the OAM internal working mechanism. So lets accept the fact that some user will book mark the login page instead of the application home page.  I would like to thanks my colleague Adam Callen (http://idmrockstar.com/blog/) for the original idea.

If a user comes from a book-marked page, do the followings.

      (1)  Identify, if the user is coming from a book marked page.

2    (2) If No, (by checking if “#URL=*” exists)

a.       OAM server sends the “Oiginal Requested URL” as a parameter.

b.      Extract “Originally Requested URL” from request object and add this URL to the end of login page URL.  

Example :

https://sso.abc.com/oam-form/login.jsp#URL=https://MyApp.abc.com/

The blue colored one is the default login page URL and we add the red colored URL when user comes for the first time

Now user may bookmark this page. Note that we injected the  additional URL “Original Requested URL” at the end of the login page URL. If user come from the book marked page we can extract this information later.  Note that the additional information added to the URL only after the page loading is complete.

3    (3) If yes,  (by checking if “#URL=*” exists)

a.       Extract “Originally Requested URL” (https://MyApp.abc.com/) from login page URL (https://sso.abc.com/oam-form/login.jsp#URL=https://MyApp.abc.com/)

b.      Now redirect the user to “Originally Requested URL” (https://MyApp.abc.com/) before the login page loads itself.

c.       Since the “Originally Requested URL” (https://MyApp.abc.com) is a protected resource, now the authentication process will go thru normal process as mentioned in step 2 above.

Here is the javascript that does all the above said trick.

function checkIfBookmarked() {    

    var hashString = location.hash ;     // https://sso.abc.com/oam-form/login.jsp#URL=https://MyApp.abc.com/   

    var extractedHash = "NotBookMarked"

    if (hashString.length > 0) {

        var extractedHash = location.hash.substring(0,5) ;               

    }                 

    // If the URL has a '#URL' value, that indicate user is coming from a book marked page.

    // #URL= contain the URL value of originally requested URL.

    // so extract the value and redirect the user to that originally requested URL.

    if (extractedHash == "#URL=") {       

        var remainingURL = location.hash.substring(5, location.hash.length) ;

        //alert("You fool.. You have bookmarked a common login page. Redirecting to " + remainingURL) ;      

        window.location.href = remainingURL ;               

    }

    else { 

       // user is not coming from a book marked page. We are good, but user may book mark it.

       // so embed the Originally Requested URL to as hash.       

        location.hash = 'URL=' + "<%=origRequestedUrl %>" ;                            

    }

}

Quick Tips: Finding the IAM component versions

It was little harder than I thought :(  My weblogic expert friend shared it.

For OIF and OAM :-

Assuming that you have installed OIF from Oracle_IDM2

$ export ORACLE_HOME=/opt/apps/Oracle/Middleware/Oracle_IDM2

$ export PATH=$PATH:/opt/apps/Oracle/Middleware/Oracle_IDM2/OPatch

$ opatch lsinventory -detail -invPtrLoc /opt/apps/Oracle/Middleware/Oracle_IDM2/oraInst.loc

For OHS  :-

opatch lsinventory -detail -invPtrLoc /opt/apps/OHS/Oracle_WT1/oraInst.loc

For WEBGATE :-

opatch lsinventory -detail -invPtrLoc /opt/apps/OHS/Oracle_OAMWebGate1/oraInst.loc -jdk /opt/apps/OHS/oracle_common/jdk/

Reconfiguring your COREid server to a new LDAP

A quick tip here on redirecting your CoreId server to a new Directory server.


-> Shut down the COREid Server
-> Open setup.xml file in .../install Directory/identity/oblix/config directory.
-> change
{..NameValPair ParamName="status" Value="done"...}
to
{..NameValPair ParamName="status" Value="incomplete"...}

-> Restart the COREid server.
-> Now access url http://.../identity/oblix and set it up again with new LDAP parameter