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: http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2990179.html Sent from the JSecurity User mailing list archive at Nabble.com.
