Hi Christopher! Nice to meet you. I hope I can be helpful to you. See responses below. ----- Original Message ----- From: Christopher Petrilli <petrilli@digicool.com>
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).
With respect to time, I have a day a week for the next 9 to 12 months to dedicate to the problem. I am pursuing my dissertation (course work is done :-) on creating a security model for web based applications and my company has given me a day off a week to work on it. Zope seemed the farthest along in providing the rest of the infrastructure a web based security model would require. I have a 20 year background in object oriented programming (mostly C++) and security but have not done much in Python.
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 tool are you using for your UML modeling? I must admit I have not kept up with UML. The last time I was heavy into case tools was back in 1992 using Rational Rose when Booch and Co. where still duking it out over the icons and fomalisms. I would love to see what you have so far or even any notes you have electronically.
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.
I would add their location and the kind of authentication is also important. For example many sites, especially digital library sites use the user's ip domain to determine what role they are assigned to. You might also want to assign different roles based on whether they have authenticated with a password in the clear or a password over SSL or a client certificate (not sure if this is useful).
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.
I'm not sure which concept you were referring to here :-).
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.
I agree the utility versus complexity is pretty low. At most it might be useful to offer a couple of predefined resolution modes with hooks to allow people to put in their own if they really want it.
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?
I agree whole heartedly. If you read the literature, people have come up with some amazing languages for expressing authorizations in an object oriented fashion, but god help the poor user who has to actually write real world authorizations in those languages. My desire is to try and bring some of these concepts "down to earth" and make them useful.
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.
I think we will find that many of the features we think up may not have broad appeal. While that may be reason enough not to make them a "standard" feature, I agree that the framwork should still support plugging in the functionality via an API or standard security "check" concept that you brought up.
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')"> ?
Upon further reflection, I would change this a little. Instead of allowing arbitrary actions, I would restrict it to just auditing events. I still think it would be useful to abstract it out of the DTML level though. Wouldn't it be nice to be able to log SQLMethod's and other zope objects?. All analysis of the events would be the responsability of a process outside of Zope such as an intrusion/fraud detection system.
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?
Yes this is scary :-). It is also one of the most powerful. When you consider supporting almost any workflow based application, this becomes a necessity. This is because the state of an object often directly affects what and who can act on it. Thanks again for your response! David