0

Scenario: I'm logged in some (java - swing) application. The authentication is typical: login and password checked by server (J2EE) on client application start, after that normal work in app including many requests/responses:

Client <------------------> Server1


Now, I want to do something like this: user clicks on some button in application and after that, the app opens default internet browser with some url pointing to other www server (Server2) but with "user context/session" for futher processing (sending request to Server1), like this:

Client -----> Browser -----> Server2 -----> Server1

The page should "catch" present client user session ID (kind of single sign-on). As far as I know, it's not able to start browser with created cookie "just before start", so idea is:

  1. Opening browser with /Server2ServiceUrl/JSESSIONID.
  2. Browser goes to Server2ServiceUrl.
  3. The user is doing some operations on page (filling form) and clicking for example "save button" on this page.
  4. The result is requested to Server2.
  5. Server2 creates session cookie (JSESSIONID) based on JSESSIONID in its initial url and sends request to Server1 with session cookie (in "Cookie" HTTP Header) so Server1 knows what user sends request.

Of course it is far away to be secure. One of the big issues is session ID visible all the time in browser address bar. One of ideas to increase security a little bit is:

  1. Browser goes to Server2Url, but not to the service, only to some url which:
    • will create browser session cookie based on JSESSIONID in initial url
    • will send redirect command to browser.
  2. Browser create session cookie and redirects to service (Server2ServiceUrl). Because of that the session ID will be visible in browser address bar only till redirect.

But still I feel that this concept should be more secure. What should I do then? Maybe is some standard technique to solve this problem?

1 Answer 1

1

As soon as the user clicks the button, create a long random single-use token and send it to the server (something like yourdomain.com/setsession?session=SESSIONID&single-use-token=TOKENID. This token will be used later to retrieve the session id.

After that, the application start a very simple HTTP server, and serve its own HTML page to the default browser. This page will redirect to yourdomain.com/getsession?token=single-use-id, which in turn will open the desired page and set the session cookie.

The getsession component will do a lookup for the token, and if it comes from the same IP as the setsession, it will delete the token, and send the session cookies to the browser.

With self-destruct tokens, you don't have to worry about replay attacks and token reuse, even if someone sees the token.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .