On Wed, May 27, 2009 at 11:15 AM, jtriley <[email protected]> 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
