Authentication and access control in Sympa mailing list server

Transcription

1 Authentication and access control in Sympa mailing list server February 2004 Serge Aumont & Olivier Salaün Comité Réseau des Universités Campus de Beaulieu, Rennes France 1 Introduction Sympa is a rich open source mailing list software that is widely used (4 000 known sites) especially by academic institutions world wide but also private service providers. It has been designed to get integrated with universities information system, allowing dynamic mailing lists to be built ; it is also able to use existing authentication services. Sympa s design also highly focuses on customization possibilities and ease of administration. This article describes how Sympa deals with authentication and authorization, especially focusing on how it cooperates with single sign-on systems such as CAS and Shibboleth. 2 Some elements of Sympa architecture 2.1 A hierarchical organization Sympa is designed as an engine to manage a large number of mailing lists built on top of a common base, not just mailing lists side by side. This architecture allows a global management of virtual mailing list servers under control of different listmasters, each of them managing a set of mailing lists. Like Apache s virtual host concept, Sympa can manage multiple mailing list services (called Virtual robots) within a single installation. Virtual robots share the same code and a set of configuration files (including web templates and authorization scenarios), thereby requiring only specific parameters to be customized at the virtual robot level. The same inheritance principles apply to mailing lists themselves, thus making their configuration lighter. A single web interface allows a global management of user preferences (language, preferred MIME format, ) as well as the authentication service we describe in chapter 3. Sympa also provides transverse features such as list memberships for subscribers and the ability to manage mailing lists and users for the listmaster. Hosting of large mailing lists (can cope with subscribers) has lead us toward a fine-grained and strict definition of roles in Sympa, because responsibilities and administration tasks need to be shared. From the higher to the lower level Sympa defines the following roles : the super listmaster, the virtual robot listmaster, the mailing list owner, the mailing list moderator and the mailing list subscriber. The super listmaster is responsible for creating new virtual robots and defines default global parameters inherited by virtual robots, whereas the listmaster s main task is mailing list activation. List owners are in charge of subscribers management (subscriptions requests, bounces) as well as list setup (access control to each feature). One list owner is responsible for delegating administration tasks to a group of list owners, if the mailing list size requires such an organization. List moderators (who are often also defined as owners) are responsible for editorial contents of moderated mailing lists.

2 2.2 Dynamic mailing lists based on LDAP The standard way to build mailing lists is for members to subscribe to the list, though the list owner may sometimes add members (for working groups mailing lists). Sympa proposes another way to build more administrative mailing lists in relation with the institution s information system. This kind of institutional mailing list can range from small student working groups allowing horizontal communication to a newsletter for contacting all university employees. Informations regarding these populations are either stored in a relational database or in the institution s LDAP directory. Sympa has the ability to dynamically build mailing lists based on RDBMS (many supported databases) and LDAP directories. There s a growing usage of this feature in french and foreign universities to systematically provide a groupware communication tool to each student community. Sympa will fetch members addresses from an LDAP directory (or a relational database) depending on the list configuration. Required parameters include server information and an LDAP filter. Institutions that use groupofuniquenames in their LDAP schema require Sympa to proceed in two times : first fetch the selected DNs and then extract, for each DN, the associated address. Note that Sympa has no prerequisite about the LDAP schema except that the directory should contain addresses. Resulting entries are cached in Sympa s own database for performance reasons and updated (based on a TTL parameter) by a dedicated process. Such a dynamic mailing list can query multiple LDAP (or SQL) servers and even allow static members to subscribe. 2.3 Interfaces to the mailing list service Sympa mail interface is comparable to other well known mailing list softwares. Commands (subscribe, review, lists, ) are sent to an address unique for each virtual robot. Each mailing list has a main address for sending messages and associated administative addresses (-request, -owner, - unsubscribe, ). Like most mailing list servers, Sympa provides a web interface to the mailing list service. All mail features are available (archives, subscription, members review, ) and even more (document repository, list creation and setup, template customization, ). User authentication is password or certificate based, privileges for each operation are evaluated by an authorization engine we will describe in chapter 4. All web pages are defined by templates that have been internationalized (14 languages) and can be customized by listmasters.

