On Mon, May 18, 2009 at 6:16 PM, jtriley <[email protected]> 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
