tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Valve Access to Principal
Date Sat, 08 Feb 2003 07:24:19 GMT


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