GWT and Web Security

[asif...@gmail.com]

Hi ,

I am navigating my way through GWT  - and hit a major conceptual roadblock with security issues.

If i want to implement security ( authentication and authorization) in my GWT webapp( doesn't include app-engine) what is conceptually the best Framework ( for example shiro , acegi etc) to use.

I tried shiro but the shiro concept of using a separate loginUrl and successUrl doesnot go down well with my understanding of GWT single page application.

Also I want to use widget level authorization - depending on the authorization of logged in user , widgets are made visible or invisible etc - so looking for a very fine grained authorization framework.

Which is the best way for me to look? Any samples/tutorials will be highly appreciated.

Regards

[Juan Pablo Gardella]

Hello, 

I think currently there are not frameworks that do what you want. At UI you need to write code to enable/disable components. Check this old thread: https://groups.google.com/forum/#!msg/google-web-toolkit/asDc2-JFy-A/z9izD9p_RoIJ

2013/7/25 <asif...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Thomas Broyer]

On Friday, July 26, 2013 12:39:53 AM UTC+2, asif...@gmail.com wrote:

Hi ,

I am navigating my way through GWT  - and hit a major conceptual roadblock with security issues.

If i want to implement security ( authentication and authorization) in my GWT webapp( doesn't include app-engine) what is conceptually the best Framework ( for example shiro , acegi etc) to use.

I only know of one: https://code.google.com/p/acris/wiki/Security and I never used it so I can't comment on it.

 

I tried shiro but the shiro concept of using a separate loginUrl and successUrl doesnot go down well with my understanding of GWT single page application.

From experience, managing login in the app without reload makes it much harder and quickly become a PITA. Redirecting to a login page that redirects back to the app (causing a reload, i.e. start fresh) is much easier to handle, so unless you really need "login without reload" (e.g. user starts action but can only complete it if he's logged in, and you don't want him to lose its data by redirecting it and reloading the app fresh after authentication; but localStorage can help here, or even a cookie for older browsers), don't use it.

I then use a dynamic host page to pass data about the user to the app (username, roles, etc.)

On the server-side, use an AOP approach, with annotations on your services and service methods (use true AOP with RPC, possibly through Guice; use a ServiceLayerDecorator for RequestFactory). Return a 403 Forbidden when the action is not allowed for the current user (or use a custom exception in RPC, if you can), a 401 Unauthorized (without WWW-Authenticate header, or with a "fake" challenge if you don't want to violate the "401 mandates WWW-Authenticate" rule of HTTP) when the user is not logged in; and catch those on the client-side (preferably in a central place; RequestFactory's RequestTransport is great for that, use an RpcRequestBuilder or an AsyncCallback super-class for RPC).

You can see an example in my Maven archetype (only covers authentication, not authorization; I need to make my authorization ServiceLayerDecorator public at some point, already duplicated it in a couple projects): https://github.com/tbroyer/gwt-maven-archetypes/tree/master/guice-rf-activities/src/main/resources/archetype-resources/ 

 

Also I want to use widget level authorization - depending on the authorization of logged in user , widgets are made visible or invisible etc - so looking for a very fine grained authorization framework.

My approach so far was purely programmatic (equivalent to isUserInRole from servlets, but on client-side). With good accessors, you can even use it directly as visible="{roles.abc}" in UiBinder (at the expense of building the widget even if the user doesn't use it, so use sparingly). Not very productive, sometimes cumbersome, but you have complete control.

An alternative (feel free to mix and match different approaches) is to use deferred binding to have one permutation per "role", and use a <property-provider> to select the appropriate permutation at runtime, depending on some data put on the host page by the server (dynamic host page once again).

[dhoffer]

Thanks Thomas that's good information.  I too have found that best practices for securing GWT applications difficult to come by.  There are just bits and pieces on the web...and if you get the Spring Security book, for example as I did, they don't even mention GWT.  What's needed are some comprehensive examples showing some best practices around security in the context of GWT.

As you say...it would be great if you could make your ServiceLayerDecorator public too that would really help.  You recommend AOP and possibly Guice, what do you use to implement the actual security, Spring/Acegi?  What about OpenID support/etc?  I know Spring Security can use an AOP approach...I didn't know that Guice could do that.  If you could elaborate on this it would be super helpful.

(Btw, I'm using Guice for IoC but didn't know it could help with security.)

[asif...@gmail.com]

Thanks Juan for your response and the reference.

[asif...@gmail.com]

Thanks Thomas, that's a lot of useful information - although I have to admit I have to work my way through it, since i am not very familiar with the AOP/ServiceLayerDecorator concept  through Guice.

I am using the straightforward Service/AsyncService on client side and ServiceImpl on server side. I will probably walk through your source code for a better understanding.

Will probably follow the deferred binding concept in the widget authorization part.

Thanks and Regards,
Asif

[Thomas Broyer]

On Friday, July 26, 2013 7:38:39 PM UTC+2, dhoffer wrote:

Thanks Thomas that's good information.  I too have found that best practices for securing GWT applications difficult to come by.  There are just bits and pieces on the web...and if you get the Spring Security book, for example as I did, they don't even mention GWT.  What's needed are some comprehensive examples showing some best practices around security in the context of GWT.

As you say...it would be great if you could make your ServiceLayerDecorator public too that would really help.

Will do. Don't hesitate to bug me about it if I forget.

 

You recommend AOP and possibly Guice, what do you use to implement the actual security, Spring/Acegi?

Manual checks.

I have kind of an aversion for everything Spring, and haven't had the need for anything more complex than checking user roles at the method level.

See https://code.google.com/p/google-guice/wiki/AOP; in the WeekendBlocker example, replace the date-based check with looking at annotations on the invoked method or its enclosing class and checking against the current user and/or his roles (which you can get from the HttpRequest, that Guice can inject into your interceptor), and throw a SecurityException. I like to use javax.annotation.security annotations on my methods to declare the required access rights.

What about OpenID support/etc?

This is a different issue.

I haven't had to deal with that case, but I like to simply defer to the servlet container (JavaEE defines JASPI and similar APIs for portable login modules, but each servlet container has its own pluggable API) and use getRemoteUser, getUserPrincipal and isUserInRole only in the webapp.

This approach gives you flexibility in the deployment: some customers will use LDAP or ActiveDirectory, others will use a SQL DB, or flat files; or defer to a front server (Apache or NGinx); some will use a web SSO (JASIG CAS, Atlassian Crowd, etc.) or Windows auth (NTLM, Kerberos, SPNEGO), or SSL client certificates; some will want 2factor auth on their web forms, etc. That's for authentication alone; authorizations (mapping users to roles) will come from LDAP/AD, SQL DBs or flat files.

We rely on JAAS and provide modules to "authenticate from flat file", "get roles from flat files" and LDAP/AD (authn with possibly authz) that you can mix and match to your needs (covers 95% use cases), and leave it to the customer to configure their own JAAS modules for other cases: using standard APIs makes it more likely that such a module already exists for their auth solution. That's for form-based auth mostly, we rely on Jetty's own Authenticator API to replace the auth mechanism, but there are means to use JASPI in Jetty if the customer has such a module already.

[David Hoffer]

That's good information.  I had no idea Guice supported AOP, I've been using Guice for IoC and Spring Security for security functionality.  (I too have an aversion to Spring for IoC but I don't have a preference yet for security).

However I'd have to see an example to really understand the details of what your doing.  I think I 'get' the method level security via AOP but what about all the other things Spring Security brings to the table, multiple/duplicate logins, session timeouts, etc.

In my case we control the full deployed stack so I don't have to leave anything custom for the user.  My requirements are OpenId and Tomcat.  I'd prefer to have security manged inside the war I deploy...as although we control the full stack including the container...I don't personally control the container so some solution that gets deployed with the war is preferable if possible/practical (although if there's a Tomcat OpenId container authentication module that sounds like a good solution too).

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/IopVSRRqt1s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

[Thomas Broyer]

On Friday, July 26, 2013 8:30:29 PM UTC+2, Thomas Broyer wrote:

On Friday, July 26, 2013 7:38:39 PM UTC+2, dhoffer wrote:

Thanks Thomas that's good information.  I too have found that best practices for securing GWT applications difficult to come by.  There are just bits and pieces on the web...and if you get the Spring Security book, for example as I did, they don't even mention GWT.  What's needed are some comprehensive examples showing some best practices around security in the context of GWT.

As you say...it would be great if you could make your ServiceLayerDecorator public too that would really help.

Will do. Don't hesitate to bug me about it if I forget.

Done: https://gist.github.com/tbroyer/6091533

[salk31]

I have kind of an aversion for everything Spring, and haven't had the need for anything more complex than checking user roles at the method level.

 We are using Spring pretty heavily and it does seem to add a huge layer of complexity and I'm not quite sure to what benefit (apart from DI).

For CAS auth integration I do seem to spend a lot of time trying to get Spring to let me get at what I need or work around the Spring "convenience" code.

@PreAuthorize on getters and setters has been pretty good though. I was reluctant to introduce an expression language but we have had no real problems.

Finally a plug for my project https://github.com/salk31/gwt-rf-queue if you are using RF and want the app to be able to carry on after an auth failure...

Cheers

Sam

[Jens]

I am wondering if there is anything standards based a servlet container can provide when I only have a static set of permissions and customers can define their own roles by combining these permissions. I pretty much always need something like @PermissionRequired instead of @RolesAllowed in my apps because roles are not static. And in addition to method/class level permissions which only regulate what a user can do in the app I also need to authorize the data a user can see.

My workflow is

1.) UI is build based on a user account's assigned roles and their containing access permissions

2.) User account selects menu item (= access permission) in UI. 

