Hi Justin, The executor does not deny the ability to invoke a call itself - it merely ensures a Subject is associated with the incoming method invocation so that security checks could be called later.
Other parts of your application ensure that certain calls may succeed or not - for example, you might annotate a method as @RequiresRole or @RequiresUser, @RequiresAuthentication, etc. Or you could programmatically check by acquiring the currently executing subject (SecurityUtils.getSubject()) and execute role/permission/authentication checks against that. Perhaps the name of those should be called SubjectRemoteInvocationExecutor instead? Did the Secure name confuse you as to its purpose? (We try to make things intuitive whenever possible - if this isn't intuitive to end-users, perhaps we should rename it). Of course the Http Basic authentication approach and url filters will certainly work, but the remote executors should work just as well, with the understanding that they only set up Subject association, and don't perform checks themselves, leaving you to define those checks elsewhere. HTH, Les On Thu, May 28, 2009 at 4:48 PM, jtriley <[email protected]> wrote: > Hi Les, > > This is more related to login/authorization. I just want to ensure that > any app that connects to the server app for rmi is authenticated and > authorized to do so. > > I'll definitely give the svn versions of SecureRemoteInvocation* a try. > > Taking a step back and testing just the server side securing of the > remote services I can't seem to get the SecureRemoteInvocationExecutor > to deny a plain httpinvoker client access. I removed the > SecureRemoteInvocationFactory bean from the client so that it was > attempting pure unauthenticated calls to the server and it was still > succeeding. I must have something wrong in my configuration... > > However, adding this to jsecurity.filter.config gives an unauthorized > response when attempting to access rmi through httpinvoker which is what > you would expect: > > jsecurity.filter.mode = "http" (works for "jsecurity" too) > jsecurity.filter.config = """ > [filters] > authcBasic=org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter > authcBasic.applicationName = secured rmi server > > [urls] > /httpinvoker/** = authcBasic > """ > > I'm wondering if dropping the SecureRemoteInvocation* classes/beans and > using this plus a Remote Realm wouldn't do the trick? Just a thought... > > ~jtriley > > > Les Hazlewood-2 (via Nabble) wrote: > > > Hi Justin, > > > > The system property approach wasn't very clean and it has been modified > > significantly in subversion to look first at the Subject bound to the > > thread and only look at the system property as a last resort. You might > > want to look at/use the code in the repository until the next version of > > the project is released: > > > > > https://svn.apache.org/repos/asf/incubator/jsecurity/trunk/support/spring/src/main/java/org/apache/ki/spring/remoting/ > > > > And look at the SecureRemoteInvocationFactory source. You'll probably > > have to copy-n-paste that into your own implementation and inject that > > implementation at runtime until the next release. > > > > Also, you're correct - you need to use the 'ki' session mode instead of > > the default servlet container HTTP sessions in order to do federated > > session management. This is a feature that servlet containers don't > > have, so you'll need to use Ki's managed enterprise sessions. > > > > Let me ask a question out of curiosity though - is it your intention to > > have both the client grails and the server grails share the same > > session? Or is this more related to login/authorization only? > > > > Cheers, > > > > Les > > > > On Thu, May 28, 2009 at 1:53 AM, jtriley <justin.t.ri...@... > > <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2988979&i=0>> > wrote: > > > > > > Hi Les, > > > > I'm in the process of creating the demo apps and have a few > questions. > > > > So far my setup consists of two grails apps: > > > > server grails - I have jsecurity configured with a local > administrator > > account. Configured two remote services, AuthService and > > RemoteService. I > > added remoteInvocationExecutor property/ref to httpinvoker proxy > > bean in the > > grails remoting plugin script. > > > > client grails - I have jsecurity configured with a local > administrator > > account. I have remote proxy services configured for both Auth and > > Remote > > services. I've setup a test controller that calls a simple method on > the > > remote AuthService. I added remoteInvocationExecutor property/ref to > > httpinvoker executor bean in the grails remoting plugin script. The > > remoteInvocationExecutor bean has a securityManager property/ref to > the > > jsecSecurityManager bean used by the jsecurity plugin. > > > > Without implementing a RemoteRealm I just tried things as is. The > remote > > service call failed telling me I needed to specify a > > jsecurity.session.id <http://jsecurity.session.id> > > system property. Looking at the spring example I determined that > > this was > > simply the session id from logging into the server in a browser. > > > > So I wrote a controller on the server grails to print the session id > > after > > successful login and then used this value to start the client > > grails. After > > specifying jsecurity.session.id <http://jsecurity.session.id> with > > the session id obtained from logging > > into the server I get the following message in a stack trace. > > > > org.codehaus.groovy.runtime.InvokerInvocationException: > > org.jsecurity.session.InvalidSessionException: Specified id > > [zt2xj4ihdhbj] > > does not correspond to a valid Session It either does not exist or > the > > corresponding session has been stopped or expired. > > at > > > org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382) > > > at > > > org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180) > > > Caused by: org.jsecurity.session.InvalidSessionException: Specified > id > > [zt2xj4ihdhbj] does not correspond to a valid Session It either > > does not > > exist or the corresponding session has been stopped or expired. > > at > > > org.jsecurity.mgt.SessionsSecurityManager.getSession(SessionsSecurityManager.java:187) > > > at > > > org.jsecurity.spring.remoting.SecureRemoteInvocationExecutor.invoke(SecureRemoteInvocationExecutor.java:112) > > > at > > > org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382) > > > at > > > org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180) > > > at $Proxy3.getSecuritySubject(Unknown Source) > > at TestController$_closure1.doCall(TestController.groovy:7) > > at TestController$_closure1.doCall(TestController.groovy) > > ... 2 more > > > > This stacktrace was produced from the client as a consequence of > > invoking > > the remote method getSecuritySubject in the remote AuthService. For > > now that > > is a simple dummy method that returns a String just to test RMI from > > end to > > end. I believe everything after $Proxy3.getSecuritySubject(Unknown > > Source) > > happens on the remote end. > > > > I had a suspicion that maybe this had to do with this > > jsecurity.session.mode > > property being http by default. As a shot in the dark I tried > > changing both > > client/grails jsecurity.session.mode to 'jsecurity' but this failed > > because > > of a missing class def: > > > > org.codehaus.groovy.runtime.InvokerInvocationException: > > java.lang.NoClassDefFoundError: > > edu/emory/mathcs/backport/java/util/concurrent/Executors > > at > > > org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382) > > > at > > > org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180) > > > Caused by: java.lang.NoClassDefFoundError: > > edu/emory/mathcs/backport/java/util/concurrent/Executors > > at > > > org.jsecurity.session.mgt.ExecutorServiceSessionValidationScheduler.enableSessionValidation(ExecutorServiceSessionValidationScheduler.java:75) > > > at > > > org.jsecurity.session.mgt.AbstractValidatingSessionManager.enableSessionValidation(AbstractValidatingSessionManager.java:219) > > > at > > > org.jsecurity.session.mgt.AbstractValidatingSessionManager.enableSessionValidationIfNecessary(AbstractValidatingSessionManager.java:92) > > > at > > > org.jsecurity.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:158) > > > at > > > org.jsecurity.session.mgt.AbstractSessionManager.start(AbstractSessionManager.java:62) > > > at > > > org.jsecurity.web.session.DefaultWebSessionManager.start(DefaultWebSessionManager.java:223) > > > at > > > org.jsecurity.web.session.DefaultWebSessionManager.start(DefaultWebSessionManager.java:219) > > > at > > > org.jsecurity.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:178) > > > at > > > org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:284) > > > at > > > org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:272) > > > at AuthController$_closure6.doCall(AuthController.groovy:71) > > at AuthController$_closure6.doCall(AuthController.groovy) > > ... 2 more > > > > I'm hoping to get this method working first (ie passing the session > > id at > > startup) since this is the lowest hanging fruit. Ideally a Realm > > implementation, as we've discussed, would help me to obtain the > > session id > > at runtime without needing to obtain it before hand, however I > imagine > > that'll be easier once I know this jsecurity.session.id > > <http://jsecurity.session.id> method works as a > > baseline. Any thoughts/suggestions appreciated as always. > > > > And I'll be sure to add issues/suggestions to Jira as I encounter > them. > > > > Thanks Les, > > > > ~jtriley > > > > > > Les Hazlewood-2 wrote: > > > > > > No prob - glad to help. I'll look forward to the demo :) > > > > > > Also, if you see anything along the way that would make (or would > have > > > made) > > > your life easier, please add these suggestions as Jira issues. > > Federated > > > SecurityManager support should be a first class citizen in a later > > > release, > > > so anything you come across along the way could help others in the > > future. > > > > > > > -- > > View this message in context: > > > http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2985681.html > > Sent from the JSecurity User mailing list archive at Nabble.com. > > > > > > > > > > ------------------------------------------------------------------------ > > This email is a reply to your post @ > > > http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2988979.html > > You can reply by email or by visting the link above. > > > > > ------------------------------ > View this message in context: Re: integrating jsecurity/ki auth with > spring's > httpinvoker<http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2990179.html> > > Sent from the JSecurity User mailing list > archive<http://n2.nabble.com/JSecurity-User-f582556.html>at Nabble.com. >
