next up previous contents index
Next: 13. Authorization scenarios Up: Sympa Mailing Lists Management Software version Previous: 11. Sympa SOAP server   Contents   Index

Subsections


12. Authentication

Sympa needs to authenticate users (subscribers, owners, moderators, listmaster) on both its mail and web interface to then apply appropriate privileges (authorization process) to subsequent requested actions. Sympa is able to cope with multiple authentication means on the client side and when using user+password it can validate these credentials against LDAP authentication backends.

When contacted on the mail interface Sympa has 3 authentication levels. Lower level is to trust the From: SMTP header field. A higher level of authentication will require that the user confirms his/her message. The strongest supported authentication method is S/MIME (note that Sympa also deals with S/MIME encrypted messages).

On the Sympa web interface (WWSympa) the user can authenticate in 4 different ways (if appropriate setup has been done on Sympa serveur). Default authentication mean is via the user's email address and a password managed by Sympa itself. If an LDAP authentication backend (or multiple) has been defined, then the user can authentication with his/her LDAP uid and password. Sympa is also able to delegate the authentication job to a web Single SignOn system ; currently CAS (the Yale University system) or a generic SSO setup, adapted to SSO products providing an Apache module. When contacted via HTTPS, Sympa can make use of X509 client certificates to authenticate users.

The authorization process in Sympa (authorization scenarios) refers to authentication methods. The same authorization scenarios are used for both mail and web accesss ; therefore some authentication methods are considered as equivalent : mail confirmation (on the mail interface) is equivalent to password authentication (on the web interface) ; S/MIME authentication is equivalent to HTTPS with client certificate authentication. Each rule in authorization scenarios requires an authentication method (smtp,md5 or smime) ; if the required authentication method was not used, a higher authentication mode can be requested.

12.1 S/MIME and HTTPS authentication

Chapter 26.2 (page [*]) deals with Sympa and S/MIME signature. Sympa uses OpenSSL library to work on S/MIME messages, you need to configure some related Sympa parameters : 26.4.2 (page [*]).

Sympa HTTPS authentication is based on Apache+mod_SSL that provide the required authentication information via CGI environment variables. You will need to edit Apache configuration to allow HTTPS access and require X509 client certificate. Here is a sample Apache configuration

SSLEngine on
SSLVerifyClient optional
SSLVerifyDepth  10
...
<Location /sympa>
   SSLOptions +StdEnvVars
   SetHandler fastcgi-script
</Location>


12.2 Authentication with email address, uid or alternate email address

Sympa stores the data relative to the subscribers in a DataBase. Among these data: password, email exploited during the Web authentication. The module of LDAP authentication allows to use Sympa in an intranet without duplicating user passwords.

This way users can indifferently authenticate with their ldap_uid, their alternate_email or their canonic email stored in the LDAP directory.

Sympa gets the canonic email in the LDAP directory with the ldap_uid or the alternate_email. Sympa will first attempt an anonymous bind to the directory to get the user's DN, then Sympa will bind with the DN and the user's ldap_password in order to perform an efficient authentication. This last bind will work only if the good ldap_password is provided. Indeed the value returned by the bind(DN,ldap_password) is tested.

Example: a person is described by

                 Dn:cn=Fabrice Rafart,
                 ou=Siege ,
                 o=MaSociete ,
                 c=FR Objectclass:
                 person Cn: Fabrice Rafart
                 Title: Network Responsible
                 O: Siege
                 Or: Data processing
                 Telephonenumber: 01-00-00-00-00
                 Facsimiletelephonenumber:01-00-00-00-00
                 L:Paris
                 Country: France

		 uid: frafart
 		 mail: Fabrice.Rafart@MaSociete.fr
                 alternate_email: frafart@MaSociete.fr
                 alternate:rafart@MaSociete.fr

