Best practices for security with GWT RPC

[canis.majoriss]

Hi All,

We are planning to use GWT RPC as a frontend for a rather large
project in terms of number of different user profiles, number of
different logical tabs/windows where user can access only those
functionalities for which he has permissions. On client side specific,
let's say, button or window will not be rendered if user does not have
priviledges, while on the server side services will be declaratively
secured and even if user somehow managed to call service for which he
does not have access rights, access will be denied. We are using
pretty basic security model: permission, role, user, where at UI all
permissions for given user (via his roles) will be pulled and then
enforced (UI developer will statically bind specific permission to
specific UI action).

Same specific funtionality (button) may be logically present on
multiple locations on GUI, and client side enforcement would have to
take that into the account.

Questions where the help of the community would be appreciated are:

1) what are the best practice when it comes to client-side RPC
(declarative?) security enforcement?

2) should we, say, for every widget (button etc) override isVisible()
method and then check (assuming here that GWT runtime will call
JavaScript equivalent of isVisible() Java method at render time from
within JavaScript runtime) if user has permission to see given
component?

3) should we cache user's permissions in some kind of JavaScript
cache, or caching it on server-side and then make a call from
JavaScript's to server to see of specific component/button should be
rendered based on user's priviledges? If server side approach is
preferred, GWT RPC will not have performance problems?

Thanks in advance on any tips you may have.

[Juan Pablo Gardella]

+1

2011/3/5 canis.majoriss <canis.m...@hotmail.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Marius Grama]

I am trying to find a similar solution for the same problem.

I've stumbled upon a framework which can be a solution for this problem, but i didn't got a chance to test it  :

http://code.google.com/p/acris/wiki/SecurityClient

[Marius Grama]

Some talk about acris is done on this thread :

https://groups.google.com/forum/#!searchin/google-web-toolkit/client$20side$20security/google-web-toolkit/X0CvuHCWv-c/YWXOiT3EBqoJ

[Jens]

Well we don't keep a cache of permissions/roles on the client. In our app we always have to load data from the server when a user switches between places. So when doing this server request we also ask the server to check the permissions that are relevant for the UI of that current place. All these permissions are defined as enums (one per place) and placed in the shared package so we can use these enums also on server side to secure our server methods.

A typical activity thats starts and loads its data would do (using Command pattern):

this.server.execute(

  new BatchCommand(

    new CheckPermissionsCommand(PlaceAPermissions.CREATE, PlaceAPermissions.DELETE),

    new LoadDataForThisActivityCommand()

  )

)

and in its onSuccess method we are setting the evaluated permissions to the view like:

boolean[] evaluatedPermissions = commandResult.getPermissions();

this.view.secure(evaluatedPermissions[0], ...);

which basically shows/hides all relevant UI elements and also secures view methods like setCreateButtonEnabled(boolean isEnabled) to respect the permissions.

During the server request everything relevant is disabled by default and the actually UI is hidden (a loading overlay will be shown).

So far it works great for us. But of course this does not enforce anything. The developer has to implement the UI "security" on its own.

-- J.

[brad]

First I would just say that it isn't really security on the client side. It is a purely aesthetic issue. You have to assume that the client side can see anything they want, unless you are conditionally loading UI code from the server side. The latter isn't terribly performant.

So what you are really saying is that you want some sort of preferences cache on the client side. There are a number of ways to do that, but since bit shifting is not very good in javascript, I'd probably skip bit flags and use a boolean array.