Sorry for the delayed response...
My basic thought for the "SecurityManager" idea was: gee, wouldn't it
be nice if any time a dataobject was "unsqueezed", I could call into
a service that would look at the object, the current user, and the
request context, and figure out if the user has permission to access
the object in that request context?
So, I was thinking, I could define a service interface, say...
DOSecurityManager or some such, with a simple API, like:
public void authorizeAccess(Persistent obj);
So, after unsqueezing an object, the squeeze adapter would give your
"SecurityManager" implementation a chance to inspect the object and
determine whether your application should let the current object be
read or edited by the current request (you can get information like
the current Request, session, user, etc. via tapestry and application-
dependent mechanisms). Then if the action is denied for the current
user+object, you can, say, throw a PageRedirectException to a
"permission denied" sort of page, or whatever is appropriate for your
application.
There are two reasons I shy away from hashing the request: usability,
and "then what?"
1) Usability:
For most situations, I don't have a problem with a user modifying a
url by hand; I've done it, I suspect that all of us have. The
important thing really isn't (usually) that the user gives us back
exactly something that we sent them, but that they have permission to
access the thing that they are requesting. If the user wants to jump
directly to account x and they are savvy enough to do so, more power
to them, imo, provided they have appropriate permissions to access
account x; as stated in my original e-mail, I don't enforce this
client side, but server side.
2) "Then what": Suppose I incorporate a hashing strategy. When
squeezer unsqueezes an object, suppose that the hash fails. Now
what? Certainly, I could throw, say, a
"AuthorizationFailedException" or "AccessDeniedException" or some
such... but is that really what you want?
One possibility would be to combine the two ideas... make the
security manager api have one or more methods... something like:
/*take the String generated by the squeezer and encode it in some
form, eg, hashing it, or adding a hash token to the string. Not that
the returned String would have to have the appropriate prefix.*/
public String encode(String original);
/*given the encoded string, give the squeezer back the original
string that it squoze; this gives you a chance to verify, eg, a hash
token as correct*/
public String decode(String encoded);
/*verify that the current can be accessed by the current request*/
public void authorizeAccess(Persistent object);
I could then provide a default implementation of the security manager
that adds a hash token to the value.
Thoughts?
Robert
On Apr 28, 2007, at 4/288:09 AM , Michael Gentry wrote:
> The auto-hashing sounds interesting to me--as long as the hash could
> be seeded by the individual application developer (or even on a
> per-user basis using a session ID, etc). I didn't totally follow what
> you meant by the security manager scenario, though. Could you
> elaborate a bit on that?
>
> Thanks!
>
> /dev/mrg
>
>
> On 4/12/07, Robert Zeigler <robert..uregumption.com> wrote:
>> So, I currently work around this issue by validating server-side that
>> the user has the appropriate permissions to edit the object[s] that
>> came back with the request. However, I[ve been thinking for awhile
>> now of extending my existing squeeze adapter implementation (the one
>> on Tassel) to address security concerns like this. One possibility
>> would be to use some sort of hashing mechanism, as mentioned by
>> Peter. Another possibility (which is something I'm leaning towards)
>> is to allow for some sort of "security manager", where the squeeze
>> adapter can "re-inflate" the object, then hand it off to the security
>> manager for inspection to make sure that the user responsible for the
>> current request has permission to access the object. Thoughts/
>> comments?
>>
>> Robert
This archive was generated by hypermail 2.0.0 : Wed Jun 06 2007 - 19:17:33 EDT