[Zope-dev] Enhancing Zope's security model

[Andreas Kostyrka]

On Wed, 7 Jul 1999, David Jacobs wrote:

> 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.
> 
> 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)
> 
> Allow time restrictions on user/role associations or method/role
> associations (duration or cyclical restrictions)
This could be probably done quite easily by providing a different
augmented User Folder.
> 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)
This could be added when some poor soul does the rewrite of error handling
in ZPublisher to work correctly with the standard_error_message document.

> 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.
Well, this would quite complicate the existing permission model. Don't
know if the complications for ALL users outweigh the convience for SOME
users.

> What do people think?  Does this functionality sound useful?  Do certain
> features call louder than others.  I believe these features will make Zope
> MUCH more attractive for developing intranet applications, which typically
> have much more complex security requirements than public web sites do.
Probably, but more complicated applications will always have to be
scripted: if you add feature A,B and C today, then you will discover that
you still need feature D.

So IMHO, even A, B and C should be scripted, especially, when they are not
of use for MOST users.

> I realize that most if not all of these features can be accomplished by
> coding in dtml.  I would like to see much of that abstracted out into the
> security interface so that security policies can be more easily changed.
Again, create a specialized User folder, that can hold your security
parameters. After that you can change the parameters easily enough :)

> I also realize that besides implementation, there is also the problem of
> coming up with a reasonable user interface that does not swamp the average
> person with possibilities.  Good default behavior is necessary, with the
> full complexity of options only showing if the application designer asks for
> it.
That's the difficult one. Even worse, Z users also tend to write a little
bit of Python (on the principle, that some things are difficult to
impossible in DTML, e.g. circumventing Acquisition, which sometimes 
simplifies things). So your implementation should have also an API that
is simple.

> I've started familiarizing myself with the source code but have a ways to
> go.  Obviously I would be making lots of changes in the access control
> directory, but it looks like a lot of the security framework is also
> embedded into the Zope objects like Folder and Document Objects.  Any tips
> on code to pay special attention to or code that I can safely ignore would
> be greatly appreciated.
1.) Fool around with Zope.
2.) Learn Python (if you do not know it well.)
3.) Learn to use ZPublisher alone. This should give you the base
    understanding about security with Zope.
4.) Read source code.

Andreas
-- 
Win95: n., A huge annoying boot virus that causes random spontaneous system
     crashes, usually just before saving a massive project.  Easily cured by
     UNIX.  See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.