[Zope-dev] Enhancing Zope's security model

[Christopher Petrilli]

> 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