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 04:20:06 GMT
Right, but I think you are missing what I am saying. The hasRole()  
method takes two parameters: a Principal (which is going to be the  
custom user principal returned from the request.getUserPrincipal()  
method), and a String role name. Roles aren't being passed to the  
hasRole method, only the user principal and the role that it is  
looking for.

In the JAAS login module, when you authenticate you add your user  
principal and role principals separately to the subject. The user  
principal does not contain roles. Its the realm that combines those  
after pulling them from the subject after the fact. So in the JAAS  
login module, what you would have to do is instantiate a user  
principal that is a subclass of GenericPrinicipal for your user  
principal, then add your role principals to that user principal, and  
then add the user principal and all the role principals to the  
subject. And then, of course, the same thing would happen all over  
again in the realm code after exiting.

Yes that could be done. What an ugly hack though. Depending on what  
the dev list comes back with, I may give it a try. It explains,  
however, the behavior I had in Tomcat 5.0.28. In 5.0.28, I couldn't  
get my user principal out of the request -- instead, the  
request.getUserPrincipal() method returned a GenericPrincipal.  
However, role authorization worked. So It really looks probably that  
someone added code to the getUserPrincipal() method to return the  
custom user principal, and broke role authorization.

Alas....a regression test that escaped... :-)

B

On Oct 20, 2005, at 9:09 PM, Caldarale, Charles R wrote:

>> From: Brad O'Hearne [mailto:brado@neurofire.com]
>> Subject: Re: Bug in RealmBase, JAASRealm, and/or Requestt
>> object preventing proper role authorization
>>
>> 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.
>>
>
> No, that's wrappering.  What I suggested was declaring your custom
> principal as a subclass of GenericPrincipal so the JAASRealm code  
> could
> use it directly.
>
>
>> 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.
>>
>
> The rules of subclassing make this perfectly safe.  The rest of the  
> code
> may be using your object, but the other code can only refer to it via
> the methods declared in the superclass GenericPrincipal; whatever
> customization you've made is invisible to the rest of Tomcat.  You  
> would
> also have the freedom of overriding the GenericPrincipal methods to  
> suit
> your needs.
>
>  - 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