Google Summer of Code: July 2nd, 2008

Today I began to work on my project at 09.30 AM (a little bit earlier than yesterday ) considering the fact that I don't know anything about bridging the authentication between J2ME client and Acegi security framework used in OpenNMS. After about one hour googling about this matter I can't find any useful information. Hmm, should I ask my mentor how to do it? Oh come on, I still got faith that I can do this. Ok, in the end I found a very small hint here. The guy in the Acegi mailing list said that :

"If your J2ME system is able to maintain the standard jsessionid or cookie-based session identifier, you shouldn't have any problems."

At that time I got confused whether I should trust this guidance or not. Ok, the point is I should maintain the JSESSIONID right? So, how to authenticate??? Thinking...Thinking..Oh no! I don't know how to do it!! :(( Googling was useless, no existing implementation about this. However, finally I got an idea. The main point is how to emulate the authentication between browser and Acegi into J2ME. Clear. In order to understand the mechanism behind this, I can sniff the packet. I assumed that the mechanism only include HTTP request and response.

Next, I used wireshark to monitor the HTTP packets during the authentication. Apparently, the mechanism went like this: (I exclude all the details of the data inside the packet)
1. Browser :
GET /opennms-webapp/notification HTTP/1.1
2. The server reply:
HTTP /1.1 302 Moved Temporarily
3. Browser:
GET /opennms-webapp/acelogin.jsp HTTP/1.1
4. Server:
HTTP/1.1 200 OK (text/html)
5. Browser:
POST /opennms-webapp/j_acegi_security_check HTTP/1.1
6. Server
Continuation or Non HTTP Traffic
7. Server
HTTP /1.1 302 Moved Temporarily
8. Browser
GET /opennms-webapp/notification HTTP/1.1
9. Server
HTTP/1.1 200 OK

Getting bored already? Ok, this is for refreshment : (posted without permission from the original owner)

Ok, back to business,
As you can see above, there are 9 steps during the authentication. Seems easy right? But apparently, it's not that easy :( Simulate that behavior in the J2ME Midlet is not that straightforward. Basically, if we tell the server (via browser) HTTP GET, we will end up with HTTP 200 OK (if success). But actually before reaching HTTP 200 OK, there can be HTTP 302 message which means redirecting. But since all the browsers now are smart enough to redirect automatically to the next destination there is no big problem. On the other hand, for J2ME this is a "problem" :D So, what I have to do is keep checking whether the 302 still remain, and parse the HTTP header to get the "Location". According to HTTP/1.1 specification, after we get 302 we should follow with HTTP GET to the next URI Location. Above you can see that in step 2 and 7 there are redirections.Clear. For the authentication, we should make a HTTP POST (step 3) and embedding the username, password.

So tired...Observing the wireshark output really made me dizzy. Yeah, because I didn't know any easier way to do this. But anyway..problem solved!