tomcat-users 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 03:54:36 GMT
Charles,

I addressed this at the bottom of my email. It might be a hack that 
would work, but you would effectively be duplicating what the JAASRealm 
is doing already. The JAASRealm takes the user principal and role 
principal, and shoves them into a GenericPrinicipal. If you wanted to 
try to game the authorization, you'd have to take your role principal, 
shove it into the user principal, then let the realm shove both of those 
again into another GenericPrincpal that wrapped it. Then it would get 
your custom user principal, and the authorization might work. I thought 
about that too, but I don't know enough about the other source code to 
know if it is safe and would affect things elsewhere in code. It is 
clear from these methods that assumptions are being made based on class 
types. Such a hack would almost certainly be broken if any changes were 
made  to this part of the code.

B

Caldarale, Charles R wrote:

>>From: Brad O'Hearne [mailto:brado@neurofire.com] 
>>Subject: Bug in RealmBase, JAASRealm, and/or Requestt object 
>>preventing proper role authorization
>>
>>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.
>>    
>>
>
>What happens if you have your custom principal extend GenericPrincipal?
>It appears that all the interesting fields are marked as protected, so
>you should be able to set them in a subclass.
>
> - Chuck
>
>
>THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>MATERIAL and is thus for use only by the intended recipient. If you
>received this in error, please contact the sender and delete the e-mail
>and its attachments from all computers.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
>  
>


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


Mime
View raw message