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