Wednesday, April 13, 2016

Mistaking Kerberos as Single Sign On

End users often misinterpret the Kerberos authentication mechanism to mean Single Sign-On (SSO) in corporate world.  Kerberos authentication provides seamless sign on to (web) applications by using the Kerberos ticket generated/ refreshed during the user’s authentication to the network (when user first login to the computer).

For example, if web applications AppX and AppY are configured for Kerberos authentication, the user will not see any credential challenge when both of these apps are accessed in two different tabs of same browser. This gives the impression of SSO between AppX and AppY.

The SSO functionality is much broader in any in premises Enterprise SSO infrastructure like OAM, SiteMinder, ForgeRock. The Kerberos mechanism is just one of several Authentication schemes available in SSO server.  The Other authentication scheme like Form Authenticaiton can also provide single sign on between two different web apps thru a secure cookie generated by sso server when user first login thru the Form in a Web-Agent based SSO architecture.  

Wednesday, July 30, 2014

OAM R2 Persistent Login (Keep Me logged In/ Remember Me) Set up

I remember struggling with this one in OAM R1.  Since this feature was not available in R1, we implemented this by our own custom code.  Finally this is available in R2.  Here is the link (http://docs.oracle.com/cd/E40329_01/admin.1112/e27239/getstarted.htm#CIHBEEAI) to set this up and test in 30 minutes max.

I am just posting the 1st step of exact WLST command taht I ran to enable it in OAM 11g R2.  Follow the rest of the steps from Oracle doc


$ cd ../Middleware/Oracle_IDM1/common/bin
$ ./wlst.sh

wls:/YOUR_DOMAIN/serverConfig> connect()
Please enter your username :weblogic
Please enter your password :
Please enter your server URL [t3://localhost:7001] :t3://YourServer:7001
Connecting to t3://YourServer:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to YOUR_DOMAINr'.

wls:/YOUR_DOMAIN/serverConfig> configurePersistentLogin(enable="true", validityInDays="30",maxAuthnLevel="2", userAttribute="obPSFTID")
SUCCESS

wls:/YOUR_DOMAIN/serverConfig> exit()

Monday, March 10, 2014

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.

Wednesday, January 15, 2014

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 := 高山


Tuesday, July 2, 2013

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.


Thursday, March 21, 2013

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.

Thursday, February 7, 2013

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