3.) App figures out which of the assigned roles of the account contain the access permission for the selected menu item.

4.) App figures out which data the user account can see based on the active roles calculated in 3.) and filters the data accordingly before sending it to the client UI. 

To make 4.) possible a customer can assign "accessible data" to each role of a given user account. So "accessible data" can vary between user accounts for the same role.

If I am not totally wrong I think JAAS can't help me here and I did not find a lot of information about JASPI but maybe my googling is just bad in this case. Currently the above is a custom implementation but I am wondering if its a "lets re-invent the wheel" thing.

-- J.

[salk31]

We couldn't find anything standard and went with spring security after looking at Shiro. In Shiro and the standard stuff it seems,at best, tough to do basic stuff like "administrators and owners can see a user's email address".

Our domain has a dozen roles and and groups (with different membership role to those groups) so @PreAuthorize turned out not to be overkill.

It would be great to have something from JEE and ideally without an expression language.

[Thomas Broyer]

On Saturday, July 27, 2013 3:43:18 PM UTC+2, Jens wrote:

I am wondering if there is anything standards based a servlet container can provide when I only have a static set of permissions and customers can define their own roles by combining these permissions. I pretty much always need something like @PermissionRequired instead of @RolesAllowed in my apps because roles are not static. And in addition to method/class level permissions which only regulate what a user can do in the app I also need to authorize the data a user can see.

IIRC, JavaEE's perspective is that those "permissions" are "roles" in your app, and you're given the ability to map given "roles" to your app's own roles. The expectation is that this mapping is done in the admin console of your JavaEE application server, but you can also do it in the web.xml (e.g. a jetty/web-override.xml or similar in other servlet containers).

My workflow is

1.) UI is build based on a user account's assigned roles and their containing access permissions

2.) User account selects menu item (= access permission) in UI. 

3.) App figures out which of the assigned roles of the account contain the access permission for the selected menu item.

4.) App figures out which data the user account can see based on the active roles calculated in 3.) and filters the data accordingly before sending it to the client UI. 

To make 4.) possible a customer can assign "accessible data" to each role of a given user account. So "accessible data" can vary between user accounts for the same role.

If I am not totally wrong I think JAAS can't help me here and I did not find a lot of information about JASPI but maybe my googling is just bad in this case. Currently the above is a custom implementation but I am wondering if its a "lets re-invent the wheel" thing.

JAAS is about authenticating the user (given his credentials) and obtaining his roles. JASPI (aka JASPIC) is about how you obtain the credentials.

None of them are about using the user Principal's roles. javax.annotation.security annotations and getUserPrincipal and isUserInRole are part of the answer.