tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Valve Access to Principal
Date Sat, 08 Feb 2003 08:01:44 GMT
And here I was going to do a boring response like: defer the check to a
Filter. :-)

I'm actually using a slight variation on Craig's suggestion on one of my
internal sites (simply meaning that I can't give you a working URL), and it
works very well.

"Craig R. McClanahan" <craigmcc@apache.org> wrote in message
news:20030207230410.C56663@icarus.apache.org...
>
>
> On Fri, 8 Feb 2003, Peter Kelley wrote:
>
> > Date: 08 Feb 2003 17:29:10 +1100
> > From: Peter Kelley <peterk@moveit.com.au>
> > Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > 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 <peterk@moveit.com.au>
> > Moveit Pty Ltd
>
> Craig McClanahan




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message