----- Original Message ----- From: "Stephen Haberman" <[EMAIL PROTECTED]> To: "Turbine Developers List" <[EMAIL PROTECTED]> Sent: Monday, February 17, 2003 12:37 PM Subject: Re: Is there some new security service being developed?
> > 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. I think it is used at object-creation time since it needs the class the access of which is going to be controlled to have the PrivilegedAction interface implemented. This interface has a run() method wich is the one that controls the execution of the action on a per-user basis (per-subject basis, as a matter of fact). > 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. > I am also new to JAAS, but as far as I have investigated, it should allow you to have groups, roles and permissions, just like the current security service allows. Still, it would be more secure. > > 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?) I as you may have already read from my previous posting, I have just discovered that. But even if implementing my own backend could solve my problem, A JAAS based security service could be a great addition to an already great framework like Turbine, couldn't it? ;) > - Stephen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
