My organization is moving in a new architectural direction. We are abandoning the old JSP/Struts/ORM model we used in the past in favor of a GWT rich client, some public REST services, and some secure web services (of some flavor). I am the architect for our organization, and I need some ideas for how best to address security in this new "rich client" world. For instance, we could completely discard the notion of sessions on the server. Make the server completely stateless, if you will. Have the GWT client cache credentials and state and what-have-you. In this world, every call to a "protected" service would require passing the user credentials, and the server would have to validate them on every call. This approach has the added advantage (perhaps?) of being reusable in the web services side because downstream users would again just have to pass credentials with every call to a protected service. Thoughts? Are others out there doing something like this? I'm using Spring extensively on the server side, but I can't find a good way to implement security with, say, Acegi, because they tend to be based on server-side sessions. Any feedback or ideas would be much appreciated. Respectfully, Charles

Hi, Its a late reply but since we are using the same architecture as you want to use. We are using swing client and our server is almost stateless. In order to validate the User we assign a unique session id to each user on login. This session id along with user IP address is cached on server side (u can use a singleton object or a rmi object in case of cluster) and then each call from the client is validated from that cached object and once validating the user the call then route to authority management system for further security verifications.