Of course it could be posible but not with this applications architecture. Because to verify user on server we should pass some user identifier from client which initially have to send to client in case of correct login and password. Server couldnt have any access to client application. Client and server could be located on a different servers, for example client: https://client.web.com server: https://service.server.com:8443/service1
2009/1/19 logicpeters <[email protected]> > > Why not just use request.getRemoteUser() or have the authentication > module put the user in the session (as a parameter, or in a cookie) > instead of passing it in the RPC call? > > > > On Jan 16, 8:18 am, "[email protected]" <[email protected]> > wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
