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

Phillip J. Eby pje@telecommunity.com
Wed, 09 Feb 2000 15:27:45 -0500


At 02:29 PM 2/9/00 -0500, Christopher Petrilli wrote:
>
>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?

Let's say you have:

* LoginMethod 3: Token cookie w/SSL
* LoginMethod 2: Basic auth
* LoginMethod 1: REMOTE_USER auth

If they are checked in this order, Loginmethod 3 checks if the request is
SSL and there's a valid token cookie.  If not, it passes and LoginMethod 2
checks for basic auth.  If basic auth isn't there or doesn't match, it
drops to LoginMethod 1.  If LoginMethod 1 sees a REMOTE_USER environment
variable, it asks a UserSource for the user object, and then asks the user
object to authenticate based on the credentials the LoginMethod extracted
from the request.  The LoginMethod does *not* "authenticate" the user,
(with the current exception of the REMOTE_USER LoginMethod, which avoids
calling the user's authenticate() method since authentication has been done
by the web server).

LoginMethods are pluggable seperately from UserSources, and it is the
UserSources (and user objects themselves) that determine roles.


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

It's seperate.  Actually, it sounds like you might want to have the
LoginMethod have a way to tell the user object where it got the credentials
from.  But probably confidence as well as roles are a function of the
user/UserSource objects to determine.  I'd prefer to keep LoginMethods as
just strategy objects for dealing with the mechanics of marshalling
authentication data from the REQUEST.



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

I think he means client certificates, although it's entirely possible that
you could create a custom LoginMethod for a specialized application.


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

We do mix and match authentication now.  That's one of the key ideas behind
the UUF (now called Login Manager), is that it eliminates the N x M problem
of writing UserFolders for N login methods and M sources of user data.  But
the design currently leaves roles entirely to the user objects, which in
turn can delegate that to their UserSource if appropriate for the specific
implementation.


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

So, should we have loginMethods have a confidence property that gets passed
to the user object with the authenticate() operation?  (The user can treat
it additively, if that's what's desired.)  Or do user objects not care what
the login method is?  Now would be a good time to know before the protocols
get any more hardened.