How do I pass a PHP session authenticated in IIS across to Jetty or Tomcat?

September 4, 2008 1:37 PM

I have users logging into XOOPS running on IIS, and have an instance of the Jetty JSP webserver configured to serve up Eclipse's Infocenter system. How can I set up security so that no users can view the Jetty-served content without being authenticated first in a XOOPS session off of IIS?

I'm trying to tie certain web-based applications together here and I'm wondering if there's an easy way to achieve something.

At my company, we run IIS, PHP and MySQL which all serves up a XOOPS-driven website. One of our teams has provided the Eclipse Help system ("Infocenter") containing a stack of product documentation, all packaged up with the Jetty webserver. The way we received it from another team in our company, you run a batch file which installs Jetty as a Windows service, and when you run that service Jetty fires up and starts listening on a port that you can pre-choose in a properties file prior to creating the service. Going to your URL/port in a browser will connect to Jetty, which in turn serves up the Eclipse Infocenter content.

That's all well and good if you're happy to just send your browser to the Jetty/Infocenter URL but there's another dimension to this. I need to be able to secure access to the Jetty port so that only users who have pre-authenticated to XOOPS, hosted in IIS, will be allowed into the Infocenter/Jetty instance. And therein lies the rub: once authenticated to XOOPS the user has a golden key in the form of an authenticated session, but as soon as the browser is passed to Jetty, how can we set it up so that the user is forbidden from accessing any Jetty-served pages without the XOOPS golden key?

It's a convoluted situation here but let's just say that another non-IT team came up with this Infocenter idea - someone who "did this at his previous job" has suggested the idea, plenty of non-IT but senior-management people bought into it, he wrapped up everything in Jetty and gave it to us, and now he's on his way out of the company (probably so he can eventually leave a poo in the middle of some other company's carpet the size of the Pyramid of Giza for someone else to clean up) and doesn't have the time to work with us to fulfil the mess of other requirements we now have in taking this technology to the next level.

We have Tomcat serving other JSP content as well, which is doubly annoying in the scheme of things since, of course, it should be able to replace Jetty as the JSP serving system. Right now we're taking on a problem another team has created, and investigating how to make a WAR-file version of the Infocenter to be hosted under Tomcat, but our deadline for getting all of this resolved and implemented is the end of this month (9/2008). So, either in Jetty or in Tomcat, is there a way of securing these technologies so that only a user that has a valid PHP session generated within XOOPS and IIS is able to be passed thru to either a Tomcat or Jetty server containing the Eclipse Infocenter system? Our other Tomcat-hosted solution is our own code, provided to us by someone who's no longer with our company, so we can get our fingers dirty with that to an extent (and that's not something I'm asking to be solved here), but we think the solution to this Infocenter dilemma lies in some sort of custom thing we need to write which allows Jetty or Tomcat to act as a doorman, checking some sort of passed credential and disallowing browser access to content if that credential is not somehow "present" as the browser comes across. Like the concept of a referrer, but not as easily spoofable/hackable. Make sense? (frustratedly sips coffee)

None of those in my team are majorly experienced web programmers so we're running madly around the Internet trying to find solutions. Figured the hive mind could help. (crosses fingers and sips more coffee)

Oh, and to answer what might be everyone's next question - we aren't using Apache to serve XOOPS because IIS was on the machine we originally put it on and we felt there was no reason to since XOOPS runs perfectly fine under IIS.

posted by tra to computers & internet (3 comments total)

That's a giant question full of specifics I don't know.

I can however shed some light on session sharing across applications.

All a session is, is a cookie set on the client (or via url, or some other client persistent manner) that indexes into the server side session store. That session store is any server side persistence (memory, database, disk).

So a client comes back the second time, says "here's my ID", and the server looks up the session and knows what vars and what details were set. In your case (authentication) the contents of the session will probably be pretty small (maybe as small as a boolean - logged in?).

So, the problem is hooking the servers up to the same backend, and also hooking them up to always serve the same client IDs as well. This is a huge problem though, since very few frameworks are designed to share their sessions with outside applications.

So... alternate solutions:

1) have the java side make a web request over to the php side, and ask if userx is logged in, and from what IP
2) force a re-login... it's really not that big a deal
3) Use a 3rd piece of software as a single sign on service (this is what many companies do).

Good luck, sorry I can't give you any hard answers, but you're facing something that is easier to work around, rather than solve directly.
posted by cschneid at 2:47 PM on September 4, 2008

Wow, tricky problem. I don't know XOOPS, but it only makes sense that its sessions would use PHP's session mechanism, which is (by default) a cookie in the user's browser that corresponds to a file on the server's disk. You need that cookie to validate the session, so your first task is to make sure your Jetty/Tomcat content is exposed on the same host and port that your XOOPS content is. That may mean a "reverse" proxy that sends to the two hosts based on URL.

Now you're getting the PHPSESSID cookie in your Jetty/Tomcat app and you need to validate it. If you're using PHP's default cookie storage, that means looking on the PHP server's disk to see whether there's a session file that corresponds to your cookie, and making sure that file is still valid. You may have to do some research on PHP cookie storage, but it can definitely be done, even if you ended up having to dig into PHP's source. Alternatively, you can replace PHP's session handling with something that stores sessions into a database or some other easily accessible place. Now you can check whether the cookie is good, pick up whatever session data you need, and away you go.

Personally, I would implement this with Apache and mod_rewrite, but that's mostly because it's my biggest hammer for HTTP chicanery like this. You can use whichever tool you like best.

If you can't modify your JSP code to validate the session ID, you've got a bigger headache. All is not lost, though - you can use mod_rewrite to grab the PHPSESSID cookie from the request, hand it off to an external program to verify whether it's any good, and then perform proxying only if the session is valid. Probably 8-10 lines of Apache config and a small external app to validate the PHP session.
posted by pocams at 2:51 PM on September 4, 2008

Forgot that I never closed this one out. We wound up not being able to come to a solution on this. The new story at work is that they aren't going to worry about authentication and let the public fully into this document repository system. I appreciate the responses, though - thank you but it was simply beyond us.
posted by tra at 5:07 PM on January 30