Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
From: Brad O'Hearne <brado@neurofire.com>
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Bug in RealmBase, JAASRealm,
 and/or Requestt object preventing proper role authorization
Date: Thu, 20 Oct 2005 20:35:57 -0700
User-Agent: KMail/1.8
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200510202035.58158.brado@neurofire.com>

All,

I have discovered a bug in role authorization when using a JAASRealm and 
custom user / role principals. In a nutshell, successful authentication in 
the JAASRealm over a custom JAAS login module results in the JAASRealm 
pulling the user principal and role principals out of the authenticated 
subject and wrapping them inside a GenericPrincipal object. The generic 
principle object is then stored in the request. Then, when permissions are 
being checked in RealmBase.hasResourcePermission(), the following line of 
code is executed to retrieve the user principal:

        Principal principal = request.getUserPrincipal();

This method didn't return the wrapping generic principle, it returned my 
custom user principle. The code for the requests getUserPrincipal() method is 
as follows:

    public Principal getUserPrincipal() {
        if (userPrincipal instanceof GenericPrincipal) {
            return ((GenericPrincipal) userPrincipal).getUserPrincipal();
        } else {
            return (userPrincipal);
        }
    }

Everything looks great so far, until you get to the logic which actually 
checks the permissions. The RealmBase.hasRole() method starts with this block 
of code (with an interesting opening comment):

        // Should be overriten in JAASRealm - to avoid pretty inefficient 
conversions
        if ((principal == null) || (role == null) ||
            !(principal instanceof GenericPrincipal))
            return (false);

When this statement executes, principal is not a GenericPrincipal, by merits 
of the request's getUserPrincipal() method executed prior to calling this 
method -- it is instead a custom user principal. This causes the third part 
of the if condition to be true, causing the method to return false, and the 
method to fail, and authorization to fail. So in other words, whenever a 
custom principal is used, role authorization should be failing, and since 
this is in RealmBase, not the JAASRealm subclass, I am assuming that anyone 
with a custom principal isn't able to authorize any roles properly. 

The quick response might be to just use a GenericPrincipal type as your custom 
principle. But this doesn't make sense either, because the hasRole method is 
seeking the roles within the GenericPrincpal object (the user principal) 
which must contain all the roles.  This is what is done by the Realm code 
already. The problem is that the hasRole method needs the GenericPrincipal 
wrapper that contains the roles, NOT the custom user principal which does not 
contain the roles. 

It would be great if I am missing something But if not, I don't know if where 
you want to consider the culprit for the bug, but it is certainly a bug, and 
it breaks authorization. Please let me know what the options are for getting 
this bug fixed, as it prevents container managed security in Tomcat using 
JAAS. 

Thanks,

Brad

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