Luis, the way you see it is completelly wrong. If you are looking only for a way to encrypt data sent to the server, stop wasting time researching 3rd party libraries, instead visit www.verisign.com, buy a certificate and use SSL! There just is NO OTHER WAY to provide better encryption for the data sent over the net, that could be implemented on a javascript client. Reason is simple, if you would be able to implement AES or some other symmetric cipher on the javascript client, you simply would not be able to exchange the key for the cipher, just because a secure, man in the middle proof asymmetric cipher CAN NOT be implemented in pure javascript. With all that said, you do not need SECURITY, you just need ENCRYPTION. After you get it (SSL I mean) and get comfortable and happy about encrypted data being sent to the server, you may run into a situation, when a non authorized person, called a hacker or an attacker, starts to execute services on you server via RPC, that he is not supposed to have access to. Then you will realize, that despite all the fancy encryption, you gotta start looking for a way to prevent this. And maybe you will also realize, that security is not just encryption. Btw. if you still want to argue about whether acris-security is about security or not, I suggest, you visit spring security forums and try it there. Good luck trying to explain to them that Spring Security actually isn't about security, it's just an "authentication interface".
P.S.: Acris-Security is mainly about authorization, not authentication...just to get the facts straight. On 14. Aug, 17:22 h., Luis Daniel Mesa Velasquez <[email protected]> wrote: > The way i see it... i only care for security between the client and > the server, meaning i don't want others to see what the client is > doing or what the server is sending. If the user has vulnerabilities, > it is not my responsability to secure every user's computer, therefore > i only think having an encryption mean to send sensitive data is > useful. It doesn't need to be fancy, sending a hash instead of the > username/password would suffice. A means to make it expensive for an > intruder to misrepresent someone, but as we all know, users leave > computer to go to the bathroom and could however leave their computers > available for eavesdropping. So you need to know nothing would be > sufficient and choose a limit to what you will provide in terms of > security. Protect data enough but don't be obsessed with it. Then > comes the authentication and authorization issue, which deals only > with validating the user is who he says he is or at least have a means > to discern who is who and what they can do. > > So Acris really is an authentication interface to the authentication > in the server. It has nothing to do with security. Authorization and > authentication deals more with data integrity and role policies. It > has a great way of delivering that interface to the client, and a > clean programming paradigm. > > I don't build whole GWT apps, i add bits and pieces of it to whatever > i develop in regular multi-page websites. If something is not going to > be secure, i might as well send it on a regular Http request/response > in the page, like a login screen and login credentials. > > Nothing is secure, just secure enough... > > On Aug 13, 5:23 am, Peter Simun <[email protected]> wrote: > > > Hi Greg, > > > why is more acceptable for you, that user will see whole application > > (also the screen which is not allowed to use) rather than ONLY screens > > that he is able to use. > > Your argument becomes to me little bit funny: "tech support and UI > > nightmare". If you have correctly setup user permissions, then no > > extra support is necessary and I have no idea which UI nightmare you > > mean. > > > Maybe you mean that UI nightmare, that you will have complex > > application with 50 screen and normal user who is allowed to use only > > 10 of them will consider your application as UI nightmare - because on > > 80% of the screen he choose he will gets the message: "You do not have > > permissions to use this screen, please contact tech support". Ou, and > > this tech support you mentioned? > > > Yes, with your solution, you will need this kind of tech support and > > hopefully you will work at first line support and you will tell the > > users that they are not able to use the 80% of the screens because > > they are only normal users, not super users. > > > And hopefully you will enjoy the question: "So, why I can see that > > screens I cannot use?" > > > hmm? > > > And - about the "correct name" - it's security! because acris-security > > project has much more features than "consistent UI", there is complex > > session handling, synchronize sessionID between client->server in a > > completly transparent way, ACL data level security, server side > > security based on spring security for securing the serivces and > > complex integration of this stuff into one consistent solution. > > > Peter > > > On 12. Aug, 17:41 h., Greg Dougherty <[email protected]> > > wrote: > > > > "I'm talking about displaying the screens and securing the > > > components." > > > > The problem is that that is a meaningless statement, and to the extent > > > that it's not meaningless, it's pointless. > > > > I suppose you could set up your code so that the JS to display a > > > screen isn't downloaded unless the user will be able to use that > > > screen, but why bother? What is the win by doing that? > > > > Speaking for myself, I'd MUCH rather have a screen show up, and tell > > > me I can't use it, then not be able to find the screen. > > > > After all, if I find the "Update Data" screen, and it says "you do not > > > have permission to use this", then I know I dont' need to look for it > > > anymore. > > > > And, if the server has my security credentials wrong, I can call tech > > > support, tell them that, and have them fix it. > > > > Calling tech support to tell them I can't find a screen at all is a > > > much different, much more aggravating, call. For both me AND the tech > > > support person. > > > > It's not security, it's just a tech support and UI nightmare. > > > > Greg > > > > On Aug 12, 2:42 am, Peter Simun <[email protected]> wrote: > > > > > I'm not talking about the data. Secured data, that user is not allowed > > > > to minupulate with, are not sent to client! This logic is done on the > > > > server side security implementation. > > > > I'm talking about displaying the screens and securing the components: > > > > - like if the user is not able to maintain users, he will not see the > > > > menu item "user maintenance" on the application menu > > > > - if the user is able to view users, but not modify the fields, he > > > > will see the readonly form (just for view purposes) > > > > > Everything just by annotate UI components with @Secured annotation > > > > > Peter > > > > > On 12. Aug, 09:17 h., cokol <[email protected]> wrote: > > > > > > its a way it works, like Greg said - a dumb client should not worry, > > > > > or better said not be too serious about security, everything what > > > > > happens on the client is INSECURE, so the only security concern it > > > > > should think about is to make the security "look good" to its user. > > > > > > the real security should always reside on the backend, client shall > > > > > NEVER get a data from the server for unauthorized user so that client > > > > > can make decisions on its own - either to display the data or not. > > > > > > On 11 Aug., 23:54, Peter Simun <[email protected]> wrote: > > > > > > > Hi Greg, > > > > > > > thanks for the answer. Who casers? Users cares! > > > > > > > Let's imagine that you will modify all the data you are "able" to > > > > > > modify (as an user of the application) and the the server will > > > > > > response you, that you are not allowed to modify them! Are you > > > > > > satisfied with that solution? Is that a common approach? > > > > > > > Isn't that solution that you have client state consistent with your > > > > > > server implementation cool? Never wanted this kind of solution? > > > > > > Second thing: what about the session handling in your GWT > > > > > > applications? What if acris can handle this for you transparently? > > > > > > And finally: "properly secured server" ... what is that? I can say, > > > > > > this common approaches are coupled in the acris-security project and > > > > > > well tested in the real environment. > > > > > > > Do you thing this is not enought? > > > > > > > Peter > > > > > > > On 11. Aug, 23:31 h., Greg Dougherty <[email protected]> > > > > > > wrote: > > > > > > > > Hi Peter. > > > > > > > > Not to be rude, but who cares? > > > > > > > > Who cares if the user can see a screen that says "Client Data", > > > > > > > when > > > > > > > the user can't actually download any of that client data? > > > > > > > > IOW, what's the point? If your sever is properly secured, then > > > > > > > users > > > > > > > who aren't allowed to see the client data won't be sent it, and > > > > > > > users > > > > > > > who aren't allowed to modify the data will have their modification > > > > > > > requests denied. If it isn't properly secured, then what AcrIS > > > > > > > does > > > > > > > is pointless. no? > > > > > > > > Yes, it's nice from the UI perspective to let the user know why > > > > > > > they > > > > > > > can't see / change the data, but what in the world does that have > > > > > > > to > > > > > > > do with "security"? > > > > > > > > Greg > > > > > > > > On Aug 11, 9:33 am, Peter Simun <[email protected]> wrote: > > > > > > > > > Hi Stefan, > > > > > > > > > of course, client side code could never be secured! AcrIS > > > > > > > > security > > > > > > > > fully depends also on securing the RPC services (on the server > > > > > > > > side, > > > > > > > > client side security is an complementary security - some kind > > > > > > > > of nice > > > > > > > > to have security) > > > > > > > > The goal is: if the user does not have rights to see some parts > > > > > > > > of the > > > > > > > > screens, it won't be displayed. If the user is not able to > > > > > > > > modify the > > > > > > > > data, he will see the readonly components. > > > > > > > > Anyway, server side security is also checking if the user is > > > > > > > > able to > > > > > > > > execute methods or if he is able to modify/see data he are > > > > > > > > reguesting. > > > > > > > > > This coupled approached gives you completly secured solution > > > > > > > > for GWT > > > > > > > > applications. > > > > > > > > > Peter > > > > > > > > > On 11. Aug, 16:07 h., Stefan Bachert <[email protected]> > > > > > > > > wrote: > > > > > > > > > > Hi Peter, > > > > > > > > > > I had just a glance at acris. > > > > > > > > > Acris is talking about a client side part. > > > > > > > > > > No mechanism which depends on client side code could be > > > > > > > > > secure! > > > > > > > > > > So I would suspect acris to be a misconsception. > > > > > > > > > At the moment I do not spend time to exactly find out what > > > > > > > > > is wrong > > > > > > > > > with acris. > > > > > > > > > > Stefan Bacherthttp://gwtworld.de > > > > > > > > > > On 11 Aug., 15:47, Peter Simun <[email protected]> wrote: > > > > > > > > > > > Luis, why do you think that there is no security there? > > > > > > > > > > > Please, read the article again and carefully, or go on the > > > > > > > > > > wiki pages:http://code.google.com/p/acris/wiki/Security > > > > > > > > > > > Peter > > > > > > > > > > > On 11. Aug, 14:04 h., Luis Daniel Mesa Velasquez > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > I don't see anything about the encryption used in the RPC > > > > > > > > > > > call to the > > > > > > > > > > > userservice... so it's just a fancy 3rd party RPC call, > > > > > > > > > > > no security > > > > > > > > > > > there... > > > > > > > > > > > > On Aug 10, 3:20 am, Peter Simun <[email protected]> wrote: > > ... > > ďalšie informácie >> -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
