Thanks Craig, this sounds like a much cleaner solution than what I eventually tried which was to copy the session grabbing code out of AuthenticatorBase and use it to get the required principal.
The problem I am having now is that JBoss still thinks that the logged on user is the last one that logged in from any browser rather than the one logged in with the current session. I have run this through the debugger and my DoAsValve is getting called with the right principals subjects but somehow the JAAS security credentials that get to JBoss belong to the user that last logged in. I'm suspecting that the code that actually processes the JSP is running on another thread but I haven't yet gone down to that level to see. Surely someone else has come up against this problem before ? Does anyone know how this problem is being solved for Tomcat 5 ? On Sat, 2003-02-08 at 18:24, Craig R. McClanahan wrote: > On Fri, 8 Feb 2003, Peter Kelley wrote: > > > Date: 08 Feb 2003 17:29:10 +1100 > > From: Peter Kelley <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: Tomcat Users List <[EMAIL PROTECTED]> > > Subject: Valve Access to Principal > > > > I'm writing a valve to associate a request with a subject using JAAS. To > > do this I need to get access to the userPrincipal from the request or > > the session. Unfortunately the method that sets this association in > > org.apache.catalina.authenticator.AuthenticatorBase gets called AFTER my > > valve meaning that I can't get access to the principal. > > > > My valve is currently defined in a context element in server.xml and I > > can see it on the call stack when I set a breakpoint in > > AuthenticatorBase in the debugger. > > > > Any suggestions as to how I could get the valve to be executed after the > > authenticator ? > > > > I've got an idea, but it requires a little background first. > > First, let's understand why the behavior you observe actually happens. As > the server.xml file is parsed, each <Valve> element you declare is added > to the valve pipeline for this webapp. Among other things, this means > that you are guaranteed that valves are invoked in the order that you > declare them. > > After server.xml is processed, but before the webapp is made available, > the start() method of an instance of > org.apache.catalina.startup.ContextConfig is called to perform any final > setup needed before the application is enabled. One of the potential > setups (see method authenticatorConfig()) is to set up an Authenticator if > this webapp declared an <auth-method> in its web.xml file (SIDE NOTE - you > don't pay any runtime overhead for container managed authentication unless > you asked for it). The net effect is that, if you're using container > managed authentication, the corresponding Authenticator valve is > automatically added to the pipeline -- but *after* any manually configured > valves. > > So, to meet your requirements, we need a mechanism to ensure that the > Authenticator is configured into the pipeline *before* your valve is. > Currently, you can do this if you manually configure it, because > authenticatorConfig() checks to see if an Authenticator has been > configured already. So, you would need to say something like this to > configure (say) the Authenticator for form-based login ahead of your > MySubjectValve valve: > > <Context path="/foo" ...> > > <!-- Configure an Authenticator implementation to be used --> > <Valve className="org.apache.catalina.authenticator.FormAuthenticator"/> > > <!-- Configure your Valve that wants to see the Principal --> > <Valve className="com.mycompany.MySubjectValve" .../> > > </Context> > > A downside of this approach is that you have to configure what login > method to use in server.xml (the <auth-method> selected in web.xml > essentially gets ignored). > > An upside of this approach is that you can easily implement and configure > an Authenticator that supports a login mechanism totally different from > any of the standard methods defined by the servlet spec. For example, > it's feasible to define an Authenticator that interacted with a Project > Liberty identity server (http://www.projectliberty.org) to enable > cross-host single sign on support. > > > -- > > Peter Kelley <[EMAIL PROTECTED]> > > Moveit Pty Ltd > > Craig McClanahan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Kelley <[EMAIL PROTECTED]> Moveit Pty Ltd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
