Cool - sounds good!
On Mon, May 10, 2010 at 1:05 PM, Kalle Korhonen <[email protected]> wrote: > On Mon, May 10, 2010 at 12:41 PM, Les Hazlewood <[email protected]> wrote: >>>> 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? > > Right, that's how I figured it, just wanted you to confirm there > wasn't anything I'm blatantly missing, thanks. The security check for > the remoting call is still done, just not in the highest layer of the > application. To prevent misuse, you could add IP or other additional > security filters, I think that's clear. I'll remove the authc line, > add some documentation for running the example and close this. > > Kalle >
