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.
--adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
