Hi, I'm no expert in this area, so take this with a pinch of salt (interested to hear what others are doing)...
You have two problems, authentication and authorisation. There are various options available for authentication (like http basic, form login, ...) but these may be limited or complicated depending on how your client and server are packaged and deployed. For example, if your client and server are packaged into a single war, then configuring authentication can be relatively straightforward and can be done solely via spring security, as the client and server will be within the same web application, which means once a user is authenticated to access the client pages, they'll also be authenticated to make calls to your web service, and browsers will automatically take care of adding appropriate JSESSIONID cookies or Authorization headers to your AJAX requests. If your client and server are packaged and deployed separately (but still within the same domain name), then authentication can get a bit more complicated, although not insurmountable. The challenge here is getting the user authenticated against the web service, and getting that authentication information into your client-side code so it can make authenticated AJAX requests. If you give me a bit more information about how client and server are packaged and deployed, I might be able to say more about the options. Generally, if client and server are packaged and deployed separately, then you may want to go for a pre-authentication approach in your spring security config, and handle actual authentication in a web layer (e.g., Apache config) before you get to the web applications. The other problem is authorisation. The main question here is which part of your application (client, service) is responsible for what authorisation decisions? E.g., you could push all authorisation decisions down to the service, and leave the client completely open (so the client-side code will need to be able to handle unauthorised responses from the service), or you could go to the opposite extreme and handle authorisation decisions in the client, in which case you will want to limit access to different parts of the client application (but this is probably not an option as you won't want to leave your service open to hacking), or some combination of the two. Where the decisions are made will affect how you configure authorisation via spring security. E.g., if all authorisation decisions are implemented at the service, then you may be able to do with just a bunch of intercept-url directives in your service's spring security config, restricting access to different service calls by URL path, http method and user role. Anyway, like I said, I'm not an expert, so caveat emptor, but hope that helps. Cheers Alistair -- Alistair Miles Head of Epidemiological Informatics Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Web: http://purl.org/net/aliman Email: [email protected] Tel: +44 (0)1865 287669 On Jan 6, 2:04 pm, julio <[email protected]> wrote: > Hi, > > I need to use Spring Security 3 in my application which is composed by > Spring 3 for the server side and GWT 2.1 for the client side. > > Client side and server side are totally ""decoupled"", I mean they > don't belong to the same project in the eclipse workspace (server side > is managed by maven and client side uses prebuilt ant files) and till > now they "communicate" each other using Rest/Json. > > Googling I found some tutorials and tips about integration with Spring > Security but all of them suppose that "client side" knows spring- > server-side classes, and so using @Controller @Autowired etc under the > gwt.server package. In my case this is not possible (or not clean to > do). > > Is there a way to use Spring Security and keeping the code > "decoupled"? Maybe for every (rest) client request I should use "basic > authentication"? And what about a normal login page authentication? > > Thanks -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
