Always Mark Your OAM Cookie as Secure and HttpOnly

It is a good practice to mark all OAM cookie as Secure and Http-only. This can be done in individual authentication scheme. The exact OAM-11g-R1 syntax is "ssoCookie=Secure;httponly" in Challenge-Parameters field.

httponly :- By marking the cookie as httpOnly, you are ensuring that the cookie can only be used for http protocol. It is not accessible via non-HTTP methods like JavaScript ("document.cookie"). Usually hackers can steal cookies via cross-site scripting.

Secure :- This configuration limit the cookie transmission thru the encrypted(https) channel only. This is an additional security on the top of httponly configuration.

Resolving OIF Error "FED-15132: Unknown refID" when JSP based form login is used for OAM authentication

The Issues :- 

My OIF server is integrated with OAM for authentication. I used a JSP based form login to collect credential when User makes an IntitateSSO call. I started seeing this error in OIF logs. This is very much reproducible in clustered OAM and OIF servers.

FED-15132: Unknown refID
Cause: User previously accessed the Oracle Identity Federation server with a different host name than the one in the current request and cookies were not transmitted.
Action: Use the same hostname and fully qualified domain URL to access the Oracle Identity Federation 

FED-15128: An internal error occurred while processing the credentials Cause: The authentication engine did not return the required refID parameter.
Action: Check that the authentication flow correctly sent the refID parameter to the Oracle Identity Federation server 

Whats Going on under the hood :- 
The OIF servers is a J2EE application runs on weblogic server which creates a JSessionId. My custom jsp based form login is also another J2EE application deployed on OAM server. When this login page is invoked, it also create a JSession Id. To add a pinch of salt to this issue, I am using same load balancer address (e.g. sso.abc.com) to access multiple Weblogic applications. They all try to use the same JSessionId cookie, which is issued to domain=sso.abc.com path=/.  Now my custom form login session is clashing with OIF's session that is created inside OIF after successful authentication.

Solution :-
You may have already guessed it. Open the weblogic.xml file of you custom Login Form war file and add the followings .

<session-descriptor>
<cookie-name> MyJSessionId </cookie-name>

</session-descriptor>


Basically, you are instructing Weblogic server to create a custom JSessionId (MyJessionId) for your Form login to avoid clashing with OIF's session.

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 %>" ;                            

    }

}