Mike, thanks a lot. Your idea is clear. 2009/1/16 mikedshaf...@gmail.com <mikedshaf...@gmail.com>
> > 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" <itmo....@gmail.com> 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
