[Zope-PTK] Stability rule-of-thumb (fwd)

[Stuart 'Zen' Bishop]

On Thu, 3 Feb 2000, Phillip J. Eby wrote:

> >Hehe... 'a folder containing the appropriate methods' is quite an
> >apt description of GUF in its present state. If you develop this, GUF can 
> >be frozen and depricated provided the hooks are called using the DTML Method 
> >calling conventions (context,REQUEST as the first two parameters)
> 
> with a model for a "Universal User Folder" that we're going to try and
> document Real Soon Now (like starting tomorrow).  The validation bits of
> GUF could be recast as a validator, and the rest could pretty much go away.
>  The model looks something like this:

One thing to think of (cut & paste from previous email with Michael):

    The original design and scope of GUF was to allow seperation of the 
    following:
	authentication (username & password)
	authentication (valid domains)
	authorization (role membership)
	listing valid users

    In particular, I needed to pull a list of users and role membership from
    my Oracle server, and dynamically authenticate via one of two Radius
    servers (choice of Radius server being dependant on role membership - thus
    GUF had to support arbitrary code).

    So in an ideal world, we would need four pluggable components:
	userList + userExists
	userRoles
	userAuthenticate
	userDomains

    A pluggable backend (a buttplug?) would need implement one or more of these
    hooks. The pluggable backend would actually be 1-5 classes that implement
    the __call__ method (so they can be dropped in instead of the default DTML
    methods)

    GUF needs to be able to handle multiple backends. For example, a Radius
    backend could only ever implement the userAuthenticate hook, so would
    also need to be combined with another.

Do you envisage being able to support a backend like Radius that can
only handle part of the role of a validator? Or will situations like
this require a GUF-like validator (folder containing DTML/Python/External
methods)?

Being able to mix'n'match backends would increase power, but decrease
friendlyness (a requirement for PTK).

> 	* has validate() method which strictly looks at the request for
> authentication tokens (e.g. cookies) or login fields

It would be nice if the UUF would also try breaking down the cookies/login
fields for you. Most of the validators would prefer just being able to
say yes/no to a username & password combination rather all of them
needing the intelligence to decode the cookie,basic auth and form data.
It can be done securely once rather than cut & paste, and validators
would instantly support new authentication-passing mechanisms.

It would also be nice if you stole my token authentication code and made
it an option so we can turn off storing username & password in the cookies.
One advantage besides security of this method is that Zope can determine if
a username/password combination is valid rather than having to talk to
a possibly slow validator. Spamming my Radius or NDS servers with a request 
for every hit is really not an option. Username/password caching cannot
be done for systems using any sort of one-time password scheme.

-- 
 ___
   //     Zen (alias Stuart Bishop)     Work: zen@cs.rmit.edu.au
  // E N  Senior Systems Alchemist      Play: zen@shangri-la.dropbear.id.au
 //__     Computer Science, RMIT 	 WWW: http://www.cs.rmit.edu.au/~zen