> I'm not sure what's going on with the security code in the > rundata_security_changes branch but I think we're veering off a bit:
I think you are right; this is at least in part due to my schedule (I will not be at the office more than a couple of hours this and the next week), for which I apologize. > 1. The security model should be completely self contained, so that the new > model that you (eric and gonzo) should be completely isolated in the > o.a.t.security.turbine package. There shouldn't be any interfaces in > the o.a.t.security package except for the SecurityManager. This was so until my last commit (maybe a week ago); moreover, the only file in o.a.t.s was SecurityManager, an EMPTY interface. I have been unable to connect to cvs.apache.org, so I really cannot comment about the current state of the code. > 2. We agreed that SecurityManager is going to be the controlling unit for > security. A SecurityManager may use several SecurityModels in > an application. I am -1 on the use of Policy as a replacement for > SecurityManager: I don't want to use JAAS nomenclature at the top > level and I would like to follow the patterns used Stratum and > Fulcrum where we have Xmanager. I don't think policy accurately > describes what something like a security manager would do. I am agnostic in terms of nomenclature; I believe it makes sense to stick to the names used throughout other Turbine projects. I also have the feeling the names I used in my initial commit (Subject, Permission, Credentials, SecurityManager) are more obvious and don't carry any extra "baggage" with them. > I am about get the fulcrum security stuff working so I would like to push > all currently proposed security code into o.a.t.security.turbine so it's > self contained and make a new o.a.t.security.fulcrum package where I will > bundle all the classes that are bound to fulcrum. I'm not really sure what you mean here... What do you intend to put in o.a.t.s.fulcrum? (Keep in mind I don't know the current state of the repo). > The other I had for gonzo and eric is: can't you primarily use what's in > fulcrum as a basis and fix what was a problem? I haven't started > looking in > depth at the proposed code I'm just asking. I know the current > security code > is problematic but I'd say it's 80% there interface wise. I disagree. The code in fulcrum makes explicit use of Roles and Groups. One of the big pushes in the new design is to simplify as much as possible the design. I'm not saying Roles and Groups are bad or anything; in fact, I like role-based security, and probably would use it almost everywhere. But the basic implementation should be that: basic. And of course it should allow for role-based security. > Jason van Zyl -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
