tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Questions on "Single Sign On"?
Date Tue, 20 Oct 2009 15:22:40 GMT
Josh Gooding wrote:
> Andre,
> I am using a realm for this.  I decided that the best route to go on this is
> if a user is actively logged in and tries to log in again (while already
> authenticated) to invalidate the 'other' session and continue on, that way
> of the browser dies, they can still get in.  I have however not clue one on
> how to do this.  What is put in the session upon authentication that I could
> have my code look for to invalidate the "other" live session?

I think that I fail to see what you are trying to achieve.

Assuming you are using "container managed security" as described here :

then what normally happens is this :
- a user, with his browser, accesses a URL on your server
- Tomcat maps this requested URL to a webapp
- in doing so, Tomcat sees that this webapp is submitted to 
- Tomcat then wonders whether this user is already authenticated. For 
that, it checks if this request is associated with a session (which can 
be indicated by a JSESSIONID cookie, or a request attribute coming with 
the request).
   - If yes, then Tomcat will retrieve the user-id associated with this 
session, and then check if this user-id has the appropriate "role" for 
accessing this webapp.  If not, the request is rejected, else it proceeds.
   - (**) If no, then Tomcat will trigger a user authentication. 
Depending on how this is set up, it will either send back a html login 
page to the browser, or a 401 status code to trigger the browser's 
builtin login dialog.
- The browser will then send back the user's credentials.  Tomcat will 
check them (using the configured method for that), and if they are ok, 
will set the user-id, and record it in the session data. Then we go back 
to (*) above.  If the credentials are not OK, then it probably loops at 
the (**) stage.

Now, how would a user in this case try to login a second time, when they 
are already authenticated ?
And, does it matter ? (are you trying to limit the number of times the 
same physical user is allowed to run the /application/ simultaneously ?)

Ok, let's say that the user leaves his first session open on workstation 
A, and starts another browser session on station B (or, his browser 
crashes and he restarts the browser, thus losing the previous session-id 
information).  He thus accesses the original URL again, and Tomcat 
attributes a new session to this other browser.

(Or else, you are doing something like "pre-emptive authentication" : 
you start each session by a login page, explicitly.  But then, you are 
no longer really in the logic of Tomcat's "container managed security".)

Tomcat itself will not provide a way to avoid that (the two or more 
individual "sessions" at the Tomcat level), because for Tomcat, these 
are really two independent sessions, and the second one has no relation 
to the first, and that second session does not indeed contain any 
Tomcat-level link to the first session.

If you want to provide such a link, then the only way I see would be at 
the application level, for example with a servlet filter wrapping your 
webapps, which would store somewhere the fact that this /user-id/ is 
already in use (and its associated Tomcat session-id).  Then it would be 
the responsibility of this servlet filter also, to "destroy" the 
previous Tomcat session linked to that same user-id, when this same 
user-id shows up with a different session-id.
But I cannot tell you if this is possible using the standard Tomcat API. 
  You would have to be able to pass another Tomcat jsessionid (than your 
own) to the session.invalidate() method, and I'm not sure that this is 
(I think that it would open the door to all kinds of misbehaviours if it 

To summarise, from what I think I understand which you want, it does not 
marry very well with Tomcat's "container managed security", and you 
should think more about a servlet filter based security mechanism, where 
you can do pretty much as you please.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message