tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad O'Hearne <br...@neurofire.com>
Subject Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization
Date Fri, 21 Oct 2005 04:26:51 GMT
Bill,

If I am reading this right, it says the bug is fixed. When will there  
be a new release that contains this fix? (Sorry for my ignorance on  
the organization of Tomcat builds).

B

On Oct 20, 2005, at 9:15 PM, Bill Barker wrote:

> http://issues.apache.org/bugzilla/show_bug.cgi?id=37044
>
> ----- Original Message ----- From: "Brad O'Hearne"  
> <brado@neurofire.com>
> To: "Tomcat Developers List" <dev@tomcat.apache.org>
> Sent: Thursday, October 20, 2005 8:35 PM
> Subject: Bug in RealmBase, JAASRealm, and/or Requestt object  
> preventing proper role authorization
>
>
>
>> 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
>>
>>
>>
>
>
>
> This message is intended only for the use of the person(s) listed  
> above as the intended recipient(s), and may contain information  
> that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended  
> recipient, you may not read, copy, or distribute this message or  
> any attachment. If you received this communication in error, please  
> notify us immediately by e-mail and then delete all copies of this  
> message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail  
> sent through the Internet is not secure. Do not send confidential  
> or sensitive information, such as social security numbers, account  
> numbers, personal identification numbers and passwords, to us via  
> ordinary (unencrypted) e-mail.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


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


Mime
View raw message