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. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
