Interesting. Sure, if our users desire it, and it comes up as a use case enough, I think we should support that. We could add a flag that is disabled by default, and it would be an easy config change if they wanted to enable it.
On Mon, Mar 16, 2009 at 9:36 AM, Jeremy Haile <[email protected]> wrote: > Yeah - I planned to respond to that today. The problem is that JSecurity > doesn't hold on to their user credentials (it shouldn't!), so we have no way > to get authz info after login unless we have a superuser account to log in > with. > > Should we add support to JSecurity to load your authz at login and not > re-request from the Realm everytime? This is the way a lot of security > frameworks work, and although it's usually an advantage of JSecurity (i.e. > dynamic reloading of authz information at runtime), in this case it's a pain > because we can't get authorization information without user credentials. I > could imagine other cases where this also is a problem (for example when > authenticating to an SSO that sends back the authz information at runtime or > any external system for which authz info is only available along with user > credentials). > > Jeremy > > > > On Mar 16, 2009, at 9:29 AM, Les Hazlewood wrote: > > Tim or Jeremy, could you please help this guy? I know you guys wrote the >> ActiveDirectory/LDAP stuff - I'm afraid I don't know it all that well. >> >> http://www.jsecurity.org/node/1085 >> >> Cheers, >> >> Les >> > >
