Role based Security in GWT: how to implement ?

[zixzigma]

Hello everyone,

I have some questions regarding implementing security in GWT.

It's a typical use case:
let's say in your app, users can have different roles,
and you want to show only the relevant part of the UI, based on their
role.

and I am talking about more than 3 roles.
eg:(Customer, BranchManager, Teller, CEO, System Admin)
(after all GWT is for larger apps, right ? )

on the back-end, i am planning to use Spring, and i'm going to use
Spring Security,
for authentication, fine-grained authorization, (method level, ACL),
it is a very mature framework and annotation based.

however, when it comes to the front-end UI, I don't know what is the
recommended practice to incorporate role-based security in MVP. (i
don't want the security checks get scattered across all methods on the
client, bloated code, if statements everywhere, security is a cross-
cutting concern, right? should i put it in the Activity/Presenter ?)

I see GWT 2.1 release addresses security concerns, for cross-site
scripting, and introducing SafeHtml.
but nothing related to authorization.

I would appreciate your insights and any feedback from google team,
perhaps a tutorial addressing this aspect of application security is
really needed !

is it possible for GWT team to introduce annotation-based support for
addressing security ?
does it make sense at all, or i'm missing something.

what have been your experiences in implementing security in GWT ?

Thank You

[Stefan Bachert]

Hi zixzigma,

doing security in the client would be wrong.
Remember you are doing client-server with GWT (not fatclient as
classical web technology does)
The client should ony receive data which are allowed for the current
user role. The client is never ever a trusted component!
So in the end any client based security concept (basing on annotation
or what else) is just a misconception.

The server is the only place where security can apply.
But GWT is mainly a client side topic.
Authentication based security or roles based security will never be a
GWT (client) topic

Stefan Bachert
http://gwtworld.de

[Stephen Haberman]

> The server is the only place where security can apply.

Very much agreed.

> But GWT is mainly a client side topic. Authentication based security
> or roles based security will never be a GWT (client) topic

Perhaps pre-2.1, yes, but the new RequestFactory, given it facilitates
client<->server data access, with the goal of ORM-like "minimal/no
boilerplate" serialization code, will have to deal with authentication
based security sooner or later.

- Stephen

[Rodrigue]

Hi Zixzigma,

I'm facing exactly the same problem like you with the difference, that
the solution you found doesn't work by me. That is why, I would like
to know if you you call the methods #refresh() or #flush() after you
added the new element to the DataProvider.

Thanks for your answer.
Rodrigue

[Jack]

The only thing we do is some cross-site scripting prevention and
hiding user interface components if a user does not have the
permission for that component. So for example we only show the menu
items a user in a given role can access. Other menu items wont be
added to the menu widget. This is done in our presenters. Each time a
presenter gets active it asks the server for the permissions the
current user have.

But you can never trust the client and we have to make sure that a
user with a given role will get an exception if he asks the server for
information he has no permission for because an attacker can ask for
such information even if he does not have the corresponding menu item
in the client UI. So each time we got a server request, the server
retrieves the user account with its assigned roles and permissions and
checks them against a set of server-side defined permissions that are
required to do the request. If they don't match we throw an exception.

On 30 Okt., 10:35, zixzigma <zixzi...@gmail.com> wrote:

[zixzigma]

Thank you for your feedback.
Yes, i was very worried about the security on client-side.
However, as Jack pointed out,
what if you want to show certain features to certain users (based on
their role).
for example, if a user has admin privileges, show "DELETE"and "UPDATE"
button on the panel.
or if you have a StackPanel, you want to show the parts relevant to
user's role/access level.
can also be applied to Tabs, Trees, etc.

when the request gets to the server, server can decide whether to
perform an operation or not, based on the user access privileges. and
rightly so, i agree.
however when it comes to showing relevant widgets on the client based
on user's access level, i dont think there is anything server can do
about it.

this is what im thinking in pseudo code:

if(user.canEdit() && user.canDelete())
mainPanel.add(deleteButton);
mainPanel.add(editButton);

or

if(user.isClerk)
mainPanel.add(clerkWorkspace)
else if (user.isBranchManager())
mainPanel.add(branchManagerWorkspace)


am i wrong in my apoproach ?
how do you handle such scenarios based on your experience ?

thank you for your insights.

[Jack]

Yeah your pseudo code is pretty much all you can do. But its not
really securing the client side.. its more like displaying a clean
user interface where a user dont see UI elements he actually cant use
because of some missing permissions. An attacker will always have all
UI elements.

Our UserRole object just holds a list of unique Strings, one for each
permission the user role is allowed to do. When a presenter gets
active it sends an array of permissions that are needed by the
persenters display to secure this display to the server. The server
then checks this array against the logged in user account and its
roles and returns a boolean array with true, false for each permission
it has checked (in the same order).
Then we call display.secure(checkedPermissions[1],
checkedPermissions[2], ...) and the display hides/adds/removes UI
elements. So each Display that needs to be secured has a secure
method, e.g. secure(boolean hasEditPermission, boolean
hasDeletePermission, boolean hasCreatePermission). The Presenter then
asks the server to check edit, delete and create permissions for a
given user/role so that it can call the secure method with the correct
values. If a display is more complex, we have much more parameters in
our secure method.

[zixzigma]

Jack,
Thank you very much for your thorough response.
Sounds like a great approach.


Thank You !

[lammert]

Also have a look at this topic at the Spring forums on which I've
posted a possible (temporary) solution to use role based security for
the RequestFactory: http://forum.springsource.org/showthread.php?t=95318

It also applies when not using Spring.