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