Authentication filters, web.xml, and portability

[DONNIE HALE <DH...@longaberger.com>]

Folks,

We've got a Tomcat 3.2.1-based interceptor in which we implement access to a custom realm for authentication, authorization, etc. We've implemented our own java.security.Principal; and we do what's needed to support getRemoteUser, getPrincipal, isUserInRole, etc.

We'd like to get away from the proprietary-based API. What I can't quite figure out, however, is if it's possible to do a truly portable authentication/authorization using just the filtering (and possibly listener) APIs. Most especially, we still want to be able to rely upon the declaritive aspects of web.xml where we can specify required roles for URL patterns.

It seems like it would be reasonably straightforward to write a Filter which wraps HttpServletRequest and overrides getRemoteUser, getPrincipal, and isUserInRole. So any application-based security access (i.e. Java code in a servlet or JSP) would go through our implementation. What's not clear, at least from my reading of the spec, is whether the container is required to use those same methods when it's determining if access should be granted to a resource which has role restrictions placed on it in web.xml. If the container must use those methods, then I think my question is answered (though I'm sure there are some I've forgotten to ask :). If not, then I either go to a non-portable API (e.g. a Tomcat Valve); or I have to implement my own mechanism for handling the role restrictions in web.xml.

Does anyone have definitive information on how web containers must, or at least in very widely-followed practice do, handle this?

Thanks,

Donnie



--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>