> Ok, I know JAAS was not specificly designed with webapps in mind. > Still, I think that the fact that it is a low-level security > framework makes it specially secure. I have been thinking that > every action and screen could implement the PrivilegedAction > Interface so the default implementation of the run method is the > one which, on authorization succed, executes the doPerform or > doBuildTemplate methods. What do you think?
True, it is especially secure. It would give you a stronger guarantee that only user/group x could execute a given Action in that they could not just find a way to circumvent your security and then somehow execute the Action when you don't want them to; the Java VM would enforce them having to go through your JAAS security code to get the right permissions. Though I wonder how JAAS works in a dynamic environment? E.g. if user X logs in to your JAAS web app and loads class A from a jar, when a request from user Y comes in, since class A is already loaded into the VM, will they have to have special JAAS permission to use it (e.g. is JAAS used only at class-load time or object-creation time)? I don't know. Also, my naive understanding of JAAS is that it limits itself to stuff like file access, class access, port/net access, much like the existing VM security model. Most webapps when using a security API would probably want to add their own dynamic elements to the API, e.g. groups of 'admins', 'managers', 'users', and users of 'bob', 'fred', etc. I honestly don't know if JAAS supports this; my intuition is that it doesn't, though I'm completely open to being proven wrong. > On the other hand, I have been told that there is a new security > service being developed, but it will still rely on Torque. Since > Torque is being decoupled from Turbine, I think relying the > security service on it is not a very good idea, since there will > be some users that would like to use the security framework, but > wouldn't like to use Torque (and that is my specific case). I agree with you that any new security service should not use Torque, as from my past usage of the current security service, the only thing wrong with it, and the very reason I thought it was being replaced, as it's tight coupling to Torque. Though perhaps I missed the other motivations for considering something like JASF. > I am not saying a Torque based security service is not useful. I > am saying the security framework should be thougth as open as > possible so any one could implement a new engine under its API > (read interfaces) without hurting the rest of Turbine. Agreed. Though I'm still under the impression (perhaps wrongly, I dunno) that any future security API would have a decoupled API but then a default backend implementation that is coupled to Torque; the ideal situation being that you could plugin your own, non-Torque backend. (Though now that I think about it, doesn't the current security service also do this? What with this LDAP backend?) - Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
