GWT security

[Peter Simun]

Hi all,

I just wanted to share with you the article about security in GWT
application.
http://java.dzone.com/articles/securing-gwt-client-acris

Serious security implementation is something that was missing almost
to each GWT developer. I saw many topics here in the forum about the
security, so maybe it will helps you to implement security in a
correct way.

Peter

[Luis Daniel Mesa Velasquez]

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 <si...@seges.sk> wrote:
> Hi all,
>
> I just wanted to share with you the article about security in GWT

> application.http://java.dzone.com/articles/securing-gwt-client-acris

[cokol]

there is no reason to secure it, since decryption logic would be in
javascript - thus public accessible, so better to use https ;)

On 11 Aug., 14:04, Luis Daniel Mesa Velasquez

[Ladislav Gazo]

I don't think that security is just about encrypting RPC calls. And as
cokol said if encrypted RPC stream is the only concern it should go
through HTTPs. The purpose of acris-security is to integrate server
side security with GWT client, propagating authentication and
authorization "things" (like allowing a user to see or manipulate
certain kind of data),...

And yes, it is fancy ;) but not only RPC call ;)

On 11. Aug, 14:04 h., Luis Daniel Mesa Velasquez

[Peter Simun]

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
<luisdanielm...@gmail.com> wrote:

[Stefan Bachert]

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 Bachert
http://gwtworld.de

[Peter Simun]

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 <stefanbach...@yahoo.de> 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

[Ladislav Gazo]

This seems to me just a flame about what the word 'security' exactly
is :) acris-security is about bridging client and server, using
server's authentication and authorization methods to add another layer
for potencial "attacker" to skip (for common users what is not visible
or editable is also not going to be broken). If you don't secure
either you are opening another hole which could be used to break in.
In GWT there is currently no way known to me how to bridge it, if
there is we will welcome any constructive suggestions/contributions on
how to improve/integrate/provide better ways for end users to be
securely-comfortable with using GWT applications. It is clear to us
that there is no effort without mistakes/bugs so we are open to any
suggestions how to improve "security" as such both for developers and
users.

[Greg Dougherty]

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

[Peter Simun]

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 <dougherty.greg...@mayo.edu>
wrote:

[Ladislav Gazo]

Personally I would like to know proper name for it, if you would be so
kind and give us some proposals we will consider it as your
contribution to the process of making acris-(currently named)-security
better :) We initially thought that 'security' also covers
transferring server-side security restrictions to the client so the
user is also satisfied (hiding components, ability to login, have some
basic components available in GWT,...) but we might be mistaken about
the name...

And also please consider that acris-security (if you haven't been able
to find it somewhere in the documentation I will fill it in) is/is
trying/and would also provide ways how to transparently switch the
server side security implementation. Maybe there (or somewhere else)
is a possibility where we could cooperate, what would you say?

On 11. Aug, 23:31 h., Greg Dougherty <dougherty.greg...@mayo.edu>
wrote:

[cokol]

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.

[Peter Simun]

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

[cokol]

oh yeah, totally right , this what I mean by make security look good
to the user ;)

[Greg Dougherty]

"Personally I would like to know proper name for it"

I'd go for "Consistent UI design." Which, I admit, doesn't sound
nearly as sexy as "improved security." BUt that is what you're doing:
you're keeping the UI consistent with what the user is allowed to do.

Another way to put it is "don't tease the users." Don't let them
think they can edit data, when they can't.

Greg

[Greg Dougherty]

"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

[Peter Simun]

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 <dougherty.greg...@mayo.edu>

[Luis Daniel Mesa Velasquez]

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...

[mig]

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

> ...
>
> ďalšie informácie >>

[Greg Dougherty]

"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."

Simple:
1: User documentation on how to use the program is consistent.
Everyone sees the same menus, screens, screen layout, etc.
2: Easier tech support: "Go to the 'Edit User Data' screen". "Where
is it?" "It's on the right-most tab on your screen" "No, it's
not" .... vs.
"Go to the 'Edit User Data' screen". "Ok, it says I can't edit the
data." "You'll have to talk to <whoever's authorized to give out the
security credentials for that>".
3: Easier to keep users up to date. "Ok, last week, I could see the
panel, now I can't. Where the heck did they move it, and why?!?" vs.
"Oh, the panel says I don't have access. I guess I have to renew my
membership to use that."
4: Better user experience: Your way: "The documentation says you can
do <X> with this app, but I can't figure out how to do it. I hate
this program!"
My way: "Ah, I see I have to get approval before I'll be able to do
what I want to do." --> User is much less cranky. (Yes, I've BEEN
that user. And not being able to FIND what I want to do is FAR more
irritating than finding it easily, but being told I don't have
permission to do it.)

And no, it's NOT "security". Security is making sure the server is
set up so that no client program, no matter how malicious, can get a
hold of information it shouldn't have, or change information it
shouldn't change. Your program runs on the client side, so it's about
making the security rules obvious to the user.

Except, instead of making things obvious, you hide them. Bad UI, bad
design, bad idea.

Greg

[mig]

Greg, do you realize, that there are administration possibilities/
functionalities/menu items here on google groups too ? No ? It is
because you CAN'T SEE THEM, because you ARE NOT THE ADMIN. I don't
know, what kinds of applications you use, but I just can't possibly
imagine a bank application, where a guest user would see all the menu
items, that admins, brokers, managers and customers see while having
90% of 'em disabled.
And yes, it IS security, because besides the client functionality,
that hides client components according to roles, permission and stuff,
it also addresses the autorization issues regarding calling server
side service methods.

On 16. Aug, 20:34 h., Greg Dougherty <dougherty.greg...@mayo.edu>

> ...
>
> ďalšie informácie >>