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"
<[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
