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

[Chip Vanek]

Hi,
Opps, I sent this to the wrong list last night.

Cc: zope@zope.org
Subject: [Zope] RE: [Zope-PTK] PROPOSAL: A Confidence Mechanism in User
Role Management


I love this Confidence Rheostat!  Along with an integrated content
tagging framework you can really tailor security to need.  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.

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.

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.

With these type of fundamental security model changes it would be
great to enable a very fine grained distributed security model.  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.

I am sure that all of this is way more then you had in mind to solve.
At the least I would hope that this mechanism would allow any two
portals to share the client cookies confidence level.  I understand that
there needs to be distinct cookies for each site and each client machine.
The target would be to simplify the life of an honest users you is the
member of multiple portal communities and uses multiple machines.  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.

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.

Best,

Chip Vanek
chip@upcast.com

>-----Original Message-----
>From: zope-ptk-admin@zope.org [mailto:zope-ptk-admin@zope.org]On Behalf
>Of Christopher Petrilli
>Sent: Thursday, February 10, 2000 6:08 AM
>To: Rob Page; Mike Pelletier
>Cc: zope-ptk@zope.org
>Subject: Re: [Zope-PTK] PROPOSAL: A Confidence Mechanism in User Role
>Management
>
>
>On 2/9/00 11:47 PM, Rob Page at rob.page@digicool.com wrote:
>
>>> So, if cleartext is less trustworthy because it's sniffable, it
>>> follows that using cleartext once compromises the secure
>>> channels as well, and so they should be no more trusted
>than cleartext
>> UNTIL
>>> the password's been changed.  Oh.  But, if you are now
>> less-than-confident
>>> of the remote user, you can't let them change the password so as to
>> become trusted
>>> again!  D'oh.  Seems like a Catch 22, I must not be getting
>something.
>>
>> This is a valid point.  This is why many sites have you
>login over SSL.
>> Perhaps they assign you an expiring cookie which you can carry around
>> and over unsecure channels.  Ideally, password specification and
>> password presentation are all done over secure comm - then you don't
>> have to discount the confidence in the password as an accurate
>> authentication mechanism.
>
>This is what I was mentioning at the bottom of another email,
>which is that
>you have the following chain of events:
>
>    * User is presented a login form over HTTP
>    * Form is POSTED via SSL, which sets a cookie in the browser
>    * Cookie is volatile and used for auth during session
>
>The cookie must be something non-guessable, so I proposed the
>following:
>
>    base64(sha1(username + ip_address + random_int))
>
>This gives you a token that should not be "guessable" and in
>addition, as
>long as you keep the random integer chosen around, you can
>validate that the
>cookie is valid using 2 options:
>
>    * Recompute auth information and compare (the correct way,
>long story)
>    * Store IP address and precalced cookie, and compare those.
>
>Chris
>--
>| Christopher Petrilli        Python Powered        Digital
>Creations, Inc.
>| petrilli@digicool.com
http://www.digicool.com


_______________________________________________
Zope-PTK maillist  -  Zope-PTK@zope.org
http://lists.zope.org/mailman/listinfo/zope-ptk



_______________________________________________
Zope maillist  -  Zope@zope.org
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )