[Zope-PTK] PROPOSAL: A Confidence Mechanism in User RoleManagement

[Christopher Petrilli]

On 2/11/00 6:29 PM, Chip Vanek at chip@upcast.com wrote:

> I am rather new to Zope and do not yet understand the whole
> roles & permissions implementation.  Thanks for setting me straight.

You should do some especially focused looking a the concept of local roles
granted to a user on a specific object.

>> Um, I don't follow this?  I don't think we have any intention of
>> externalizing the authentication and authorization code to an "external
>> system".  
>> 
> 
> Yes, this comment was primarily focused on externalizing the
> authorization requests for some users.  I was interested in a way
> to allow Zope to provide services to 10k++ users were some subset
> of the users are members of another trusted system.

If such a system provides an API for authentication, one could theoretically
construct a replacement UserFolder that interfaced with it.  This would be
non-trivial in many cases.

>> What is a time zone on the Internet?
> 
> OK the example sucks.  I followed the thread back to your proposal
> and see that you have the concept of constraints on the roles that
> can be granted.  This question was about having a constraint type
> structure for user access method.  HTTP is just the most popular
> access type now.  What about SOAP, XML-RPC, some ubiquitous Microsoft
> access method like COM, WAP, or some emerging access method.

This was at least discussed as being a potential factor in confidence,
however it's more interesting as different views of the same data, something
that Jim Fulton and I had a talk about the other day.  Some data might not
be visible from certain perspectives, or presented in a totally different
way.  This is a product, in my mind, of the model-view-controller pattern.

>> Very fine grained security models have traditionally been
>> abysmal failures
>> (I can point at some MSSI stuff done at NSA if you want
>> examples).  They are
>> too complex for 99.99% of the population, and valuable to an
>> even smaller
>> percentage.
>> 
> 
> Yeh, if you could send me some of those pointers it would be
> great.  My daytime job is building services using HP new e'Speak
> technology and they are introducing some security models and concepts
> that are beyond my present understanding (no great stretch;).

I will dig up what I can publish (much of the research is not public, but
not classified either, lalalala).  The core issue is that the combinatorial
semantics of a fine-grained model makes it much much easier to make critical
mistakes.  It also makes it harder to understand.

The current Zope model is exceptionally fine-grained by most people's
standards, in that it allows you to apply permissions on a per-object basis.
The only thing more "fine grained" one might want is to control a specific
method on a specific object, but even this can be done using a Proxy role on
another object.

>>> This would enable any system user to create, manage, and use system
>>> security capabilities.  A user could then share one file from their
>>> Member Folder with other select system users.  They could also allow
>>> only a subset of these users to "vouch" for access by other not
>>> originally on the list.  This could be a very lightweight list of
>>> "locks" associated with each resource and list of "keys" associated
>>> with any consumer of a resource.  Your SSL enabled creation of a
>>> cookie token would be just a special case of one of these "keys".
>>> Each "Key" would have a TTL and a set of resource locks it might
>>> be able to open.
>> 
>> Way out of the scope of this discussion, so I won't even
>> address it.  This
>> is largely doable today with local roles.
> 
> OK, As I understand more about Zope security and roles, I would
> like to revisit this item.

My point was you are asking about an application level instantiation of some
security model at this point. We are discussing the model itself.

> Sharing credentials between sites is likely a pipe dream so
> ignore that crud.

This is simply a technical restriction of the current system.  If you use
PKI-style client certificates then you already do share "credentials,"
however there is a pretty heavy cost to doing so.

Chris
-- 
| Christopher Petrilli        Python Powered        Digital Creations, Inc.
| petrilli@digicool.com                             http://www.digicool.com