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.
