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

[Mike Pelletier]

    This is pretty neat.  I explored accomplishing a number of the goals
this enables with the UniversalUserFolder stuff Ty and Phillip are working
on.  Instead of each loginMethod (the back end which authenticates a user)
returning a confidence value, they are arranged in the order of the
confidence we have in that method's method of authenticating a user, most
confident to least confident.  The first one that returns a user object is
the one you use.  Since the loginMethod itself returns the user object,
you have the ability to munge the user beforehand, constraining the roles
to whatever is appropreate for the method you used.  If you try to do
something for which you have the 'granted roles' but not the 'available
roles', the login interface is presented (retina scanner prompts you,
whatever) and you have the opportunity to authenticate yourself with
higher confidence and so receive the needed roles to continue.

    For instance, the first loginMethod may look for a digital signature
(granting access to sensitive company and personal data), the second may
look for a password (granting access to sensitive personal data), and the
third may just look for some sort of identity cookie (granting access to
no sensitive data, but putting the user's preferences into effect).

    The role-munging hasn't received any formal treatment in the UUF, but
I see that maybe it should.  Perhaps instead of actual munging, the
loginMethod should be able to specify the restrictions, which are applied
by getRoles or something.

    What I like about this system is it doesn't have a confidence int.  
Perhaps it's just my bias speaking, or I may be missing some key point,
but I don't like arbitrary scales like this.  I much prefer to use some
sort of (possibly extensible) enumeration, such as a list of strings, to
express graduations like this.  That way every possible value has a
defined meaning.  I don't necisarilly know that all subsets of the
possible set of confidence values are 'calibrated' the same.  That is, the
difference between 10 and 11 and the difference between 99 and 100 could
be and probably are significantly different.  'Add 10 to your confidence'
is pretty meaningless.  I have no idea what the actual result of that
action will be.  I'd have to know what each confidence level actually
means, and then I'd end up doing something like 'upgrade_confidence(50 -
get_confidence())' which seems to defeat the purpose of the interface,
though I admit I'm not certain what the purpose is.

    What are the advantages of using a confidence value over
confidence-sorted loginMethods?



    The rest just out of personal interest.

    Your document states:

	"In addition, it may (and should) be important to differentiate
	the method by which these credentials are presented. A password
	sent as clear text may be less trustworthy than one sent over an
	SSL session. One might even argue that one sent over a 40-bit SSL
	session is less trustworthy than one sent over 128-bit SSL. These
	are all security officer decisions in the process of risk
	mitigation."

    Shouldn't receiving a cleartext password constrain the upper bound
that this user's confidence can EVER attain, until the password has been
securely changed?  Or does SSL not use the same password to authenticate?  
(I don't know a lot about how SSL works, or what services it provides.)


-- 
Mike Pelletier                          email: mike@digicool.com
Mild mannered software developer          icq: 7127228
by day, super villain by night.         phone: 519-884-2434