Hi Craig- I've come up with a solution that seems to work very well for my purposes. Unfortunately, my project's priority is to build on Jrun, but I'll need to adapt this solution to Tomcat in the near future. I post the description of my implemented solution just to get it out there for comment and possibly (if the solution is worthy) to help out anyone else trying to solve this problem.
The essence of the problem, again, was to enable a single sign-on through a corporate portal. The portal presents links to other corporate web applications. Clicking on those links automatically signs the user on through the web-app's security service. My solution was to create a servlet (Jrun)SecurityCredentialForward capable of interacting with the security service (in the current solution Jrun's WebAppSecurityService). By bypassing the FormAuthentication class (the real manager of the j_security_check workflow) I could avoid the two step process. Each url in the portal's application list contains a link to the security servlet and parameters specifying the applications main url, username and password. The SecurityCredentialForward takes the username and password, authenticates them with the WebAppSecurityService and if everything is kosher, redirects the user to the main web page. All "natural" web container security functions are used from there on and as far as the container is concerned, the j_security_check process ran as normal. I'm pretty sure this same approach could be used with Tomcat. It doesn't seem to incur any negative performance penalties and doesn't (as far as I can see) violate the login process since it uses resources that are already available to the servlet. Any opinions are gladly accepted. thanks, Jim > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 16, 2002 12:45 PM > To: Tomcat Users List > Subject: RE: forwarding through j_security_check > > > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
