>> I'll take a peek at the authentication issue. The idea was that you >> would authenticate via the webapp first (JSP) and then launch the >> webstart app. So, the /remoting/** = authc, ... line was added as an >> example of a secure app that can only be used if already >> authenticated. Does this make sense? > > Right, you can only launch the webstart app if you are logged in. But > the webstart app doesn't share the same session, or specifically, > doesn't carry the same session cookie in the http remote invocation > headers as the user's browser, so the request never reaches the > remoting servlet. Either there was some additional mechanism to deal > with that but it was lost along the way or I just don't understand how > this configuration could work. The SecureRemoteInvocationExecutor > itself does the expected thing, creating the subject from the session > id argument if the request is allowed to progress that far.
Ah, I see now. I think having /remoting/** = authc doesn't make sense then. I think it probably makes more sense that a client should be able to execute a remote invocation at any point in the Subject's interaction with the system and rely on things like annotations or code checks to assert a user must be authenticated for a certain method. Then, if any filter would be applied to /remoting/** it would probably more likely be something like an SSL filter or IP filter to ensure the request is either secure, or comes from a certain IP or IP range or something like that. What do you think? - Les
