On Sun, 10 Feb 2003, Peter Kelley wrote:
> Date: 10 Feb 2003 16:12:36 +1100
> From: Peter Kelley <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Valve Access to Principal
>
> I think you misunderstand my question, I want to run Tomcat standalone.
> The problem I have is that the JAAS credentials don't seem to be being
> associated with the thread that is running my JSP. The fact that JBoss
> is on the other end is probably irrelevant, the same problem would occur
> no matter what was being called.
>
No, it is *absolutely* relevant, because your complaint is that *JBoss*,
not Tomcat, is not seeing the Principal you think it should.
> I'm happy to help and contribute whatever code gets written but I need
> to know where would be the best place to do the security association.
> Putting the association in a valve doesn't seem to be working, somehow
> the association is being broken by the time the JSP code is called. Can
> you provide any guidance on where the best place to do the security
> association might be ?
>
Show me a scenario that fails in standalone Tomcat and we can talk. If
the problem shows up only in Tomcat+JBoss, go talk to whoever built that
integration.
Craig
> On Mon, 2003-02-10 at 14:58, Craig R. McClanahan wrote:
> > On Sun, 10 Feb 2003, Peter Kelley wrote:
> >
> > > Date: 10 Feb 2003 14:31:23 +1100
> > > From: Peter Kelley <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > > To: Tomcat Users List <[EMAIL PROTECTED]>
> > > Subject: Re: Valve Access to Principal
> > >
> > > 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 ?
> > >
> >
> > I'm afraid that I'm a total newbie in terms of understanding how JBoss
> > decided to integrate Tomcat. One of the benefits of the Tomcat
> > architecture is that there are many different options for this. One of
> > the disadvantages, though, is that those of us focused on the standalone
> > Tomcat server don't necessarily have a clue on how it was done in any
> > particular case :-).
> >
> > Maybe some questions to the JBoss mailing lists would be in order?
> >
> > One thing to review, though, is the order in which the valves get
> > authenticated -- you probably want to ensure that your valve is invoked
> > before any valves that the JBoss integration adds.
> >
> > > Does anyone know how this problem is being solved for Tomcat 5 ?
> > >
> >
> > Tomcat 5 has integrated support for JSR 115, but that's for authorization,
> > not authentication. At some future point, I'm sure Tomcat will
> > incorporate the results of JSR 196 ("Java Authentication Service Provider
> > Interface for Containers"), but not until that JSR actually has a public
> > release of its spec -- it has only just gotten underway.
> >
> > Craig
> >
> >
> > > 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]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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]