So Fabrice Rafart can be authenticated with: frafart, Fabrice.Rafart@MaSociete.fr, frafart@MaSociete.fr,Rafart@MaSociete.fr. After this operation, the address in the field FROM will be the Canonic email, in this case Fabrice.Rafart@MaSociete.fr. That means that Sympa will get this email and use it during all the session until you clearly ask Sympa to change your email address via the two pages : which and pref.


12.3 Generic SSO authentication

The authentication method has first been introduced to allow interraction with Shibboleth, Internet2's inter-institutional authentication system. But it should be usable with any SSO system that provides an Apache authentication module being able to protect a specified URL on the site (not the whole site). Here is a sample httpd.conf that shib-protects the associated Sympa URL :

...
<Location /sympa/sso_login/inqueue>
  AuthType shibboleth
  require affiliation ~ ^member@.+
</Location>
...

Sympa will get user attributes via environment variables. In the most simple case the SSO will provide the user email address. If not, Sympa can be configured to verify an email address provided by the user hiself or to look for the user email address in a LDAP directory (the search filter will make use of user information inherited from the SSO Apache module).

To plug a new SSO server in your Sympa server you should add a generic_sso paragraph (describing the SSO service) in your auth.conf configuration file (See 12.5.3, page [*]). Once this paragraph has been added, the SSO service name will be automatically added to the web login menu.

Apart from the user email address, the SSO can provide other user attributes that Sympa will store in the user_table DB table (for persistancy) and make them available in the [user_attributes] structure that you can use within authorization scenarios (see 13.1, page [*]) or in web templates via the [% user.attributes %] structure.


12.4 CAS-based authentication

CAS is Yale university SSO software. Sympa can use CAS authentication service.

The listmaster should define at least one or more CAS servers (cas paragraph) in auth.conf. If non_blocking_redirection parameter was set for a CAS server then Sympa will try a transparent login on this server when the user accesses the web interface. If one CAS server redirect the user to Sympa with a valid ticket Sympa receives a user ID from the CAS server. It then connects to the related LDAP directory to get the user email address. If no CAS server returns a valid user ID, Sympa will let the user either select a CAS server to login or perform a Sympa login.


12.5 auth.conf

The /home/sympa/etc/auth.conf configuration file contains numerous parameters which are read on start-up of Sympa. If you change this file, do not forget that you will need to restart wwsympa.fcgi afterwards.

The /home/sympa/etc/auth.conf is organised in paragraphs. Each paragraph describes an authentication service with all required parameters to perform an authentication using this service. Current version of Sympa can perform authentication through LDAP directories, using an external Single Sign-On Service (like CAS or Shibboleth), or using internal user_table.

The login page contains 2 forms : the login form and the SSO. When users hit the login form, each ldap or user_table authentication paragraph is applied unless email adress input from form match the negative_regexp or do not match regexp. negative_regexp and regexp can be defined for earch ldap or user_table authentication service so administrator can block some authentication methode for class of users.

The segond form in login page contain the list of CAS server so user can choose explicitely his CAS service.

Each paragraph start with one of the keyword cas, ldap or user_table

The /home/sympa/etc/auth.conf file contains directives in the following format:

paragraphs
keyword value

paragraphs
keyword value

Comments start with the # character at the beginning of a line.

Empty lines are also considered as comments and are ignored at the beginning. After the first paragraph they are considered as paragraphs separators. There should only be one directive per line, but their order in the paragraph is of no importance.

Example :

#Configuration file auth.conf for the LDAP authentification
#Description of parameters for each directory


cas
	base_url			https://sso-cas.cru.fr
	non_blocking_redirection        on
	auth_service_name		cas-cru
	ldap_host			ldap.cru.fr:389
        ldap_get_email_by_uid_filter    (uid=[uid])
	ldap_timeout			7
	ldap_suffix			dc=cru,dc=fr
	ldap_scope			sub
	ldap_email_attribute		mail