3 A SOAP server for Sympa has recently been added to the package. This server provides an API to integrate simple mailing list services within another application ; for example include a list subscription form in a PHP page. In the past, external applications would directly access Sympa s database, thus bypassing Sympa s authentication and authorization procedures. The SOAP interface makes it easy to develop a Sympa Uportal [6] channel; this has been done by the french ESUP project [5], along with CAS authentication. 3 User authentication in Sympa Sympa needs to authenticate users (listmaster, owners, moderators, subscribers) on both its mail and web interfaces to then apply appropriate access controls (authorization process) to subsequent requested actions. At the beginning, like most web application, Sympa provided its own authentication service based on internal user passwords and challenges. Several other authentication backends have been added later. Authentication backends are now defined in an ordered configuration file that allows to restrict each backend to a subset of users. This restriction is expressed with a regular expression that is applied on the user address. It is crucial to provide various authentication methods in a mailing list server because unlike a webmail service, it is not restricted to local users. Users from other universities or from out side the community will certainly use your mailing list service and Sympa wil be able to authenticate them with one of its backends. 3.1 Mail versus web authentication For the mail interface, basic authentication is based on From: message header field whereas a higher authentication level relies on a mail challenge password. On the web interface, a password is required when authentication is needed. Sy mpa assumes that user mailbox is confidential and usually sends new user passwords via . Therefore web password-based authentication and mail challenges are considered equivalent. Of course the authentication level when based on an SMTP header is very low but the evaluation of user privileges depends on which authentication technique has been used. For most mailing lists, the subscription process will trust the SMTP From: header field whereas it is not strong enough while creating or removing a mailing list.

4 3.2 X509 user certificates Sympa s basic authentication method has been extended in order to support x509 user certificates for strong authentication both for mail access using S/MIME signature (PGP is on the way) and for web access. HTTPS is not only used to encrypt CGI data but with SSL V3 it authenticates end users owning an X509 personal certificate. This method provides stronger authentication and may be more user friendly, but its usage depends on user certificate deployment and can t be generalized now. 3.3 LDAP authentication Listmasters want the mailing list service st rongly integrated with their information system, beyond HTML customization. The first need is to make the authentication process conform to the institution policy. Most universities don't use a Single Sign-On solution yet but they use an LDAP directory as the reference for all password authentication. Sympa can validate user identifier and password against an LDAP directory. Then it performs one more LDAP request to fetch the user address given his DN. Here are the three steps algorithm of the LDAP authentication process : 1. Search the DN given the userid 2. Bind with the DN and password to validate the password 3. Fetch address in the DN entry 3.4 Sympa and CAS single sign-on french universities are currently deploying single sign-on services to solve the multiple authentication problem within web portals. This problematic has araised within the ESUP project [5], a consortium of Universities building an open source Virtual campus solution that could be generalized at a national level. We ve been working on the integration of CAS, the single sign-on software they have chosen, with Sympa s web interface. CAS [3] (Central Authentication Service) is a web single sign-on system that has been developped by Yale University. It is strongly inspired by Kerberos concepts, making use of tickets and allowing user authentication delegation. There are usually low impacts on a CASified application unless the application support s multiple CAS servers or if it uses CAS authentication only for a subset of users Getting user attributes CAS only handles user authentication, it does not spread user attributes. The result of a CAS authentication is a user identifier but the user address is not transmitted by the CAS server, whereas Sympa requires it. Sympa assumes that user attributes including the address is stored in an LDAP directory. Along with the CAS server definition, Sympa configuration file will include a description of a LDAP request to fetch the user address from its user-id. The LDAP server and filters are defined the same way it was for LDAP-based authentication CAS redirections Like most web single sign-on systems, CAS intensely uses HTTP redirections. These redirections bring the magic of single sign-on, transparently checking if the user was previously authenticated on the CAS server and skip the login step. Otherwise the CAS server prints a login form. When Sympa is configured to use more than one CAS server, any redirection to a CAS server is a dead end for user that couldn t login on that particular server. CAS provides a way to perform non-blocking login redirections; the CAS server is only providing the user login status but not requesting a login action. This feature allows Sympa to test if a user is already authenticated against different servers. If none of the CAS servers has an active login session with that user, he will be redirected back to Sympa login banner. The Sympa login banner proposes an /password form along with a menu list ing all supported CAS servers, thereby acting like a Shibboleth WAYF (Where Are You From). The redirection technique has a major drawback : if the CAS server is unreachable the user is never brought back to Sympa. This risk is acceptable for institutions using their own CAS server but the average risk becomes too

