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

[Chip Vanek]

Hi,

>-----Original Message-----
>From: Christopher Petrilli [mailto:petrilli@digicool.com]
>Sent: Friday, February 11, 2000 1:42 PM
>To: Chip Vanek; zope-ptk@zope.org
>Subject: Re: [Zope-PTK] PROPOSAL: A Confidence Mechanism in User
>RoleManagement
>
>
>On 2/11/00 1:30 PM, Chip Vanek at chip@upcast.com wrote:
>
>> I love this Confidence Rheostat!  Along with an integrated content
>> tagging framework you can really tailor security to need.
>
>We already have this, just to be clear.  It's based on Permissions on
>objects interacting with Roles.  Did you intend another 
>"framework" that
>isn't there at this point?
>

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

>> Your POST via SSL & volatile cookie/tokens make it work.  I just have
>> couple of concerns and one addition.  I am just seeing this thread
>> so forgive me if this has been asked and answered.
>
>This is a common paradigm actually, used by a bunch of people 
>;-) I hardly
>thought this idea up... though I should patent it anyway! :-)
>
>> Would this mechanism allow for chaining of access requests?  
>Something
>> analogues to "Oh, you want to see THAT file, well I don't know but,
>> I know you does, hang on.."  So specific resources or capabilities
>> would delegate access authorization to other systems.
>
>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.

>> Can this dynamic security mechanism store different confidence
>> levels for different conditions?  Multiple user logon in one
>> 6 hour period from client location in time zone 10 hours apart
>> could trigger higher required confidence.
>
>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.
>
>> With these type of fundamental security model changes it would be
>> great to enable a very fine grained distributed security model.
>
>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;).

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

>
>> I am sure that all of this is way more then you had in mind to solve.
>
>It needs to have a problem to solve first that is more than 
>hypothetical I
>believe.
>
>> At the least I would hope that this mechanism would allow any two
>> portals to share the client cookies confidence level.
>
>How? Cookies are URI specific.
>
>> I understand that
>> there needs to be distinct cookies for each site and each 
>client machine.
>
>Yes. So what exactly have you gained?

Nothing, stupid idea...

>
>> The target would be to simplify the life of an honest users 
>you is the
>> member of multiple portal communities and uses multiple machines.
>
>I believe a documented case of said complexity would be a good starting
>point.  What complexity are you simplifying?
>
>> A ring of cooperating portals could automagically generate a 
>new cookie
>> if a valid cookie from a brother portal was found.  Actually 
>this last
>> idea seems totally undoable but, the need still exists.
>
>How would they find this cookie? It's not available to any 
>portal but the
>one who created it.  I'm not convinced the need exists based 
>on any stated
>requirement. 
>

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

>> Sorry for the long message.  In any case, if your proposal could be
>> quickly implemented it would be so much better then the way 
>things work now.
>
>Let's try and stay focused on a goal driven system, I think 
>this is critical
>to success and leave the "wild blue sky" for later.
>
>Chris
>-- 
>| Christopher Petrilli        Python Powered        Digital 
>Creations, Inc.
>| petrilli@digicool.com                             
http://www.digicool.com


Agreed,  

Chip