2

We have a three tier architecture and we are using spring remoting in combination with hessian. Currently we have a client app and the business app is running on two different tomcats.

 Tomcat 1           Tomcat 2
----------        ------------
| client |   ->   | business |
----------        ------------
                   exposing services for clients

But we came across a security problem. Our exposed services (business app) requires a logged in user with special rights, for example ROLE_SUPERVISOR. The client application has a login form and the credential validation is done by the business app (the client app has no database connection). This means that the user is only logged in on the client application, the business app knows nothing about it (and this is maybe the main problem).

We thought it is possible with spring security remoting to send all needed information from the client to the business app (i.e. the authentication object). But unfortunately this can not be done. So, we have to find another solution.

  • One solution could be to send the authentication object along with every request. But this may have another security issue. The authentication object which is sent by the client, can be faked by an attacker. In this case we have to check the users' credential for every request and load his roles (granted authorities) to be sure, that he is authorized.

  • The second solution is that both apps are aware of the logged in users, which means, when a user logged in with the client app, he is also logged in in the business app. But, nevertheless, the user (or authorization) object must be sent with every request.

Maybe we are missing something. Isn't there a better / easier way to do this with spring security and spring remoting. A three tier architecture isn't unusual and there must be a way to secure the exposed services.

Update spring remoting with hessian: client side configuration (java config)

@Bean
public HessianProxyFactoryBean xyService() {
    HessianProxyFactoryBean xyService = new HessianProxyFactoryBean();
    xyService.setServiceUrl(remotingUrl + remotingContextPath + "/XyService");
    xyService.setServiceInterface(XyService.class);

    return xyService;
}

business side:

@Bean(name = "/XyService")
public HessianServiceExporter xyService() {
    HessianServiceExporter hessianServiceExporter = new HessianServiceExporter();
    hessianServiceExporter.setServiceInterface(XyService.class);
    hessianServiceExporter.setService(xyServiceImpl);
    return hessianServiceExporter;
}

I appreciate your help! Thanks, Daniel

Daniel
  • 835
  • 1
  • 7
  • 18
  • What exactly "cannot be done", and why? – chrylis -cautiouslyoptimistic- May 12 '14 at 14:50
  • It is not possible to "prepare" the (hessian) remote call to send an authentication object (or something similar) along with the original request. There are only two options with spring security remoting: 1. a http basic authentication and 2. sending an authentication object using rmi. Both is not an option. – Daniel May 12 '14 at 15:44
  • How are you performing that remote call? Hessian's essentially an encoding, and it's not clear why you can't use `HttpInvoker`. – chrylis -cautiouslyoptimistic- May 12 '14 at 15:48
  • I could use HttpInvoker, but I can't see why this should help, because with spring security remoting only http BASIC authentication can be done. I updated my question and added my configuration. – Daniel May 12 '14 at 16:45
  • As you already noticed the only possibility is to use Spring Security Remoting and that only works with basic authentication as Hessian is just HTTP but it simply encodes the request. If you want something else you would have to implement it yourself to serialize/deserialze the `Authentication` object, but why couldn't you use the simply basic authentication (drawback is that you would have to authenticate once to the backend). – M. Deinum May 12 '14 at 18:21
  • The problem is, that a basic authentication is a username / password authentication mechanism. Spring security provides several authentication mechanisms, not only username / password. And we are using *X.509 and username / password*. X.509 has no username and password, which means, we can't use basic authentication to authenticate to the backend. – Daniel May 12 '14 at 20:24

0 Answers0