tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Bug in RealmBase, JAASRealm, and/or Requestt object preventing proper role authorization
Date Fri, 21 Oct 2005 04:15:13 GMT

----- Original Message ----- 
From: "Brad O'Hearne" <>
To: "Tomcat Developers List" <>
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
> Thanks,
> Brad
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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:
For additional commands, e-mail:

View raw message