You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by jtriley <ju...@gmail.com> on 2009/05/14 20:54:30 UTC
integrating jsecurity/ki auth with spring's httpinvoker
I'm curious if anyone could shed some light on how to do the following:
I have two grails apps that I've connected via spring's httpinvoker via the
grails remoting plugin. I have jsecurity installed on the remote side with a
few users/roles. I'd like to create a user for the client grails app to
authenticate with so that I can rest assure that only those apps with the
proper credentials can use the server's remote procedures.
Basically, anytime my client grails app connects to the remote grails app
via spring's httpinvoker, I'd like for the httpinvoker bean to pass along a
username/password, obtain a session, and then carry that session for future
remote procedure calls (just like in a browser). Otherwise, any
unauthenticated calls to the remote grails app's remote procedures should
fail.
So, in researching this, it appears that jsecurity has a
org.jsecurity.spring.remoting package that contains the following classes:
SecureRemoteInvocationExecutor (server side)
SecureRemoteInvocationFactory (client side)
Looking in at the guts of the remoting plugin I have determined that
org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter is used
on the remote side and
org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean is used
for the client side.
Looking at these classes I see that I can set a property
"remoteInvocationExecutor" on the enclosing beans that points to the classes
in org.jsecurity.spring.remoting
What I'm confused about at this point is how I pass in the username/password
from the client-side and I'm also wondering if there's anything to do on the
server side?
Of course, I could be totally off with all of this and would certainly
appreciate someone setting me straight on these issues.
Thanks!
~jtriley
--
View this message in context: http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2898395.html
Sent from the JSecurity User mailing list archive at Nabble.com.
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by Les Hazlewood <lh...@apache.org>.
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 <ju...@gmail.com> 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.riley@...
> > <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.
>
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by jtriley <ju...@gmail.com>.
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.riley@...
> <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.
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by Les Hazlewood <lh...@apache.org>.
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 <ju...@gmail.com> 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
> 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 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 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.
>
>
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by jtriley <ju...@gmail.com>.
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
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 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 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.
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by Les Hazlewood <lh...@apache.org>.
On Wed, May 27, 2009 at 11:15 AM, jtriley <ju...@gmail.com> wrote:
>
> >
> > Another option that I'd think about as well would be to have your
> > delegating Realm not necessarily delegate to the remote SecurityManager
> > directly, but instead a thin wrapper service that could give your realm
> > whatever it needed (and it perhaps talked to its own system's
> > SecurityManager).
> >
>
> I think this is also a good idea. In my head I would now have two remote
> services on the server side: an unsecured remote service for handling auth
> requests and a jsec/ki secured remote service for doing real work. On the
> client side, since I have jsecurity installed there as well, I would need
> to
> set the jsecurity.authentication.strategy to
> AtLeastOneSuccessfulModularAuthenticationStrategy since only the remote
> auth
> will succeed when using the remote credentials. Does this sound reasonable?
Yep, that sounds like the way to go.
Les Hazlewood-3 wrote:
> >
> > ..... (you should probably extend AuthorizingRealm to take advantage of
> > caching role/perm information)....The built-in caching mechanism will
> help
> > performance a lot, eliminating round-trips to the remote SecurityManager.
> >
> I'll also give this a shot.
>
> Thanks a lot for your help so far Les. I'll post my progress here and
> hopefully I'll be able to share the solution via a bundle of demo
> client/server grails apps.
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.
Cheers,
Les
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by jtriley <ju...@gmail.com>.
Sorry about the last message, post and preview buttons are too close :P
Les Hazlewood-3 wrote:
>
> This should be ok. I'm thinking maybe one of the easiest things to do is
> create a Realm implementation that actually makes RMI calls to the
> 'server' SecurityManager. That realm implementation could be injected
> into the 'client' SecurityManager configuration. In other words, your
> Realm implementation's 'data source' would really just be the remote
> SecurityManager. Does that make sense?
>
> ...The Subject implementation just delegates to the local SecurityManager.
> The SecurityManager then would call one or more Realms. If one of those
> Realms was a proxy to the remote SecurityManager, that should make things
> easier.
>
>
I'm pretty sure I get the picture and it sounds like a great idea. Thanks
for explaining how the realms work, this definitely seems to be the way to
go. After reading a bit, it appears the jsecurity grails plugin has the
ability to define realms easily and I could inject an unsecured remote proxy
(ie Remote Service) into the realm just for proxying authentication to the
server.
Les Hazlewood-3 wrote:
>
> Another option that I'd think about as well would be to have your
> delegating Realm not necessarily delegate to the remote SecurityManager
> directly, but instead a thin wrapper service that could give your realm
> whatever it needed (and it perhaps talked to its own system's
> SecurityManager).
>
I think this is also a good idea. In my head I would now have two remote
services on the server side: an unsecured remote service for handling auth
requests and a jsec/ki secured remote service for doing real work. On the
client side, since I have jsecurity installed there as well, I would need to
set the jsecurity.authentication.strategy to
AtLeastOneSuccessfulModularAuthenticationStrategy since only the remote auth
will succeed when using the remote credentials. Does this sound reasonable?
Les Hazlewood-3 wrote:
>
> ..... (you should probably extend AuthorizingRealm to take advantage of
> caching role/perm information)....The built-in caching mechanism will help
> performance a lot, eliminating round-trips to the remote SecurityManager.
>
I'll also give this a shot.
Thanks a lot for your help so far Les. I'll post my progress here and
hopefully I'll be able to share the solution via a bundle of demo
client/server grails apps.
~jtriley
--
View this message in context: http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2981784.html
Sent from the JSecurity User mailing list archive at Nabble.com.
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by jtriley <ju...@gmail.com>.
Les Hazlewood-3 wrote:
>
>
>
--
View this message in context: http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2981605.html
Sent from the JSecurity User mailing list archive at Nabble.com.
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by Les Hazlewood <le...@anjinllc.com>.
On Mon, May 18, 2009 at 6:16 PM, jtriley <ju...@gmail.com> wrote:
> So the previous email dealt with issues starting the spring-sample in
> ki's svn tree.
>
> Concerning my original use case:
>
> One detail I forgot to mention was that my client grails app ALSO has
> jsecurity/ki users/roles separate from the server. The idea is that
> users login to the client grails app using the client's users/roles, and
> the client grails app itself would authenticate to the server against
> the server's users/roles. The authentication on the server in this case
> is only used to authenticate RMI clients. Do you see any issues with
> this setup?
This should be ok. I'm thinking maybe one of the easiest things to do is
create a Realm implementation that actually makes RMI calls to the 'server'
SecurityManager. That realm implementation could be injected into the
'client' SecurityManager configuration. In other words, your Realm
implementation's 'data source' would really just be the remote
SecurityManager. Does that make sense?
>
>
> Also, in my setup, grails/spring injects the remote proxy stub that's
> been configured to proxy the given interface (in grails remoting plugin,
> this is a remote Service).
>
> So I'm curious, do I just do this on the client?:
>
> class SomeClass {
> def remoteService (dependency injected remote proxy)
>
> def callRemoteMethod() {
> Subject subject = SecurityUtils.getSubject()
> subject.login(...)
> remoteService.someMethod()
> ....
> }
> }
>
> If that's the case, given that I have jsecurity user/roles on the client
> and the server as well, does my call to getSubject give me a remote
> Subject or a local Subject?
Local, i.e. the Subject implementation just delegates to the local
SecurityManager. The SecurityManager then would call one or more Realms.
If one of those Realms was a proxy to the remote SecurityManager, that
should make things easier.
> If it's local, then a call to login is
> going to try to authenticate against the client's user/roles which is
> not what I need. If it's remote, does this affect my client's local
> user/roles queries as well?
By using the delegating Realm approach mentioned above (you should probably
extend AuthorizingRealm to take advantage of caching role/perm information),
you would have that delegating realm return roles/perms that exist in the
remote server. The built-in caching mechanism will help performance a lot,
eliminating round-trips to the remote SecurityManager.
Clearly, I'm still confused. I'm trying to get this working so that I
> can contribute it back to the grails remoting plugin. (ie if you
> install grails, jsecurity/ki plugin, and remoting plugin you should have
> the option to have secured httpinvoker RMI).
Its a little difficult to set up for sure - the concept of 'federated'
security managers is a bigger enterprise feature that hasn't been built
directly in to the framework. That is not to say you can't do it, its just
not as 'hands off' as most of the rest of the framework.
Another option that I'd think about as well would be to have your delegating
Realm not necessarily delegate to the remote SecurityManager directly, but
instead a thin wrapper service that could give your realm whatever it needed
(and it perhaps talked to its own system's SecurityManager).
If you think of features you would need to accomplish this a little easier,
please, by all means add some Jira issues so we don't lose track of them.
I hope that helps!
Cheers,
Les
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by jtriley <ju...@gmail.com>.
So the previous email dealt with issues starting the spring-sample in
ki's svn tree.
Concerning my original use case:
One detail I forgot to mention was that my client grails app ALSO has
jsecurity/ki users/roles separate from the server. The idea is that
users login to the client grails app using the client's users/roles, and
the client grails app itself would authenticate to the server against
the server's users/roles. The authentication on the server in this case
is only used to authenticate RMI clients. Do you see any issues with
this setup?
Also, in my setup, grails/spring injects the remote proxy stub that's
been configured to proxy the given interface (in grails remoting plugin,
this is a remote Service).
So I'm curious, do I just do this on the client?:
class SomeClass {
def remoteService (dependency injected remote proxy)
def callRemoteMethod() {
Subject subject = SecurityUtils.getSubject()
subject.login(...)
remoteService.someMethod()
....
}
}
If that's the case, given that I have jsecurity user/roles on the client
and the server as well, does my call to getSubject give me a remote
Subject or a local Subject? If it's local, then a call to login is
going to try to authenticate against the client's user/roles which is
not what I need. If it's remote, does this affect my client's local
user/roles queries as well?
Clearly, I'm still confused. I'm trying to get this working so that I
can contribute it back to the grails remoting plugin. (ie if you
install grails, jsecurity/ki plugin, and remoting plugin you should have
the option to have secured httpinvoker RMI).
Thanks for your help so far,
~Justin
Justin Riley wrote:
> Hi Les,
>
> Thanks for your reply, it has helped to clarify some things and I'm
> currently looking at the sample spring application's code.
>
> I decided to use a svn checkout of the latest ki code and built the code
> and examples using mvn clean install.
>
> I took the war generated from spring-sample and dumped it into tomcat's
> webapp directory, started tomcat, and now I have the server running
> successfully at http://localhost:8080/ki-spring/.
>
> I got as far as logging in and clicking the jnlp to launch the web start
> demo...however, the libraries it needs are missing from the war'd spring
> sample and so it failed.
>
> So, I decided to go back to command line and run the gui myself by
> specifying classpath and -Dki.session.id=whatever-server-said, however,
> I'm getting this error:
>
> Exception in thread "main"
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'webStartView' defined in class path resource
> [webstart.spring.xml]: Invocation of init method failed; nested
> exception is java.lang.IllegalStateException: No SecurityManager
> accessible to this method, either bound to the
> org.apache.ki.util.ThreadContext or as a vm static singleton. See the
> org.apache.ki.SecurityUtils.getSubject() method JavaDoc for an
> explanation of expected environment configuration.
>
> Any ideas?
>
> Thanks!
>
> ~Justin
>
>
> Les Hazlewood-2 (via Nabble) wrote:
>> Hi Justin,
>>
>> You're pretty close - you don't pass the username/password along with
>> each remoting invocation. It works just like a normal user account.
>>
>> For example, you get the Subject, then you call
>> login(AuthenticationToken), and once successful, you continue to use
>> that subject for further invocations. As long as the session id goes
>> along with every remote invocation, the server side can associate the
>> request with the correct user.
>>
>> We have a spring sample application here:
>> https://svn.apache.org/repos/asf/incubator/jsecurity/trunk/samples/spring/
>>
>> It uses a Java WebStart Swing UI that acts as the remote client, but
>> works in essense like your remote grails app. Check that out and see if
>> that helps. Feel free to ask more questions.
>>
>> Cheers,
>>
>> Les
>>
>> On Thu, May 14, 2009 at 2:54 PM, jtriley <justin.t.riley@...
>> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2907871&i=0>> wrote:
>>
>>
>> I'm curious if anyone could shed some light on how to do the following:
>>
>> I have two grails apps that I've connected via spring's httpinvoker
>> via the
>> grails remoting plugin. I have jsecurity installed on the remote
>> side with a
>> few users/roles. I'd like to create a user for the client grails app to
>> authenticate with so that I can rest assure that only those apps
>> with the
>> proper credentials can use the server's remote procedures.
>>
>> Basically, anytime my client grails app connects to the remote
>> grails app
>> via spring's httpinvoker, I'd like for the httpinvoker bean to pass
>> along a
>> username/password, obtain a session, and then carry that session for
>> future
>> remote procedure calls (just like in a browser). Otherwise, any
>> unauthenticated calls to the remote grails app's remote procedures
>> should
>> fail.
>>
>> So, in researching this, it appears that jsecurity has a
>> org.jsecurity.spring.remoting package that contains the following
>> classes:
>>
>> SecureRemoteInvocationExecutor (server side)
>> SecureRemoteInvocationFactory (client side)
>>
>> Looking in at the guts of the remoting plugin I have determined that
>> org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter
>> is used
>> on the remote side and
>> org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean
>> is used
>> for the client side.
>>
>> Looking at these classes I see that I can set a property
>> "remoteInvocationExecutor" on the enclosing beans that points to the
>> classes
>> in org.jsecurity.spring.remoting
>>
>> What I'm confused about at this point is how I pass in the
>> username/password
>> from the client-side and I'm also wondering if there's anything to
>> do on the
>> server side?
>>
>> Of course, I could be totally off with all of this and would certainly
>> appreciate someone setting me straight on these issues.
>>
>> Thanks!
>>
>> ~jtriley
>> --
>> View this message in context:
>> http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2898395.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-tp2898395p2907871.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-tp2898395p2936063.html
Sent from the JSecurity User mailing list archive at Nabble.com.
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by jtriley <ju...@gmail.com>.
Hi Les,
Thanks for your reply, it has helped to clarify some things and I'm
currently looking at the sample spring application's code.
I decided to use a svn checkout of the latest ki code and built the code
and examples using mvn clean install.
I took the war generated from spring-sample and dumped it into tomcat's
webapp directory, started tomcat, and now I have the server running
successfully at http://localhost:8080/ki-spring/.
I got as far as logging in and clicking the jnlp to launch the web start
demo...however, the libraries it needs are missing from the war'd spring
sample and so it failed.
So, I decided to go back to command line and run the gui myself by
specifying classpath and -Dki.session.id=whatever-server-said, however,
I'm getting this error:
Exception in thread "main"
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'webStartView' defined in class path resource
[webstart.spring.xml]: Invocation of init method failed; nested
exception is java.lang.IllegalStateException: No SecurityManager
accessible to this method, either bound to the
org.apache.ki.util.ThreadContext or as a vm static singleton. See the
org.apache.ki.SecurityUtils.getSubject() method JavaDoc for an
explanation of expected environment configuration.
Any ideas?
Thanks!
~Justin
Les Hazlewood-2 (via Nabble) wrote:
> Hi Justin,
>
> You're pretty close - you don't pass the username/password along with
> each remoting invocation. It works just like a normal user account.
>
> For example, you get the Subject, then you call
> login(AuthenticationToken), and once successful, you continue to use
> that subject for further invocations. As long as the session id goes
> along with every remote invocation, the server side can associate the
> request with the correct user.
>
> We have a spring sample application here:
> https://svn.apache.org/repos/asf/incubator/jsecurity/trunk/samples/spring/
>
> It uses a Java WebStart Swing UI that acts as the remote client, but
> works in essense like your remote grails app. Check that out and see if
> that helps. Feel free to ask more questions.
>
> Cheers,
>
> Les
>
> On Thu, May 14, 2009 at 2:54 PM, jtriley <justin.t.riley@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2907871&i=0>> wrote:
>
>
> I'm curious if anyone could shed some light on how to do the following:
>
> I have two grails apps that I've connected via spring's httpinvoker
> via the
> grails remoting plugin. I have jsecurity installed on the remote
> side with a
> few users/roles. I'd like to create a user for the client grails app to
> authenticate with so that I can rest assure that only those apps
> with the
> proper credentials can use the server's remote procedures.
>
> Basically, anytime my client grails app connects to the remote
> grails app
> via spring's httpinvoker, I'd like for the httpinvoker bean to pass
> along a
> username/password, obtain a session, and then carry that session for
> future
> remote procedure calls (just like in a browser). Otherwise, any
> unauthenticated calls to the remote grails app's remote procedures
> should
> fail.
>
> So, in researching this, it appears that jsecurity has a
> org.jsecurity.spring.remoting package that contains the following
> classes:
>
> SecureRemoteInvocationExecutor (server side)
> SecureRemoteInvocationFactory (client side)
>
> Looking in at the guts of the remoting plugin I have determined that
> org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter
> is used
> on the remote side and
> org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean
> is used
> for the client side.
>
> Looking at these classes I see that I can set a property
> "remoteInvocationExecutor" on the enclosing beans that points to the
> classes
> in org.jsecurity.spring.remoting
>
> What I'm confused about at this point is how I pass in the
> username/password
> from the client-side and I'm also wondering if there's anything to
> do on the
> server side?
>
> Of course, I could be totally off with all of this and would certainly
> appreciate someone setting me straight on these issues.
>
> Thanks!
>
> ~jtriley
> --
> View this message in context:
> http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2898395.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-tp2898395p2907871.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-tp2898395p2935831.html
Sent from the JSecurity User mailing list archive at Nabble.com.
Re: integrating jsecurity/ki auth with spring's httpinvoker
Posted by Les Hazlewood <lh...@apache.org>.
Hi Justin,
You're pretty close - you don't pass the username/password along with each
remoting invocation. It works just like a normal user account.
For example, you get the Subject, then you call login(AuthenticationToken),
and once successful, you continue to use that subject for further
invocations. As long as the session id goes along with every remote
invocation, the server side can associate the request with the correct user.
We have a spring sample application here:
https://svn.apache.org/repos/asf/incubator/jsecurity/trunk/samples/spring/
It uses a Java WebStart Swing UI that acts as the remote client, but works
in essense like your remote grails app. Check that out and see if that
helps. Feel free to ask more questions.
Cheers,
Les
On Thu, May 14, 2009 at 2:54 PM, jtriley <ju...@gmail.com> wrote:
>
> I'm curious if anyone could shed some light on how to do the following:
>
> I have two grails apps that I've connected via spring's httpinvoker via the
> grails remoting plugin. I have jsecurity installed on the remote side with
> a
> few users/roles. I'd like to create a user for the client grails app to
> authenticate with so that I can rest assure that only those apps with the
> proper credentials can use the server's remote procedures.
>
> Basically, anytime my client grails app connects to the remote grails app
> via spring's httpinvoker, I'd like for the httpinvoker bean to pass along a
> username/password, obtain a session, and then carry that session for future
> remote procedure calls (just like in a browser). Otherwise, any
> unauthenticated calls to the remote grails app's remote procedures should
> fail.
>
> So, in researching this, it appears that jsecurity has a
> org.jsecurity.spring.remoting package that contains the following classes:
>
> SecureRemoteInvocationExecutor (server side)
> SecureRemoteInvocationFactory (client side)
>
> Looking in at the guts of the remoting plugin I have determined that
> org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter is used
> on the remote side and
> org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean is
> used
> for the client side.
>
> Looking at these classes I see that I can set a property
> "remoteInvocationExecutor" on the enclosing beans that points to the
> classes
> in org.jsecurity.spring.remoting
>
> What I'm confused about at this point is how I pass in the
> username/password
> from the client-side and I'm also wondering if there's anything to do on
> the
> server side?
>
> Of course, I could be totally off with all of this and would certainly
> appreciate someone setting me straight on these issues.
>
> Thanks!
>
> ~jtriley
> --
> View this message in context:
> http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2898395.html
> Sent from the JSecurity User mailing list archive at Nabble.com.
>
>