[Zope-dev] Enhancing Zope's security model

[David Jacobs]

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