5 high for virtual organizations relying on several CAS servers (service br oken if one CAS server is broken). Sympa allows the listmaster to configure each CAS server in order to disable automatic redirection. Two optimizations are planed to reduce risks related to CAS redirections : Adjust redirection order using heuristics based on user IP address. Sympa would try to find out which CAS server is capable of authenticating the user. This mainly addresses performance issues and it would be a rather tedious task for the listmaster to maintain the set of IP addresses. Sympa could regularly ping each CAS server and disable unreachable servers until they come up CAS logout When using its native authentication, Sympa proposes a logout button in order to remove its session cookie and safely close the current login session. When users have logged in on a CAS server, the logout button should provide the same feature. This is done using a redirection to the appropriate CAS logout URL. Some administrators don t want any target application to provide a global logout function ; the portal itself being the only place where this feature is proposed. Sympa keeps track of which backend authenticated the user in session cookies, then adapting the logout behavior to the backend CAS authentication across Uportal Sympa can be queried from within an Uportal [6]channel via its SOAP interface, briefly described earlier. Authentication on the SOAP interface requires an address and a password or a CAS Proxy Ticket can be used. In the later case the Uportal channel acts as a CAS proxy and will request a Proxy Ticket for the Sympa service ; the Sympa authentication library is able to validate such CAS tickets. Since SOAP is based on HTTP, Sympa uses HTTP cookies to maintain authentication sessions with the user. 4 Managing access control with authorization scenarios Since Sympa proposes three interfaces (mail, web and SOAP) to most of its services, the access control rules applied to the same f unction via different interfaces have to be equivalent. This required a common authorization process and a way to express authorization rules for each functions. To achieve this goal Sympa uses its authorization scenarios, an access control language. An service request is mapped to an appropriate scenario and evaluated by Sympa s authorization engine. A service is requested within some conext : role of the requesting user, environment variables (REMOTE_ADDR, SSL_CLIENT_S_DN, ), authentication method, mail headers and body The scenario describes which action(s), depending on this context, must be performed to achieve the authorization process. The scenario file is made of rules evaluated sequentially and composed by three elements : a condition, an authentication method and an action. If the service request context matches a rule condition and satisfies its authentication method, then the corresponding action is returned by the authorization engine to the main program. The action might be a request for a stronger authentication process for the user, a new service request or eventually the execution of the request (do_it). Here is an example of a sophisticated authorization scenario for a moderated mailing list : title.us Moderated list for non subscribers or multipart messages title.fr Modération pour les non abonnés ou messages multipart is_editor([listname],[sender]) smtp,md5 -> do_it #rule 1 match([header->content-type],/multipart/) smtp -> editorkey #rule 2 is_subscriber([listname],[sender]) smtp,md5 -> do_it #rule 3 true() smtp -> request_auth #rule 4 true() md5 -> editorkey #rule 5 Note that when evaluated for non subscribers, the scenario above will be evaluated three times by Sympa : rule (4) is first matched and will request the message sender to confirm (request_auth) confirmation is then identified by the md5 authentication method in rule (5) and the message is forwarded to moderators (editorkey)

