Re: [struts] JAAS and Struts Re-authentication Question

2007-11-19 Thread Adam Gordon
So I think I have it working and I didn't have to redirect the user, which is good because that wasn't working anyway. I don't know if it was JAAS or Struts, or what, but the login parameters were being stripped from the request so they never got to the login page. How I got it to work was

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-16 Thread Dale Newfield
Adam Gordon wrote: 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. Except a redirect must be to a GET, not a POST, and it would be unfortunate to include the login credentials

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-16 Thread Adam Gordon
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

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-16 Thread Adam Gordon
Yea, but in this case, it may be something we need to live with. The login page scriptlet code looks for the login credentials in the request and sets the appropriate form fields as well as a flag we use to indicate whether the form should be submitted immediately upon loading and in either

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-15 Thread Dale Newfield
Laurie Harper wrote: If you have a separate 'login' page (as opposed to having a login form on each page) you might be able to get away with invalidating the session when that page is shown, with the caveat that logged in users would implicitly be logged out if they visit that page. And in

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-15 Thread Adam Gordon
I believe you are absolutely correct Laurie, because I've not yet seen a way to get a handle to the LoginContext to call logout(). All we can do is invalidate the session - which we do when the user logs out. This removes the user principal from the request and indicates to JAAS that the

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-15 Thread Adam Gordon
See my comments in my response to Laurie. We're basically using dual login pages, one on our main website (Apache) and the other in our webapp. I'm currently toying with the idea of a Filter to detect the subsequent logins against an already authenticated session. --adam Dale Newfield

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-15 Thread Dale Newfield
Adam Gordon wrote: For background, we actually have two login pages: on is the login page that is running inside our webapp that is running JAAS and POSTs to j_security_check at form submission time. The other page is our company's main website (Apache) and users can log in here too. What

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-14 Thread Adam Gordon
If you mean protecting the page w/ a security constraint, I think that would be a problem in that JAAS would detect that it's a protected resource and prompt the user to log in before hitting the login page and upon a successful login would redirect the user to the login page after they've

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-14 Thread Laurie Harper
I don't think Container Managed Security has provisions for logging users out, other than by expiring the session (and not even then if you're relying on HTTP authentication rather than form-based). If you have a separate 'login' page (as opposed to having a login form on each page) you might

Re: [struts] JAAS and Struts Re-authentication Question

2007-11-13 Thread Dale Newfield
Adam Gordon wrote: We're using JAAS for webapp authentication and we've discovered an issue: If user A is logged in and tries to log in as user B, they stay logged in as user A. Couldn't you protect the login form page and action so that they're only accessible by a session without any