I have narrowed down my problem:
Wrapping the HttpServletRequest is not sufficient because CoyoteRequest
and CoyoteRequestFacade mask the real user principal. A
'setUserPrincipal' call cannot be made on the HttpServletRequest in the
Filter because the type is CoyoteRequestFacade, and not CoyoteRequest
(which supports setUserPrincipal). Why the servlet spec omits
'setUserPrincipal' in HttpServletRequest interface, I do not know. But
since it cannot be set on the CoyoteRequestFacade, all 'isUserInRole'
calls delegated to CoyoteRequestFacade will return false, because
CoyoteRequestFacade does not have a valid user principal.
This could be worked around if there were just a call in
CoyoteRequestFacade to return the actual CoyoteRequest upon which the
userPrincipal could be set.
Aaron Hamid
On Fri, 31 Jan 2003 [EMAIL PROTECTED] wrote:
>
> Hello all,
>
> I have written a filter to do custom authentication. This filter
> creates an HttpServletRequestWrapper subclass and overrides
> getRemoteUser() and getUserPrincipal(). getUserPrincipal() returns a
> valid principal object.
>
> However, when I use such a filter in 4.1.18 LE in a webapp which uses
> realm-based authentication, with the login-config commented out, or
> auth-method set to NONE, I always get:
>
> Configuration error: Cannot perform access control without an
> authenticated principal
>
> This is being emitted from AuthenticatorBase, accessControl method, by
> this block of code:
>
> // Which user principal have we already authenticated?
> Principal principal =
> ((HttpServletRequest)
> request.getRequest()).getUserPrincipal();
> if (principal == null) {
> if (debug >= 2)
> log(" No user authenticated, cannot grant access");
> ((HttpServletResponse) response.getResponse()).sendError
> (HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
> sm.getString("authenticator.notAuthenticated"));
> return (false);
> }
>
> principal here is obviously returning null, and thus my filters have not
> been called at this point.
>
> Is there any way to get my filters called first? Or for tomcat auth not
> to be called at all? The webapp does its own internal authorization with
> the realm (which points to a database). I have set all res-auth elements
> I can find to 'Application', yet Tomcat still insists on performing this
> auth.
>
> Is what I am trying to do possible? At one point I attempted to
> implement a tomcat-specific Authentictor type and class, registering it
> in the Authenticators.properties, and also a custom realm, but this was a
> failure, and doesn't really map to the semantics I wish to implement. I
> wish to still rely on the realm defined in the container, yet derive the
> literal username, prior to authorization against said realm, from logic in a
> filter.
>
> Aaron Hamid
> Cornell University
>
> ---------------------------------------------------------------------
> 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]
