Re: AW: [Acegisecurity-developer] Using Acegi in distributed environm ent
On Saturday 05 March 2005 00:47, Andreas Prohaska wrote: > 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! I'm unclear _why_ exactly you need Acegi Security (or anything else for that matter) to secure methods and properties on Account domain object instances. As previously mentioned, domain object instances in the UI tier (be they webapp or rich client) are essentially throw-away instances that either (a) get accepted as valid on their return to the services layer and persisted or otherwise operated on, or (b) they are rejected as the principal has insufficient permissions to pass the mutated Account instance to the relevant services layer method. AOP allows you to advise domain object instances, but it's something of a new field and issues such as serialization of advisors from one web container to another is a grey area (I doubt it's done very often or easily). Does the advice look for a local collaborator, or does the container serialize unadvised instances which have advisors re-applied on the target container? It's an area of AOP best practice which sees grey to me; most people are experiencing enough of a paradigm shift getting used to AOP on their services layer. For that reason, if you're keen on using AOP on domain instances, at the very least you should consider which AOP framework you're going to use, which persistence framework, compatibilities between them, and the advice (pardon the pun) of the project team responsible for the AOP framework when it comes to serialization of advisors across containers - particularly in a fail-over-support cluster. For my two cents, I'd focus my energies on using the Acegi Security ACL capabilities properly in this sort of application, enforcing at the services layer boundary. At least you know it's simple, it works, there exists a body of design patterns and samples and people who can critique your architecture, and it is performant. HTH 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
[Acegisecurity-developer] Acegi Security - new release 0.8.0 and subproject status
Dear Spring Community I'm pleased to make the following two announcements: * Acegi Security will become a Spring subproject from release 1.0.0. * Acegi Security release 0.8.0 is now available. = OFFICIAL SUBPROJECT STATUS = Official subproject status means a closer relationship with the Spring Core project, broader adoption in Spring-powered projects, and the availability of quality professional services via Interface 21. A separate announcement will be published in the near future with additional details. Rod Johnson comments: "Subproject status for Acegi Security is overdue. Its quality and flexible design makes it a worthy part of the Spring family, and it exhibits the architectural consistency our users expect. Security is a core concern in the enterprise, and as in so many other areas a good generic framework offers tremendous value to developers. We're already seeing a lot of interest in the community and among our clients, and expect that adoption will progress in leaps and bounds with the 1.0.0 release." = RELEASE 0.8.0 = There are many improvements and fixes in release 0.8.0 (as listed at http://acegisecurity.sourceforge.net/changes-report.html). New features include: * Significant simplification of filter setup * Anonymous authentication support * Remember-me authentication support * Concurrent login prevention support * Digest authentication support (safer than BASIC authentication) * Source ZIPs for easier IDE integration, and nightly CVS snapshots * Various other fixes and improvements Most of these new features were added as a direct result of community feedback. We always welcome your feedback and suggestions. As per the Apache APR project versioning guidelines, this is a major release. We definitely expect the next major release will be 1.0.0, although release 0.8.0 should be considered stable enough for most projects to use. There are detailed upgrade instructions included in the release ZIP and on the Acegi Security home page. For Maven users, Acegi Security's latest JARs are available from http://acegisecurity.sourceforge.net/maven/acegisecurity/jars. Release 0.8.0 will be added to iBiblio very shortly. = FURTHER INFORMATION = Please visit http://acegisecurity.sourceforge.net to learn more about Acegi Security's features, browse online documentation, or download the latest release. We hope you find this new release useful in your projects. Cheers 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
AW: [Acegisecurity-developer] Using Acegi in distributed environm ent
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=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
AW: [Acegisecurity-developer] Using Acegi in distributed environm ent
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: acegisecurity-developer@lists.sourceforge.net > 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: '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:[EMA
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: '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/l
