On Tue, 16 Jul 2002, James Krygowski wrote:
> Date: Tue, 16 Jul 2002 07:09:55 -0400
> From: James Krygowski <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: RE: forwarding through j_security_check
>
> Hi Craig-
>
> >> If so, is it possible to set up a servlet that
> >> could manipulate the Referrer in the header, and redirect a request along
> to
> >> an application in another Tomcat server, making it look like a post to
> >> j_security_check, complete with referrer, j_username and j_password?
> >>
> >> Any suggestions or comments are welcome and appreciated.
> >>
> > Trying to forward security credentials like this is pretty much guaranteed
> > not to work.
> >
> > One thing you might consider using is Tomcat's standard support for single
> > sign on across multiple webaps. Check out the "Single Sign On" section
>
> Thanks for the response. Your suggestion is only applicable for those who
> have a homogenous Tomcat environment. In my situation, my portal will have
> to forward to a mixed environment of Tomcat and JRun servers. In the future
> that may expand to include either WebLogic or WebSphere. I find it hard to
> believe that there is no way to programmatically manage a login sequence
> using j_security_check. Is it possible to use a servlet intermediary to
> handle the login interaction and then redirect the user to a "protected"
> resource once the login sequence is successfully completed?
Hard to believe or not, the servlet spec is totally silent about
programmatic interaction with j_security_check. That means there is
absolutely no guarantee of behavior consistency in this regard across
servlet containers -- or even across different versions of the same
container (Tomcat 3.3 and 4.x do things very differently in this regard,
for example).
Your use case is something that things like the Liberty Alliance
<http://www.projectliberty.org> are trying to solve. Unfortunately,
you're a bit early on the adoption curve for that to be helpful.
About the only portable thing you can do in the mean time would be a proxy
app that your users always went through for every request, which knows how
to do the login interaction with each back end app as needed (i.e.
whenever they challenge for credentials, answer based on what it knows
about this user, but pass all other requests through). But the
performance impact of such a proxy isn't going to be very attractive.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
