Spring Rich and Security problem

[adamarmistead]

Hi I have a spring rich client application and I'm having an issue when logging in where my rich client has the proper Authentication object but my server it logged in to has an AnonymousAuthenticationToken not the full Authentication object the client has. I put a post on the Spring Security forums in case it is a security issue but i suppose it could be a spring rich issue as well. Can anyone help me out?

heres a link to the post on the spring security forum:

http://forum.springsource.org/showthread.php?t=85856

[adamarmistead]

hrm, turns out I was using the standard springframework remoting classes instead of the richclient ones when accessing my remote services.

changing:
class="org.springframework.remoting.httpinvoker.Ht tpInvokerProxyFactoryBean"

to

class="org.springframework.richclient.security.rem oting.BasicAuthHttpInvokerProxyFactoryBean"

solved the problem and now my Authentication object matches on the client and server.

[LievenDoclo]

I wrote an article about this: http://www.insaneprogramming.be/?p=128

[adamarmistead]

So, just to make sure I understand your article. You are suggesting I use the HttpInvokerProxyFactoryBean and set its remoteInvocationFactory to an instance of the ContextPropagatingRemoteInvocationFactory like this:

<bean id="myService"
        class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
  <property name="serviceUrl" value="https://${remote.service.path}/MyService.html"/>
  <property name="serviceInterface" value="org.my.app.service.MyService"/>
  <property name="remoteInvocationFactory" ref="ctxPropFactory"/>
  </bean>

<bean id="ctxPropFactory"
  class="org.springframework.security.remoting.rmi.ContextPropagatingRemoteInvocationFactory"/>

in order to remove the overhead of returning the Authentication from the server on each call, as my client already has it. Unless I've misunderstood something that makes sense to me.

I am confused though when you mention this as an alternative to using a DelegatingFilterProxy. I have one of those set up on my server, but I'm not clear on the impact this has on my switching over to using your suggested setup. It seems like your saying I no longer need this on my server if all my calls are routed through spring httpInvokers configured with a ContextPropagatingRemoteInvocationFactory as I will then just be pushing my Authentication token I acquired from my remoteAuthenticationManager to the server on each call. But if my service methods could be called in another way, say directly on the server through a webapp interface or possible something else I haven't thought of yet then I still need to keep my DelegatingFilterProxy. Does that sound even close to correct?

[LievenDoclo]

If you use the context propagation, you don't need the basic http authentication on the server side, as it will be overriden by the authentication in the remote call anyway: the filter sets the authentication on the call based on the http usename and pass, but the remote invocation overrides the previously set authentication. So you don't need to do every call using HTTP username and pass.

So if you know that every call to your HTTP invoker proxy will be done with context propagation, you don't need to use the DelegatingFilter (you can keep using it though). But if you don't know, the safe bet is to keep the DelegatingFilterProxy. But if you use context propagation AND the http authentication, you'll need to provide a way so that non-http authenticated calls (but which contain a embedded security context) still get through. In other words, you'll have to enable anonymous access.

[winterman]

Working with spring rich client is such a pain, I have been racking my brain to develop an application based on spring rich client and security. I am now stuck with authentication of client. Is there any tutorial dealing specifically about security issues? I went through the pages you have suggested but there isn’t anything related to the security issues.

[julio.arguello]

In fact, lack of documentation is a pity, however you will realize this framework makes things easier.

This site included this kind of information:
http://spring-rich-c.sourceforge.net/1.0.0/index.html

Security was documented at
http://opensource.atlassian.com/conf...y/RCP/Security however it seems to be down

Take a look to docbks sources at SVN, there is a chapter dedicated to security management. You can also query Google cache:
http://webcache.googleusercontent.co...&gl=es&strip=1

At last but not least, there is an extension project, named Bluebell, that makes things better, easier and faster.
http://saber.b2b2000.com/display/BLUE/Bluebell

[LievenDoclo]

In the Valkyrie prototype, I've greatly simplified the security system. In essence, you can set authorities on objects and if an authentication is found in the context (for example through the LoginCommand), the security system springs into action and handles security transparantly.
The only thing you now need to do is define the authorities needed for a command or anything else that is a subclass of AuthorityConfigurable and add a login command that sets an Authentication in the SecurityContext.