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

[Christopher Petrilli]

On 2/9/00 1:50 PM, Mike Pelletier at mike@digicool.com wrote:

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

I believe that anything based on this chaining is going to be difficult to
explain, but perhaps what I've don is difficult as well.  How do you know
when to stop trying to authenticate? Or do you only take one step at a time?
Confidence is an important concept in the security world, and so I think its
critical to keeping the "authentication method" SEPERATE from the Roles
granted.  Blurring these is a sure recipe for confusion and holes.

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

Um, how prey tell will a digital signature work over the Web? FTP? There's
no protocol for this, no expressive capability.  Or did you mean a X.509v3
certificate for client-authentication?  These are quite different
manifestations of a cryptographic protocol.

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

Hmm, I think these two ideas should not be combined.  The determination of
Roles is a "confidence" issue, not directly a result of authentication.  If
you were to mix and match authentication in the future, you'd still have a
problem with understanding the interaction of roles.

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

They are calibrated by the security office, otherwise you are dictating
things to the security officer.  We could provide guidelines, but many
people have different risk vectors they are willing to accept or mitigate as
they see appropriate to their environment.  Call it 0-10 if you wish, call
it red, orange, yellow, green, blue, indigo, violet, call it the periodic
table of elements, it ends up being an arbitrary scale regardless, unless
you dictate the security policy of the organization from a software
perspective. 

The purpose is not think about the number, bu your requirement, in
retrospect, get_confidence() shouldn't exist.  Because developers might do
what you're arguing which is distinctly non OO in my opinion.   My mistake.

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

Issues of abstraction and the fact that login methods create confidence, and
you might change them around as technology/policy changes, but that Roles
are metric driven, not authentication method driven.  The two are largely
detached, and I believe out of distinct necessity.

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

Securely changed?  I'm no sure I follow.  SSL is a cryptographic system for
private transmission of data, it MAY provide an authentication mechanism
using X.509v3 public key certificates.

Chris
-- 
| Christopher Petrilli        Python Powered        Digital Creations, Inc.
| petrilli@digicool.com                             http://www.digicool.com