authentication levels in the ACM

[robert byrne <robert.byrne@Sun.COM>]

Folks,

The issue of authentication levels versus mechanisms has come up again.

The history on this is that the model started with levels, went to
mechanisms and now has moved back to levels.

To help us try to reach concensus on this, here are three options and I
try to list some pros and cos of each of the options.

1. Remove reference to authentication levels and mechanisms.

This way, the model would not be capable of exressing anything
concerning the authentication method or strength of a user.  The policy
of authentication requirements on users would be external to the model.

Pro: 
  1. simplifies the ACM
  
Con:
  1. authentication is a basic notion for authorization and so it's
natural to want to express it in the ACM.

--

2. Go back to a list of mechanisms with no "strength ordering" among
     the mechanisms.

This way an aci subject would have to specify a list authentication
mechanisms.  There would be special keywords "none" and "authenticated"
to mean "no authentication" and "some kind of authentication".

Pro:
 1. can force a given authzID to use a given mechanism.

Con: 
 1. As no ordering is defined on mechanisms, the model cannot
automatically give you behaviour you might expect: eg. if an aci
authorizes me when I bind with DIGEST-MD5, I might be surprised to find
that when I bound using SSL that it did not grant me that right.  The
implication is that at grant aci create time the admin needs to list
_all_ the mecahanisms he wishes to grant rights.  For deny, he needs to
consider the possibility of the subject of his deny coming in using a
different, "less strong", authentication mechanism with a potentially
different authorizationId.

--

3. Stick with authentication levels and a "strength hierarchy"

Pro:
  1. The model can make use of the "strength hierarchy" in defining
      ACI semantics (e.g. a deny applies to ALL subjects at lower
      authnLevel).
 2. Once the mechanisms are put in the buckets, the admin of acis is
easier--just choose beteen the four levels rather than lots of
mechanisms.

Con:
  1. Assignment of mechanisms to levels is on a per-server basis, but
      we could define a way for servers to advertise their assignments
      (for example to help with replication).
 2. No way to associate a particular user with a particular mechanism.

Cast your vote now!  Otherwise we will default to 3, which is the
current flavour.

Rob.