Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an web application A where a user has to authenticate through a username/pass method (https://server.local/webappA). A secure connection is established (HTTPS) with the server A.

Then, these guys want some sort of 'trickery' to use this same authenticated user to open a different URL (https://server.local:8080/webappB/?param1=PID) and still be sure the authentication is not broken. In other words, they don't want the user to enter his credentials again for webappB. Also, this new webappB should not be accessible to non authenticated users.

WebappB is running in Tomcat and could be hosted on the same server on a different port #. Our job could be a lot easier if webappA had a well known authentication system such as LDAP but they don't. WebappA is from Company A and WebappB is from company B.

Is there any possibility this can work? I personally don't see how, so I might try with you guys. I am free to install any apache mod or server I need.

share|improve this question
up vote 4 down vote accepted

This isn't too tricky, assuming both apps can access similar session data. But only if you can mess around with the code a bit. Since you're talking about different companies providing the software that second part might not be possible.

Basically when a session is started with AppA the username/password is checked against some source (be it a database, IMAP server, LDAP server, whatever), this isn't actually the important part of the process for. After that first username/password collection, a session token is issued. AppA checks the session token upon access and if valid; loads the session (so it doesn't require username/password every time you do something).

For this to work you need AppB to (a) be able to access that session token (easy enough, it's likely stored as a cookie), (b) access the session data that lists valid tokens and the user's related (if user isn't included with the token in the cookie) and (c) create a session in AppB without a username/password start, or validate against the existing session.

Session token access:

This should just be a matter of reading the cookies supplied to AppB. As long as AppA issues the cookie without a restrictive path value (low risk since Company A can't know all the folders that AppA could operate under).

Session data access:

Typically an application would store session information in some sort of a database table. The only trick might be learning the username associated with a session (the token might include username, or some sort of ID, or neither). Session validity as defined by AppA should be obeyed by AppB

Create AppB Session:

Probably the trickiest part, if AppB has dependency injection on the authentication module, (including session start, session detect and session terminate) then it's just a matter of getting the application to read the same session token as AppA, compare/validate against the session data and translate and extend if required. Note unless both apps are modified you'll also want AppB to defer logins and possibly logouts to AppA


If AppA uses a cookie to store/retrieve session information without a path value notice that any other part of the same website can also see this cookie. If some of the site is served under http - including images, style sheets and javascript - this session cookie will be exposed and obtainable by sniffing software (such as firesheep) or hardware. Serving static content from a different server (or same server under a different name) helps to mitigate this.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.