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]
