[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-dev
Subject:    [Proposal] Fix for getUserPrincipal problem.
From:       "Thom Park" <tpark () inprise ! com>
Date:       2000-12-31 22:50:48
[Download RAW message or body]

Hello!

I have, what I believe is a fix for a problem reported by me earlier
with getUserPrincipal, where two separate browser sessions return the
same principal, even when the authorized users are different. The
proposal is this:

In several places in the code there are comments that state that the
adapter that performs the authorize should set both the 'remote user'
and the 'principal', however none of them ever do. My proposal is that
SimpleRealm and JDBCRealm be modified to set the principal at the time
they successfully authorize a user (and call setRemoteUser).

I further suggest that the requestImpl class no longer allocate a
SimplePrincipal should the principal be null. It should be the job of
the authorizing class to allocate the principal, not the requestImpl. To
my mind, the only reason the principal is null (In requestImpl) is if
the user failed authorization. I believe that the routine that sets the
user should also set the principal.

I made the following code changes and successfully tested them on NT
with Tomcat 3.2.1. Could someone please review them and let me know if
they are valid for submission into the 3.2 product as I am not a
committer.

Please advise as to whether my logic (and code) makes sense as this
problem is causing quite a headache with some additional security work
that I am assisting with.

Note as the code is very short, I included the entire methods that I
modified in the three files (SimplRealm.java, JDBCRealm.java and
RequestImpl.java)



Change to SimpleRealm's authorize code (Starting at line 122):

    public int authenticate( Request req, Response response )
    {
       // Extract the credentials
       Hashtable cred=new Hashtable();
       SecurityTools.credentials( req, cred );

       // This realm will use only username and password callbacks
       String user=(String)cred.get("username");
       String password=(String)cred.get("password");

       if( debug > 0 ) log( "Verify user=" + user + " pass=" + password
);
       if( memoryRealm.checkPassword( user, password ) ) {
       if( debug > 0 ) log( "Auth ok, user=" + user );
       req.setRemoteUser( user );
       // set principal as well
       req.setUserPrincipal(new SimplePrincipal(user));
       Context ctx = req.getContext();
       if (ctx != null)
         req.setAuthType(ctx.getAuthMethod());
       }
       return 0;
    }


Change to JDBCRealm's authorize code (starting at line 472):

    public int authenticate( Request req, Response response ) {
        // Extract the credentials
        Hashtable cred=new Hashtable();
        SecurityTools.credentials( req, cred );
        // This realm will use only username and password callbacks
        String user=(String)cred.get("username");
        String password=(String)cred.get("password");

         if( authenticate( user, password ) ) {
           if( debug > 0 ) log( "Auth ok, user=" + user );
           req.setRemoteUser( user );
           // also set UserPrincipal in request
           req.setUserPrincipal(new SimplePrincipal(user));
           Context ctx = req.getContext();
           if (ctx != null)
               req.setAuthType(ctx.getAuthMethod());
        }
        return 0;
    }

Change to requestImpl's getUserPrincipal code (starting at line 362):

    public Principal getUserPrincipal() {
       if( getRemoteUser() == null ) return null;

        /*
         principal is now set in [any] one of the adapters that handle
         the authorize function. The servlet spec states that if a user
hasn't been
         authorized, then null should be returned in the principal,
ergo, if the remoteUser
         has been set, then the principal has to have been set as well
-if not then there's a
         continuity failure here and it's best to return null.
         */
       return principal;
    }






---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]