Andy,

I agree that filtering the method response is a fascinating area. The only
problem I have always found on filtering a method response is that it
doesn't scale properly when performance is an issue. I'm particularly
thinking on Collections here, where the full collection check for
permissions would degrade performance on big enough collections.

Maybe providing "intelligent" collections and Iterators that perform the
security check when accessed could be a wiser approach for that area (like
hibernate for lazy load modification). That would imply that a response
from a method would be a proxy on the original object that enforces all
the security restrictions specified.

-----Mensaje original-----
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] En nombre de
Andy Depue
Enviado el: viernes, 31 de diciembre de 2004 0:26
Para: acegisecurity-developer@lists.sourceforge.net
Asunto: Re: [Acegisecurity-developer] MSc Thesis on middle tier security

The new model object filtering is a fascinating area in my mind.  One
thing
we've implemented (before Acegi had its own filtering) is the ability to
filter down to the property level on an object.  In other words, you can
secure a specific property and if someone doesn't have clearance then the
property will be cleared.  This introduces all sorts of interesting
problems
in some scenarios.  For example, in our case the value objects passed back

and forth between clients and server side services double as our Hibernate

data object model.  In other words, we don't have separate value objects
but
instead use a single data object model for both data access and service
invocation.  This gets quite tricky when you combine it with property
level
filtering.  Imagine a service method that returns a model object with
several
properties filtered out.  The user then makes some changes to the object
and
sends it back in another service call to be updated.  What the user sends
back to the server is a partial object in that some of the properties are
blank since they were secured from the client to begin with.  If you
persisted the object as-is, then Hibernate would blindly write those
cleared
property values back to the DB - very bad.  Oh, and don't forget that some

properties could be secured for a particular client so that they are
read-only or even write-only.  And don't forget to throw a security
exception
if the client tries to pass a value in a non-writeable field.  And then
there's recursive data structures to contend with... property values that
are
themselves collections of securable objects... and if you filtered a
collection of securable objects from a property, and the client returns
that
object to the server to be updated, how do you determine if the client
legitimately removed an object from the collection, or if the object was
filtered due to security?  You wouldn't want to have hibernate persist the

collection as-is, or it would remove from the DB objects that were only
filtered for security reasons.  Fun stuff, eh?

  - Andy


On Thursday 30 December 2004 01:49 pm, Vladimir Horev wrote:
> Hello list!
>
> I'm planning to write a MSc thesis on the subject of business tier
> security. My idea was to take part of some open source project (acegi)
> and develop some component that I could use in my thesis. Could you
> recommend me something on that?
>
> regards, Vladimir
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Home: http://acegisecurity.sourceforge.net
> Acegisecurity-developer mailing list
> Acegisecurity-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 30/12/2004

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to