Hi Sergio,
yes, we're talking about the same scenario, let me just point out
one more issue. First of all I am/will be using a servlet application
that connects to an enterprise server that connects to the database.
Not necessarily EJBs.
I want to enforce security on domain objects (Account) in the server
tier *and* in the servlet tier.
The scenario would work almost as you described it:
A - Client calls remote method BankManager.getAccount();
A.1 - BankManager loads Account from DB
A.2 - BankManager immediately proxies Account instance with
Acegi classes to enforce security.
B - Client application (servlet) gets serialized version
of proxied Account object
==> I expect this does not work in Acegi at the moment!
C - Client modifies local, unserialized, secured Account object.
D - Client serializes and sends the modified Account object back
to the BankManager.
E - BankManager saves Account.
I assume that my client can be trusted, since it is used in a secure,
controlled environment. It could also be signed (if I wanted to be
more secure).
But even without trusting my client, assume that I have the secured
Account instance in the servlet tier. Now imagine a wizard that allows
the current user to edit the Account, perhaps in multiple steps.
Everyone would agree that it's a common pratice to put the Account
instance into the HttpSession until it's finally saved.
But since this is an online banking application, we have to use
fail-over, load-balancing superwebservers that use HttpSession
replication (by serializing sessions between servers) and BANG!
> -----Urspr�ngliche Nachricht-----
> Von: Sergio Berna [mailto:[EMAIL PROTECTED]
> Gesendet: Freitag, 4. M�rz 2005 14:10
> An: [email protected]
> Betreff: RE: [Acegisecurity-developer] Using Acegi in distributed
> environment
>
>
>
> 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: '[email protected]'
> 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: [email protected]
> > 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
> > [email protected]
> > 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
> [email protected]
> 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
>
>
-------------------------------------------------------
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=click
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
