[Zope-PTK] PROPOSAL: A Confidence Mechanism in UserRoleManagement

Chip Vanek chip@upcast.com
Sat, 12 Feb 2000 12:56:33 -0800


>-----Original Message-----
>From: Christopher Petrilli [mailto:petrilli@digicool.com]
>Sent: Saturday, February 12, 2000 7:46 AM
>To: Chip Vanek; zope-ptk@zope.org
>Subject: Re: [Zope-PTK] PROPOSAL: A Confidence Mechanism in
>UserRoleManagement
>
>
>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.

Yup, after I get some of this initial work on PTK done I will
focus my attention on the existing security model.  I am sure that
it is very capable but for me not yet "self-revealing" ;)

>
>>> 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.

It was the different view of the same data element that I was
trying to express.  I would like to allow users to see certain new
items via their cell phone browsers or wireless PDAs.  They should
also be able to add new content or reply using wireless pages or
popup forms on other websites.  

>
>>> 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.

Thanks!  I have been reading a number of ideas in the space including 
the work at www.erights.org.  With inclusion of some of these attributes
Zope could become a killer app.

>
>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.
>

Aboslutely,  One of the things that attracted me to Zope was the secure
exposing of individual objects to the web.  I am still far from fully 
understanding how this works now but, would like to keep tabs on your work
as motivation to get "myself up to speed."


>>>> 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.
>

The interplay between local roles and Zope security is still not
"self revealing" to me yet.  I hope to clear up my mental fog soon...


>> 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.
>

It is cost of using ful scale PKI that I am trying to avoid.  I spend
3 years fighting to get a full PKI infrastructure in place inside
Hewlett-Packard and still feel the scars.  They now have over 50k
certificates and a CA linked to a master directory or all 125k users
but, I no longer have any love for a corporate IT job.  

Best,

Chip


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