The simplest thing I can comment is: that's about your only option. You've got various levels of security issues here, so I'm going to assume the simplest. You need the web client to be trusted by the GWT "server" (the server end of the GWT-RPC). Then you need the GWT server to be trusted by the application server. In most of our applications, we do server to server trust using Kerberos, service tickets and a whole bunch of authentication that is way beyond anything I want to write here. For GWT-RPC, we do a session id that contains the users Kerberos credentials ticket, which can be verified by a Spring inserted filter on our GWT RPC. We have done cookies in a SQL database, but today we've got code that takes the credentials and sends them to a cookie on the browser. That cookie is then visible to the server as it is included in the web request. We don't use SSL to harden our pipes, but we could and might. All of our users at this time are inside the firewall and we are therefore dealing with them via an LDAP (Microsoft Active Directory in our case).
All of this sounds like mumbo jumbo no doubt. To do "real" security like we're doing, we've had a couple of us working on this for a couple of years. We've also done less secure security (oxymoronic perhaps) where we create a special session key and store it in SQL. We then send it down to the client where it is cookied. Every request has the cookie and our server side then extracts the session and validates against the session table in SQL. Then using the same session id, we can determine the users' credentials that we've also stuck in another table. This has allowed us to do things like certain users can't insert records or whatever rule you employ. But our security auditors haven't historically loved this and that's what prompted us to develop the Kerberos/service ticket solution. Now we are working with WS-Security to truly secure our SOA services...it never ends... Later, Shaffer On Jan 16, 3:58 am, "Mikhail M" <[email protected]> wrote: > Need help! > > I have an architecture described below > > 1) Client application > 2) Server application > > Client and server applications hasn't dependencies and could be set on > different servers. > I have the same Object model using in both application. > > Client and server are using rpc to communicate. > > In server application I'm using Spring > (org.springframework.web.servlet.DispatcherServlet) > In client application - GWT > > It works perfect but it isn't secure. So now I need to add auth to my client > application. > Users could have different roles, that's why they could call only allowed > remote procedures. > Of course it should be checked on server side. > > I need some mechanism for detection users on server side. I could't find any > suitable > solution for my application architecture. I think should be any transparent > mechanism for my > architecture. > > Do you have any ideas? > > My idea is to add to every rpc call any parameter - session identifier. This > identifier > set to any user if auth was correct. This session id stored in data base for > example and > cleared after some times if user was inactive. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
