struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Gordon <>
Subject Re: [struts] JAAS and Struts Re-authentication Question
Date Fri, 16 Nov 2007 18:48:06 GMT
> Let me get this straight:  All pages in your webapp are protected (not 
> available to non-logged in users), so when someone who is logged in on 
> the company's main site tries to get to a page in your webapp, JAAS 
> catches it and sends them to your webapp's login page, which might be 
> able to glean enough details to log them in automagically and then 
> redirect them to the originally requested page in your webapp.  So 
> you're relying on JAAS's restriction "non-logged in users can't get to 
> these pages" to insert your webapp's login logic, but if the user *is* 
> already logged in, there's noplace to catch this, so your webapp's 
> login logic gets sidestepped.

Correct.  We do have some pages which are accessible by non-logged in 
users, but I don't believe that's relevant here.  We have two security 
constraints:  the first locks everything down and says the webapp is 
only accessible by users w/ the the role X (we only have one role and 
either you're in that role or your not) and the second opens up specific 
URIs to everyone (help docs, etc...).
> If a user is logged in as A and continues (using the site-wide login 
> form) to log in as B, once in your webapp does request.getRemoteUser() 
> return A or B?  If it returns A then you have enough information to 
> detect this case.
We have a request listener set up in web.xml that is hit for every 
request.  We use it to setup the user's navigation menus and stash some 
static account information on their session for easier accessibility.  
When user A logs in, for debugging, I'm printing out the full URL and it 
has user A's login parameters and the value of getRemoteUser() returns 
user A's username.  With A's session still authenticated, I navigate 
back to our main website and log in as user B and the full URL contains 
user B's login parameters, but getRemoteUser() returns user A's 
username.  Detecting the case wasn't the issue.  We could also do this 
by looking for the account information on the session - if it's present 
the session is authenticated, if not, it's not.

> Since you know how to detect the login parameters from the request, 
> you could put in an interceptor that checks if the login parameter is 
> present, and if it differs from request.getRemoteUser() then you have 
> just detected the problematic case.  Invalidate the session and then 
> JAAS will catch that the user is no longer logged in, which will 
> trigger the display of your webapp's login page, which will result in 
> correct behavior.
This is the crux of the problem.  In this request listener, I've placed 
code that looks for the case above, i.e., user B's login parameters but 
user A's authenticated session and in the case where B logs in over the 
top of A, I've invalidated the session.  I believe what's happening is 
that JAAS correctly detects that the session is no longer authenticated 
and redirects the user to the login page.  However, this creates 2 
problems:  1) I already have the user's credentials and don't need the 
login form (which actually makes me think there's another issue as the 
login parameters aren't getting passed to that login form) and 2) when I 
try to log in via the form w/ B's credentials, I still get A's account.  
Looking at the logs, I can see the login() method from the LoginModule 
being called for B.   I believe the wrong account problem is occurring 
because the logout() method is never being called on the LoginModule for 
user A.  And as we've already discussed in this thread, there's not 
really any way to call the logout() method.  I think the solution is 
going to be to redirect the user to the default main page manually w/ 
the login parameters and JAAS should take over from there...hopefully.  
Only, you can't redirect a request from a RequestListener so I'm going 
to see if I can set up a Filter since it has the required Response 
object to do the redirect.

Thanks for all the info.  If you have any other epiphanies please let me 
know and I'll let you know how this turns out.


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

View raw message