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.
Chapter 19.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 : 19.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 /wws> SSLOptions +StdEnvVars SetHandler fastcgi-script </Location>
Sympa stores the data relative to the subscribers in a DataBase. Among these data: password, email exploited during the Web authentication. The module of 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 directory.
Sympa gets the canonic email in the 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.
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 /wws/sso_login/inqueue> AuthType shibboleth require affiliation ~ ^member@.+$ </Location> ...
The SSO is also expected to provide user attributes including the user email address as environment variables. To make the SSO appear in the login menu, a textbf generic_sso paragraph describing the SSO service should be added to auth.conf. The format of this paragraph is described in the following section.
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 9.1, page ).
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.
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 host sso-cas.cru.fr:443 login_uri /login non_blocking_redirection on check_uri /validate logout_uri /logout 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/wws/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_EP_AFFILIATION 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
The user_table paragraph is related to sympa internal authentication by email and password. It is the simplest one the only parameters are regexp and negative_regexp which are perl regexp use to select or block this authentication method for a class of email.
This keyword is mandatory. It is the domain name used in order to bind to the directory and then to extract informations. You must mention the port number after the server name. Server replication is supported by listing several servers separated by commas.
Example :
host ldap.univ-rennes1.fr:389 host ldap0.university.com:389,ldap1.university.com:389,ldap2.university.com:389
It corresponds to the timelimit in the Search fonction. A timelimit that restricts the maximum time (in seconds) allowed for a search. A value of 0 (the default), means that no timelimit will be requested.
The root of the DIT (Directory Information Tree). The DN that is the base object entry relative to which the search is to be performed.
Example: dc=university,dc=fr
If anonymous bind is not allowed on the LDAP server, a DN and password can be used.
This password is used, combined with the bind_dn above.
Defines the search filter corresponding to the ldap_uid. (RFC 2254 compliant). If you want to apply the filter on the user, use the variable ' [sender] '. It will work with every type of authentication (uid, alternate_email..).
Example :
(Login = [sender]) (|(ID = [sender])(UID = [sender]))
Defines the search filter corresponding to the email addresses (canonic and alternative).(RFC 2254 compliant). If you want to apply the filter on the user, use the variable ' [sender] '. It will work with every type of authentication (uid, alternate_email..).
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
The filters can be :
(mail = [sender]) (| (mail = [sender])(alternate_email = [sender]) ) (| (mail = [sender])(alternate_email = [sender])(alternate = [sender]) )
The name of the attribute for the canonic email in your directory : for instance mail, canonic_email, canonic_address ... In the previous example the canonic email is 'mail'.
The name of the attribute for the alternate email in your directory : for instance alternate_email, mailalternateaddress, ... You make a list of these attributes separated by commas.
With this list Sympa creates a cookie which contains various information : the user is authenticated via Ldap or not, his alternate email. To store the alternate email is interesting when you want to canonify your preferences and subscriptions. That is to say you want to use a unique address in User_table and Subscriber_table which is the canonic email.
(Default value: sub) By default the search is performed on the whole tree below the specified base object. This may be changed by specifying a scope :
Defines the URL of a document describing LDAP password management. When hitting Sympa's Send me a password button, LDAP users will be redirected to this URL.
If set to 1, connection to the LDAP server will use SSL (LDAPS).
This defines the version of the SSL/TLS protocol to use. Defaults of to sslv2/3, other possible values are sslv2, sslv3, and tlsv1.
Specify which subset of cipher suites are permissible for this connection, using the standard OpenSSL string format. The default value of for ciphers is ALL, which permits all ciphers, even those that don't encrypt!
A corresponding URL on the local web server should be protected by the SSO system ; this URL would look like textbf http://yourhost.yourdomain/wws/sso_login/inqueue if the service_id is inqueue.
This parameter concern only the first access to Sympa services by a user, it activate or not the non blocking redirection to the related cas server to check automatically if the user as been previously authenticated with this CAS server. Possible values are on off, default is on. The redirection to CAS is use with the cgi parameter gateway=1 that specify to CAS server to always redirect the user to the origine URL but just check if the user is logged. If active, the SSO service is effective and transparent, but in case the CAS server is out of order the access to Sympa services is impossible.
If set to 1, connection to the LDAP server will use SSL (LDAPS).
This defines the version of the SSL/TLS protocol to use. Defaults of to sslv2/3, other possible values are sslv2, sslv3, and tlsv1.
Specify which subset of cipher suites are permissible for this connection, using the OpenSSL string format. The default value of for ciphers is ALL, which permits all ciphers, even those that don't encrypt!
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 :
sympauser=<user_email>:<checksum>where <user_email> is the user's complete e-mail address, and <checksum> are the 8 first bytes of the a MD5 checksum of the <user_email>+Sympa cookie configuration parameter. Your application needs to know what the cookie parameter is, so it can check the HTTP cookie validity ; this is a secret shared between WWSympa and your application. WWSympa's loginrequest page can be called to return to the referer URL when an action is performed. Here is a sample HTML anchor :
<A HREF="/wws/loginrequest/referer">Login page</A>
You can also have your own HTML page submitting data to wwsympa.fcgi CGI. If you're doing so, you can set the referer variable to another URI. You can also set the failure_referer to make WWSympa redirect the client to a different URI if login fails.