Single sign-on (SSO) is a method of access control, that enables a user to authenticate once, and gain access to the resources of multiple software systems. Well in my case, the task i have given is to authenticate a user in a PHP and a JAVA (Web) system simultaneously.

My PHP web application is the well known Joomla CMS, and my JAVA web application is based on JSF and custom built. After some thinking and research I found several resources which are worth reading (JOSSO, OneSign ), but i couldn’t take any help from them, mostly those SSO frameworks are complex ( yeah I couldn’t understand ) and aimed on a general pourpose and most of them are not for free.

So yeah I thought of doing some Hack to joomla and also make some changes in my Java web app’s authentication method. After talking with some of my geeky Friends (Sandaruwan and Anjana). I came up with two approaches. both are involved in handling the cookies manually up to certain extent.

The 1st approach is (Which i didn’t try and had to give up due to the reason that I am using JSF as the web application framework) to log-in to the Joomla site and after loged in to Joomla create a random named temp file in the server (possibly in /home/secrets with 777) with the user-name (if a valid log in) and set a cookie using set_cookie(“name”,$filename) and direct to a jsp page to do the java side authentication.

in this JSP, page read the secret file name from the cookie and read the file from the http server in-order to take the username of the loged-in user. By passing this to the authentication method of the java web app, the java side also can be authenticated.

yup it is pretty simple, but i had to give it up mainly because I use JSF. if I do the user authentication in the above way in the java side. I cannot add the user object to the FacesContext which will be used by my other java side components. so even though i log in. later on in other jsf pages my loged user cannot be found. (Shortly my java login process is not happening according to the JSF implementation procedures.) and secondly i had to give up this method because my Project manger didn’t like the idea of saving temp files in the server.

So the Second and the method which i have implemented is, automating the Joomla log-in process by making an http request to the http server from my JSF backing bean. and set the PHP cookie manually via Http Servlet response.

before i explain this method more broadly i have to mention about two nice tools which helped me to monitor the http requests and response.
Apache TCP Monitor
Live Http headers (FireFox ad-on)

Architecture

Implementation

There are two different scenarios.
1. User can visit teh home page of the joomla site 1st and the PHP Cookie is already set.
2. User visit the Java site PHP Cookie is not available.

Since anyhow we are using the java login form for the username and password in put. the Signing in for both sites will be done from the java side. (If its the PHP side same problem with the JSF session)

I created a link in the joomla home to the JSF login form. and made the joomla login form invisible to the user.

<form action="/joomla/index.php" method="post" name="login" 

					id="form-login" >
    <input type="hidden" name="option" value="com_user" />
    <input type="hidden" name="task" value="login" />
    <input type="hidden" name="return" 

		value="aHR0cDovL2xvY2FsaG9zdC9qb29tbGEvaW5kZXgucGhw" />
    <input type="hidden" 

		name="4c8b847e06d9cfc211c7c0547d8b0e82" value="1" />
</form>

I removed the input text fields for username and password but kept the four hidden fields as shown above. it is very important to keep these hidden fields hence, when login, joomla is checking for these randomly generated (generated in the server and dynamically added to the form) values. to remove the visible input text fields you have to hack in to thejoomla template.
Now there is no login form in the Joomla home (not invisible). Once you click the Login Link the user will be forward to a java (JSF) login form and asked to insert the username and password. these values are taken in to the Backing bean (Normal JSF procedure). and make the JAVA side authentication.

If the user is authenticated, what you have to do is make two UrlConnection to the HTTP server in order to authenticate Joomla. the 1st UrlConnection is to read the main page (or the page where joomla has its dynamically generated Login form)

you have to read four hidden fields in the form and take them to variables and create a request string, and make the 2nd request to the same page (Due to Joomla’s design pattern). you should not forget to send the cookie that you received with the 1st request. Once you did this you are authenticated in thephp side too. The next step is adding the cookie to the HttpServletResponce. (Make sure u set the path of the cookie.. I had to debug for hours forgetting that part )

The above mentioned is the 1st scenario if there are no cookies in the client side (if the user haven’t requested the home page ofjoomla). the 2nd scenario is if the user has a cookie, then when ur making the request u have to get the cookies from the HttpServletRequest and append it to the request header. Simply what you have to do is get all the cookies and append them. the rest of it is same.

So that’s it.. you’re authenticated in both web apps. With the post i will attach the Java Source code i used to do this task.

Joomla Auth Source Code

Okey so am writing after some time about some valuable thing !! This is about some thing I happened to do as an assignment for one of my degree modules (Network Application Development). The Assignment is to implement a server and a client using both TCP and UDP. The functionalities expected were, a centralized server which keeps records of the online connected buddies in the network (Subscription)

A Client to communicate and retrieve the buddy list from the central central server and directly connect to the buddy (peer 2 peer)

message broadcasting among groups.

So here I go with some details about the application level protocol and I will atach the C codes if any one needs to download and modify please feel free.

Application Level Protocol

The application level protocol is mainly implements two applications, the central server and the p2p
client.

Basic functionality of the central server

• User(client) subscription
• Keep records of the users
• Update records on new subscription and un-subscription
• Broadcast the record table to all the online clients.

Basic p2p client functionality

• Retrieve the user table from the central server.
• Broadcast messages to all peers
• Talk with each peer separately

Server protocol

Centralized server is using a TCP connection to connect to all its peers. The Server binds to a socket
and keeps listening to all incoming TCP connections.
When a new client is connected to the server’s port number server accepts the client connection and
open up a new thread for that client.
The server maintains a table of clients containing client information.
In side the newly created thread the server updates the count of clients and inserts new client data in
to its table.
The connection between the server and the client will not be closed.
The server in its main process will keep on listening to new incoming TCP connections.
The server is declaring a thread pool (an array of threads) where it will create a separate new thread
for each connected client and will do all the communication with that client in that separate thread.
The server keeps the number of clients and the client table as global data. And they are shared with
each thread.
As soon as the numbers of clients are changed (a user is newly subscribed or unsubscribed)
the
server will send the updated table of clients to all clients using the connected threads.

p2p Client protocol

Client connects to the server using a TCP connection.
Client is maintaining UDP server and a UDP client for the peer-to-peer
communication.
At first when the client is run with the server port as a command line argument it prompts for the
UDP port where it’s UDP server will be listening for incoming messages from the fellow peers. The
UDP server Port will be send to the central server for subscription.
A child process will be invoked inside the main process for UDP activities (UDP server and client)
The UDP client will prompt for the host address and the port of the fellow peer to start a
conversation. This can be provided by referencing to the clients table, sent by the server.
Then the UDP client will establish a connection with the fellow peer using the given host addresses
and the port.
If a message has to be broadcast the UDP client will connect to all hosts and send the message.


Download the C code, make and run