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).
On Fri, Jul 26, 2013 at 12:30 PM, Thomas Broyer <t.broyer@gmail.com> 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.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 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-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@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.
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-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@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.
No comments:
Post a Comment