6 the message is validated by moderator, rule (1) is matched and message is distributed to list subscribers (do_it) Sympa is distributed with a set of 100 scenario files that can be overloaded according to Sympa hierarchical organization ; listmasters can of course write new scenarios. Thanks to the rich context that is passed to the authorization engine, the behaviour of Sympa services can be extended to listmaster needs very easily without any changes in the code. From the list owner s point of view, a scenario is just a list of possible values (scenario titles) for one list parameter. List owners are not allowed to create or edit existing scenarios. Extensions have been planned around authorization scenarios to provide parameters to scenarios. Sympa s web admin interface could also include a scenario editor, so list owners could build their own scenarios based on a few standard rules. 5 Sympa and Shibboleth Shibboleth [4] is a software developped by Internet2 that aims at interconnecting local authentication systems to distant web ressources, thus allowing sophisticated access control management. Shibboleth is made of three main components : The Origin package is installed in the user s home organization. This component is a front-end to the local authentication system and user attribute database. The Target package is installed in front of a web ressources that requires Shibboleth access control. This component will communicate with the Origin to perform user authentication and user attribute negotiation. The WAYF (Where Are You From) is the central component, shared by multiple organisations. It is in charge of guiding users to their Home organisation s Shibboleth component (Origin) to authenticate. Shibboleth integration with Sympa has been asked by Internet2 for their own use. These developments also allowed us to have a better understanding of Shibboleth architecture and see how it could be used by french universities. In Shibboleth architecture, Sympa s web interface is one service that can act as a protected ressource on the Target side. Sympa is supposed to redirect the user to the WAYF that will delegate user authentication to the appropriate Origin site ; Sympa then receives the user identity and attributes (Student, Teacher, ) from Shibboleth Origin site and will grant the user appropriate application privileges. Note that changes that were made to Sympa for Shibboleth authentication should adapt to any other single signon software, as long as it is able to protect a single URL (not the whole site) and assuming that user attributes are passed to Sympa as HTTP header fields. 5.1 Shibboleth authentication Unlike static web pages, Sympa s web interface can not be located behind an authentication point but needs to trigger authentication when required. This is due to the fact that a single Sympa server may authenticate users using different authentication methods (internal password, LDAP passwords, X509 client certificates, CAS) depending on user populations. Many Sympa features (including web archives) are also accessible to unauthenticated users. Sympa delegates Shibboleth authentication to the web server (Apache) via the ShibRM module (RM = Ressource Manager). This module acts like Apache s mod_auth module to restrict access to a web URL for a set of authenticated users. To allow a triggered authentication, only a dedicated URL of Sympa (/sso_login) is protected by ShibRM. If the user selects Shibboleth Inqueue authentication service from Sympa s login banner, he is redirected to the /sso_login URL that will guide the user to his home organisation login banner. Once the user is authenticated, he is brought back to Sympa that will set an authentication HTTP cookie.

7 5.2 User attributes Shibboleth does a sophisticated management of user attributes in both Origin and Target packages, allowing various data sources to be used ; exchanged attributes (including user ID and address) can be filtered on both side. The user s identity and attributes are carried from the ShibRM to Sympa via HTTP header fields. Sympa requires at least the user address to be set because this is the user identifier in the mailing list manager. Additional user attributes that are provided will be stored in Sympa s cache (until the user logs out) for later use. Provided the user s address, Sympa considers the user authenticated and sets its session cookie. During the login session, Shibboleth user attributes (obtained from the Origin site) are available in web/mail templates and in authorization scenarios. This way, the web interface can include additional user information ; user privileges can be tailored (extended or restricted) depending on user information provided by his home organization. 5.3 Changes in Sympa user interface If Shibboleth servers have been defined in auth.conf, a menu is added to the Sympa login banner with the list of defined Shibboleth (or CAS) servers the user can be redirected to. If the user selects a Shibboleth server, he is not directly redirected to the corresponding WAYF but to the sso_login page that is Shibboleth-protected and will thereby redirect the user to the WAYF. Note that the logout function is unchanged and only closes the Sympa login session. It does neither performs a logout at the user s home organization nor at the local level of the ShibRM. 6 Conclusion We now consider that Sympa is well adapted to interoperate with complex information systems. The authentication mechanism, which is an important concern for interoperability, has been made highly configurable. It can cope with major authentication technologies including LDAP, single sign-on and X509 certificates. Support of SAML authentication for the Sympa SOAP server is now considered. In between authentication and authorization layers, the attributes management process might require some extentions in Sympa. As information system concerns are moving toward dedicated attributes delivery services, we will improve user attributes management in Sympa to extend usage of these attribute sources. This will allow us to map user attributes with mailing list roles. Sympa authorization scenario engine would also benefit from these new user attributes. 7 Références [1] Sympa : [2] Sample SOAP client to Sympa service : [3] CAS : [4] Shibboleth : [5] Esup-Portail - Groupe 1B - SSO et gestion des autorisations [6] Uportal :