[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:
 > On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
 > > Richard Wackerbarth writes:

 > >> Since we consider the user manager to be a part of the MM complex,
 > >> what have we gained by hiding the underlying credential from the
 > >> web interface?
 > > 
 > > Security.  See the OAuth 2.0 spec (RFC 6749) which recommends (at
 > > SHOULD level) this practice.
 > 
 > RFC 6749 addresses the implementation of an OAuth authorization
 > system.
 > 
 > In this context, SHOULD refers to the implementation of this RFC.
 > 
 > It does not imply that other authorization schemes also need to
 > meet those same criteria.

True, but logically irrelevant: it does not mean that the
recommendations of the RFC are irrelevant in the design of
authorization schemes.

OAuth has reasons for recommending that you avoid passing user-
supplied credentials around.  These include (among others I haven't
the imagination to supply here, I'm sure)

(1) privacy of the user (the component the user wants access to may
    have no need to know who the user is)
(2) security of the user credentials (leaking the auth token does not
    allow an attacker to access all resources the user is authorized
    for)
(3) the accessed component doesn't know the importance of the user
    credentials (the user may have used the same password in several
    systems, or the user may have very high privileges in other parts
    of this system), increasing the risk involved in (2).

I see no reason to suppose Mailman is not subject to these
considerations.  (3) is certainly relevant, as I know that I am
simultaneously a site owner, a list owner, a moderator, and a
subscriber for some lists.

There is a plausible workflow in which a user (who happens to be a
list owner) who is browsing the archives is given a subscriber-level
token, and when they decide to access a list admin page, they need to
re-authenticate to upgrade their authorization to list owner.  If they
then access a non-admin page, or they time out before accessing
another admin page, the owner-level token is downgraded to a
subscriber token.  (This is like sudo on POSIX systems.)

I'm not arguing that Mailman should default to such a workflow, but I
think we should be able to support it.  Passing around user
credentials makes it harder to audit such a workflow.

 > As for security, exposing the authorization server to direct
 > Internet access is, in itself, a security weak point.

I wouldn't say necessarily "weak", but it certainly expands the attack
surface that needs to be defended.  That's why I don't want to include
an auth server implemented by security amateurs (us!)