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

[Christopher Petrilli]

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?

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

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

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

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

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

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

> 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