You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ar...@cornell.edu on 2003/01/31 20:48:52 UTC
authentication and filters
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: authentication and filters
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 31 Jan 2003 arh14@cornell.edu wrote:
> Date: Fri, 31 Jan 2003 15:52:57 -0500 (EST)
> From: arh14@cornell.edu
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: authentication and filters
>
>
> 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.
>
That would defeat the whole purpose of having the facade, which is to
*prevent* applications from messing with container internal objects.
Instead, you need to override the getRemoteUser(), getUserPrincipal, and
isUserInRole() methods in your wrapper class.
> Aaron Hamid
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: authentication and filters
Posted by ar...@cornell.edu.
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 arh14@cornell.edu 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org