tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
Date Sat, 04 Apr 2009 22:36:11 GMT

On Apr 4, 2009, at 3:01 PM, Xie Xiaodong wrote:

> Hello, Dear All,
>   First, thank you very much for you valuable comments, Mark.
>   I've revised my project plan based on the comments of Mark, since  
> I could
> not edit my proposal any longer, I wrote the revised version of  
> project plan
> in a comment of my proposal, you can find it for certain by  
> searching the
> "Show Student Proposal" page with "xiaodong xie wrote". Sorry for this
> inconvenience.
>   I am now getting myself familiar with the Servlet Container  
> Profile of
> JSR-196 in order to move the Authentication funcationality of valve  
> into
> some independent structure consistence with JSR-196. This part will  
> be added
> into my project proposal in some comment later.
>   Any more comments, feedback and criticism to my proposal are  
> welcomed.

While it is possible to implement the built in auth methods (BASIC,  
DIGEST,  FORM, CLIENT_CERT) as jaspi auth modules it's not as  
efficient as having a more tomcat-specific auth method.  The important  
part is really having a validate request method called before the web  
resource constraint check and a secure response method called after  
the request has been processed.  There are a lot of opportunities for  
improved caching if you don't follow the jaspi model exactly, mostly  
by letting the authenticator return the user identity rather than  
passing in a brand new Subject instance for each request.

I recommend that the valve or filter look something like this:

check user data constraints
Status status = validate request
if (status == success) {
   check web resource constraints
   process request
   secure response
//otherwise the validate request  call will have set up an appropriate  
response to continue the authentication message exchange

"validate request" and "secure response" are delegated to some kind of  
authenticator similar to but more efficient than a jaspi auth context

constraint checking can either be (abstract) methods on the (base)  
valve or delegated to some other object.  The point here is to easily  
support both constraint based checking (as done in tomcat today) and  
jacc based permission checking (as done in geronimo and presumably  
other javaee integrations such as jboss)

david jencks

> -- 
> Sincerely yours and Best Regards,
> Xie Xiaodong

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message