tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bárbara Vieira <barbar...@di.uminho.pt>
Subject RE: Tomcat's container architecture - Authenticator
Date Wed, 28 Nov 2007 15:37:35 GMT
Hi !!

>are you sure that invoke method of AuthenticatorBase is called inside
FormAuthenticator?

 

No, the invoke(Request request, Response response) method of
AuthenticatorBase isn’t called in FormAuthenticator, but FormAuthenticator
inherits that method from AuthenticatorBase. So, when you are
re-implementing some valve like FormAuthenticator, the invoke(Request
request, Response response) method is also inherited. 

Looking at invoke(Request request, Response response) method code that is
inherited, you’ll see that the method always check if the user was already
authenticated. I.e. the first action of this method is check if the
application is caching data, and if so, 

-          First it checks if there are a Principal in the Request

-          If there isn’t a Principal in the Request, it checks if there is
a Principal in Session

If the user was already authenticated, there is always a Principal in the
Session. What the method does, is putting that Principal in the Request.
When the Request is passed to authenticate(Request request, Response
response, LoginConfig config) method the only thing that it does is test if
the Request has a Principal. My question about that is : why can’t we just
return true in the invoke method, when it test if the Principal is in the
Session or is in the Request? Why we have to put the Principal in the
Request, and then authenticate that Request?! I would like to know what kind
of security it provides.

 

> I have seen that Principal is always null then you request
getUserPrincipal() from an auth so you can remove these lines above, it's
only a waste of time and of checks.

 

The principal isn’t always null in the Request J The principal is null when
the user isn’t authenticated yet. After that, the Principal is saved in the
internal Session and the invoke method put that Principal in the Request.
So, when the authenticate method is called, the Principal isn’t null, and it
executes that code.

 

> I was trying to discover what happens when the auth returns TRUE or FALSE
but i haven't found material about it. I can only understand that if TRUE
all works fine, and FALSE is a bad thing

 

If you look at invoke(in the AuthenticatorBase) method code you’ll see
what’s happen. When authenticate method returns true, the invoke method
tests if the user has permissions to accede to that resources, and if it
has, calls the next valve in the StandardPipeline. You can see this code in
http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.25/src/  -
apache-tomcat-5.5.25-src.zip.

 

 

Thanks,

Regards from Braga, Portugal

Bárbara Vieira       

 

From: Carlo Politi [mailto:c_politi@yahoo.com] 
Sent: quarta-feira, 28 de Novembro de 2007 14:15
To: Bárbara Vieira
Subject: Re: Tomcat's container architecture - Authenticator

 

Hello :)
are you sure that invoke method of AuthenticatorBase is called inside
FormAuthenticator?
In my experience of these months of study, i have understood that the only
things you need are:
1) create an authenticated principal (or by invoking a login module or
creating yourself a principal)
    in Form (as in Basic) you invoke the login module  with: principal =
context.getRealm().authenticate(username, password);

2) register the authenticated principal with the method "register" of
AuthenticatorBase

only these you need to make work an auth

// Have we already authenticated someone?

        Principal principal = hreq.getUserPrincipal();

        String ssoId = (String) request.getNote(Constants.REQ_SSOID_NOTE);

        if (principal != null) {

            if (log.isDebugEnabled())

                log.debug("Already authenticated '" +

                    principal.getName() + "'");

            // Associate the session with any existing SSO session

            if (ssoId != null)

                associate(ssoId, getSession(request, true));

            return (true);

        }


I have seen that Principal is always null then you request
getUserPrincipal() from an auth so you can remove these lines above, it's
only a waste of time and of checks. 

I was trying to discover what happens when the auth returns TRUE or FALSE
but i haven't found material about it. I can only understand that if TRUE
all works fine, and FALSE is a bad thing

 

  _____  

 <http://us.rd.yahoo.com/mail_it/taglines/*http:/it.messenger.yahoo.com>
Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message