First of all I'll try to clarify what I understand for the problem you propose. A- Client calls remote method getAccount B- Client application gets serialized version of Account object C- Client modifies local unserialized account Object D- Client serializes and sends the modified account object back to the server (withdraw method) E- Server stores the Account object
With this scenery on mind your problems are: Protection of data on account object. You should control serialization in order to not send those properties to the client (mark them as unserializable). Protection against unauthorized Account object send. Acegi works fine protecting the access to the method withdraw on the server (for example). Protection against unauthorized properties on the account object traveling. Here some sort of acl or voters would be the ideal solution for the withdraw method. >From my point of view there is no use on restricting property and method access on the client since that code can be easily changed. It is in the server where you have to enforce those controls. Same thing as making an html login form that checks that user is right using local html variables and after that checks calls an unprotected jsp. On the other hand, if you want to have security controls on your heavyweight client applications then you should define those security restrictions also in the client (maybe using acegi) and there would be no unrestricted access neither on client nor on server. Hope this helps Sergio. -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Andreas Prohaska Enviado el: jueves, 03 de marzo de 2005 16:11 Para: 'acegisecurity-developer@lists.sourceforge.net' Asunto: AW: [Acegisecurity-developer] Using Acegi in distributed environment Well, that's true for the business objects implementing services. Sorry that I didn't make that clearer. What I have in mind are domain objects actually modelling the data, protected by Acegi. Imagine an Account class that offers a method called getBalance() and that method is protected with Acegi. The actual Account instance is loaded in the server tier and proxied with AOP Alliance classes to intercept the MethodInvocation. The MethodInvocationInterceptor is also linked with the AccessDecisionManager instance of the server. Everything fine so far. But then, this Account instance has to be sent to the web tier, because I want to display the Account to a user. Perhaps in order to change the name of the Account owner, but NOT the balance. As far as I know the Acegi framework, every MethodSecurityInterceptor, AccessDecisionManager, etc. would get lost on the way to the web tier, either leaving the object unprotected or causing exceptions. Now I wonder if there is any recommended way to address this problem (if it's a problem). > -----Ursprüngliche Nachricht----- > Von: Ben Alex [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 3. März 2005 12:41 > An: acegisecurity-developer@lists.sourceforge.net > Betreff: Re: [Acegisecurity-developer] Using Acegi in distributed > environment > > > Andreas Prohaska wrote: > > > I bet that most of us use Acegi in some kind of EJB or > servlet tier, but I > >expect problems when AOP proxied object instances are sent > over the wire. > >Imagine the case that you want to protect your business > model objects with a > >MethodInvocationInterceptor. Another problem seems to be > Serialization used > >during HttpSession replication in the web tier. I doubt that > this could > >work. Please correct me, if I'm wrong. > > > > > I'm not sure what the problem would be. Your services layer > beans will > still be located on the original machine (the server). You're client > machine just has a proxy stub, generated from the services layer > interface. The AOP will still take place on the server and > never be proxied. > > Best regards > Ben > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Home: http://acegisecurity.sourceforge.net > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick _______________________________________________ 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.308 / Virus Database: 266.6.0 - Release Date: 02/03/2005
smime.p7s
Description: S/MIME cryptographic signature
