[Zope3-dev] Re: principals vs. users

[Jeremy Hylton]

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

  >> Jim and I talked a few days ago about compound principals which
  >> may be what motivates his comment.  A compound principal is one
  >> of the form "SSL connection as Guido" where the SSL connection is
  >> the principal on the local machine that speaks for Guido.  It is
  >> typical to check that the SSL connection actually speaks for
  >> Guido and then just reason about Guido.
  >>
  >> But there may be circumstances where you want to associated
  >> permissions with the compound principal itself.  For example, to
  >> distinguish between Guido logged in using http and Guido logged
  >> in using https.  (Amazon.com does something like this.)

  GvR> Are we calling these two different principals?  Or are they the
  GvR> same principal with different strengths of authentication?  I
  GvR> think the point is that they are the same principal, but that
  GvR> our level of trust differs depending on how they authenticated
  GvR> themselves (and on how much we trust the security of the
  GvR> connection).

I think it's important that we not confuse principal with user/human.
In Unix, username corresponds to principal, but I don't think Unix
security is a very good match for Zope.  It's too simple.

They are different principals.  A principal is the unit of accounting
in an authentication system and we would want to account for them
differently.  The fact that there are two different channels used for
communication means there are two different principals.  The logic of
our authentication may allow us to prove that the two different
principals speak for the same principal, but not that they are, in
fact, indentical.

See:

B. Lampson, M. Abadi, M. Burrows, and E. Wobber. Authentication in
distributed systems: Theory and practice.  ACM Trans. Computer Systems
10, 4 (Nov. 1992), pp 265-310.

http://research.microsoft.com/lampson/45-AuthenticationTheoryAndPractice/Abstract.html

  >> >> o Risks of client-side trojan attacks will be partly
  >> >>   mitigated.
  >>
  GvR> How?
  >>
  >> If you log in using your "sys admin" role, you may not have
  >> permission to edit documents that requires your "editor" role.
  >> And vice versa.  It limits your vulnerability to a single role's
  >> permissions rather than all of them.

  GvR> Hm, but if log in with an editor role, I still have view
  GvR> permissions on other pages that might contain a client-side
  GvR> trojan.  I don't see how it solves the problem, although it may
  GvR> reduce it somewhat.

I don't see that it solves the problem either.  It reduces the set of
permissions that you are using at any one time, which may reduce the
damage done by the attack.

Jeremy