## The URL corresponding to the service_id should be protected by the SSO (Shibboleth in the exampl)
## The URL would look like http://yourhost.yourdomain/sympa/sso_login/inqueue in the following example
generic_sso
        service_name       InQueue Federation
        service_id         inqueue
        http_header_prefix HTTP_SHIB
        email_http_header  HTTP_SHIB_EMAIL_ADDRESS

## The email address is not provided by the user home institution
generic_sso
        service_name               Shibboleth Federation
        service_id                 myfederation
        http_header_prefix         HTTP_SHIB
        netid_http_header          HTTP_SHIB_EMAIL_ADDRESS
	internal_email_by_netid    1
	force_email_verify         1

ldap
	regexp				univ-rennes1\.fr
	host				ldap.univ-rennes1.fr:389
	timeout				30
	suffix				dc=univ-rennes1,dc=fr
	get_dn_by_uid_filter		(uid=[sender])
	get_dn_by_email_filter		(|(mail=[sender])(mailalternateaddress=[sender]))
	email_attribute			mail
	alternative_email_attribute	mailalternateaddress,ur1mail
	scope				sub
	use_ssl                         1
	ssl_version                     sslv3
	ssl_ciphers                     MEDIUM:HIGH

ldap
	
	host				ldap.univ-nancy2.fr:392,ldap1.univ-nancy2.fr:392,ldap2.univ-nancy2.fr:392
	timeout				20
	bind_dn                         cn=sympa,ou=people,dc=cru,dc=fr
	bind_password                   sympaPASSWD
	suffix				dc=univ-nancy2,dc=fr
	get_dn_by_uid_filter		(uid=[sender])
	get_dn_by_email_filter			(|(mail=[sender])(n2atraliasmail=[sender]))
	alternative_email_attribute	n2atrmaildrop
	email_attribute			mail
	scope				sub
        authentication_info_url         http://sso.univ-nancy2.fr/
	

user_table
	negative_regexp 		((univ-rennes1)|(univ-nancy2))\.fr

12.5.1 user_table paragraph

The user_table paragraph is related to sympa internal authentication by email and password. It is the simplest one the only parameters are regexp or negative_regexp which are perl regular expressions applied on a provided email address to select or block this authentication method for a subset of email addresses.

12.5.2 ldap paragraph


12.5.3 generic_sso paragraph

The following parameters define how Sympa can verify the user email address, either provided by the SSO or by the user himself :

The following parameters define how Sympa can retrieve the user email address ; these are only useful if the email_http_header entry was not defined :

12.5.4 cas paragraph


12.6 Sharing WWSympa authentication with other applications

If your are not using a web Single SignOn system you might want to make other web applications collaborate with Sympa, and share the same authentication system. Sympa uses HTTP cookies to carry users' auth information from page to page. This cookie carries no information concerning privileges. To make your application work with Sympa, you have two possibilities :


12.7 Provide a Sympa login form in another application

You can easily trigger a Sympa login from within another web page. The login form should look like this :

<FORM ACTION="http://listes.cru.fr/sympa" method="post">
      <input type="hidden" name="previous_action" value="arc" />
      Accès web archives of list
      <select name="previous_list">
      <option value="sympa-users" >sympa-users</option>
      </select><br/>

      <input type="hidden" name="action" value="login" />
      <label for="email">email address :
      <input type="text" name="email" id="email" size="18" value="" /></label><br />
      <label for="passwd" >password :
      <input type="password" name="passwd" id="passwd" size="8" /></label> <br/>
      <input class="MainMenuLinks" type="submit" name="action_login" value="Login and access web archives" />
</FORM>

The example above does not only perform the login action but also redirects the user to another sympa page, a list web archives here. The previous_action and previous_list variable define the action that will be performed after the login is done.


next up previous contents index
Next: 13. Authorization scenarios Up: Sympa Mailing Lists Management Software version Previous: 11. Sympa SOAP server   Contents   Index
root 2006-04-12