tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thom Park <tp...@borland.com>
Subject Re: Auth bug in 3.2.1?
Date Fri, 13 Apr 2001 05:31:26 GMT
Hi Marc,

I saw this problem in 3.2.1 as well  - I made a fix for it in the tomcat that
ships with the Borland AppServer but
couldn't get anyone to comment on the fix in the main code-line (essentially
I'm not a commiter so couldn't submit the fix)

Here's what I found:

The following code is in org.apache.tomcat.core.RequestImpl.java:

    public Principal getUserPrincipal() {
         if( getRemoteUser() == null ) return null;
         if( principal == null ) {
             principal=new SimplePrincipal( getRemoteUser() );
         }
         return principal;
    }

Notice the call to SimplePrincipal - this creates a new SimplePrincpal object
(i.e. a java.security.principal) using the
name associated with the remote User call.

I found two problems with this approach -

1. The username used was not that of the current user - it was of the
previously authorized user - subsequent users after the first one to be
authorized
    didn't get changed  the reason for this is that the only time we refresh
the principal with a new user, is if the principal was null, but, in this
case, it wasn't
    the principal still held the previous user's principal..

2. If you were using a custom Realm for authorization (e.g. LDAPRealm), then
this 'new' principal wouldn't be valid for that authorization object.
   If the servlet tried to use that 'special' principal for use with some
other software, it would no longer be the 'special' principal -it would be a
SimplePrincipal.


 It blew my J2EE CTS testing out of the water in several places.

I fixed it by doing the following:
1.  in org.apache.tomcat.core.RequestImpl.java: I made the following change
to getUserPrincipal:

    public Principal getUserPrincipal() {
         if( getRemoteUser() == null ) return null;
         // else return principal
         return principal;
    }

And in SimplRealm (and JDBCRealm and any other special Realm Manager) I added
the following to the authenticate method:
(in bold).  My rationale for making this change was that, given it was the
Realm manager's job to authenticate the user - and, only after authentication

should the userPrincipal be set, I moved the responsibility for setting the
UserPrincipal to the Realm manager.

This also meant that, at any time following successful authorization, the
current user principal would be correct for the user.

    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;
    }

Anyway, that's the story behind this particular problem.

There's also a bug in support for security-role-links but that's another
story ;-)

-Thom


Marc Palmer wrote:

> Hi,
>
> I'm a relative tomcat newbie but have discovered what looks to me like a
> bug in the simple tomcat-user.xml authentication interceptor.
>
> In a nutshell:
>
> In tomcat-users.xml I have 2 users, in 2 different roles, let's say:
>
> "john" has role "manager"
> "jane" has role "clerk"
>
> They auth fine, my servlet is protected using this scheme, everything is
> beautiful.
>
> However, when a (real life) user exits their browser (to clear auth
> credentials) and opens a browser again on the same PC and goes to my site
> and logs in as a different tomcat user, the user Principal remains the
> same as the previous request, but the role changes!
>
> Step by step:
>
> 1) User logs in as "jane". Servlet prints "user = jane, role=clerk"
>
> 2) User closes and re-opens browser window.
>
> 3) User logs in again, this time as "john". Servlet prints "user = jane,
> role = manager".
>
> So, basically getUserPrincipal is not changing, for some WEIRD reason.
> Role changes ok, so auth is happening, but it's like the auth interceptor
> is caching principals by IP or something.
>
> AFAIK this is not a problem with the browser (IE5) because I have
> rebooted in between logins and the problem still occurs. In addition,
> keeping a second auth attempt (that shows incorrect user principal) open
> in the browser and restarting tomcat and then pressing REFRESH on the
> browser sends the CORRECT principal to my servlet – so it looks like the
> browser is sending the right credentials.
>
> Am I being silly, or is this a boo-boo?
>
> Cheers

--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html


Mime
View raw message