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 <[email protected]> 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 > [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. > > > -- 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.
