Getting Mailman to use KX509 authentication

Some jottings on the changes necessary to make mailman work with KX509 auth. The mail team are tracking this as bug_small.png Bug #1027

  • Run mailman within an opportunistically authenticating kx509 environment. This means that if the user has kx509 credentials then we resolve them to create a REMOTE_USER variable, but if they don't we let them continue on their way.
  • Add support for checking the REMOTE_USER variable to WebAuthenticate. This is complicated by the issue of mapping authentication identity to email address - see discussion below.
  • Add support for returning the email address of the currently authenticated user.
  • Patch Cgi/options.py to accept the current user's email address from the web server environment if its not present in the CGI variables
  • Patch Cgi/options.py to not display a 'Log Out' button if we're logged in via REMOTE_USER.
  • Patch HTMLFormatter.py to not prompt for a username and password to view a subscribers list where that list is available due to the current user's authentication

These changes allow all 'ordinary' mailman activities to be authenticated via kx509. It doesn't extend to site administration acts, or to list deletion. In order to handle site administration, we'd need to find a way of defining an 'administrator' identity, which we could then compare REMOTE_USER to. List deletion could be handled by modifying Cgi/rmlist.py to call EnterpriseWebAuthenticate in addition to its call to Authenticate.

Authentication Realms

One complication is that REMOTE_USER contains only the username (sxw, rather than sxw@INF.ED.AC.UK), when what we need is to know the email address. There are a number of ways to get around this, with varying complexities:

  • Using kx509 we can pass a full email address by pulling out a different part of the certificate. To do this, we simply configure add AuthSSLDNComponent SSL_CLIENT_S_DN_Email (rather than the current SSL_CLIENT_S_DN_UID.However, this doesn't extend to other authentication schemes that expect the username to be a username. Also, kx509 is already abusing the Email component of the certificate - it contains the Kerberos principal, which just happens to look like an email address!
  • We can just store a default 'authentication domain' in which we consider all authenticated users to have email addresses.
  • We have a default domain as above, but expand users of the form a%b.c to a@bREMOVE_THIS.c without appending the doman. This caters for the lightweight account case, avoiding the directory lookup described below.
  • We add a directory lookup to check the email address associated with a given username. We store the required information to do this in LDAP already, but it would add an LDAP dependency to mailman that some people may be keen to avoid.

-- SimonWilkinson - 03 Apr 2005

Topic revision: r5 - 03 Apr 2005 - 23:37:28 - SimonWilkinson
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies