Is anyone currently working on enhancing Zope's security model?
Yes, that's my bag-o-tricks, and probably a big chunk of why I'm here... I left Xcert's PKI consulting group to come to Digital Creations. I'll try and make a broad stroke at some of the ideas that I've been thinking about---it just takes time (or money).
Traditional web servers have horrible security model's for the application designer. They leave almost all the security work to be done by the application itself. With Zope abstracting all access into a nice object oriented fashion, much more powerful models are possible.
Traditional web servers have no security MODEL :-) having said that, I can only agree whole-heartedly here. One of the things I'm working on slowly is creating a full UML model of the security model implemented in Zope. Then we can better discuss changes to the model. I'm a big believer in formalization of the security model, as opposed to the purely textual "well, we check X here".
What you guys have done with users, permissions and roles is already far ahead of other web servers. I am interested in taking it a step further to remove even more security code that currently resides in dtml scripts.
This is a good thing, it also is necessary as we begin to integrate some of the concepts introduced in the PKI world. We've already started to work on how do you define roles and fit anonymous users into them. Also, how do you separate the identification stage from the authentication stage. For example, the path of a user through the security model: 1. 100% anonymous, unknown person 2. Identifiable anonymous person (same person, but not sure who) 3. Identified person, but not authenticated 4. I&A person, but not authorized 5. Authorized At any point, you should be able to bind that "individual" to a role.
Provide for positive and negative authorizations. * We may want to give a role Employees access to a method, but not if the user is also in the role Bad Boys.
This is something I miss too... it would be nice to be able to "allow/deny" permissions overriding acquisition through this... so each setting would have three possible positions: * On (allow) * Off (deny) * Acquire Now, as you talk about being able to define a "permission" that has intelligence to it, and I'm not sure how to do that without having a huge impact on performance, but it is an interesting idea, especially as you try and translate X.509 certificate information (i.e. DN + LDAP) into a set of Roles.
Provide for resolution rules for when positive and negative authorization conflict. * (e.g. lower in the object hierarchy overrides inherited auths, negative overrides positive, order dependent)
First glance says this is 1) largely accomplished by acquisition as it is, 2) too complex if it isn't as it introduces yet another concept that the user must grasp. The single largest flaw with many security solutions is they aren't obvious, and in their obtuosity they only create more problems. Perhaps I'm simply not understanding this. Want to write some pseudo code, er... Python?
Allow time restrictions on user/role associations or method/role associations (duration or cyclical restrictions) * This would allow you to say Joe is a Manager from June 1 to June 30th.
I can imagine this being useful. More importantly, Joe is only a manager from 8am-5pm M-F. This is a very common thing.
* This would allow you to say the Pay Payroll method can only be run on Friday's.
This is probably best enforced at the "application" layer as opposed to the framework layer. But perhaps there should be a way to have a separation of the security "check" from the DTML itself.
* This is useful in that you don't have to remember to remove Joe from the role. It also helps when looking at audit logs you can see that he was authorized to perform those functions during that time.
No disagreement, but we have to balance power and speed and usability.
Allow actions to be associated with an authorization event. * on success (e.g. write audit entry in log) * on failure (e.g. write audit entry in log and call routine that checks for excessive failures and pages sys admin if over the threshold.send email)
Perhaps exposure of the new ZLOG framework at the DTML level would be useful? Simply use a <dtml-call "auditme('information here')"> ?
Allow expressions that include object values to play in the authorization decision. * Given an expense voucher (EV) object, a 1st Level Manager can 'sign' (an EV method) if the EV.amount is less than $2500 and the EV.author is not the AUTHENTICATED_USER.
Scared :-) Again, perhaps an abstract concept of a property on an object that can on the *rare* occasion that it is needed could be called? You bring up some good ideas, discussion is good on this. Christopher -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com