TNC2004 Rhodes 1 Authentication and access control in Sympa mailing list manager Serge Aumont & Olivier Salaün May 2004

TNC2004 Rhodes 2 Yet another mailing list manager CRU (french higher education network technical team) Scalability (Kilo-Lists, Mega-Subscribers) Advanced features (subscriber preferred mail format, list document repository, …) Interfaces : mail robot, web and SOAP A full service web portal including administration at list and robot level Virtual hosting Internationalized (14 languages) Dynamic mailing list extracted from LDAP directories (or SQL servers)

TNC2004 Rhodes 3 Authentication methodInterface Sender confirmation challeng Password (allocation by )web LDAP authN backendweb SSO: CAS SSO: Shibboleth Web & SOAP Web User certificat S/MIME Web: HTTPS

TNC2004 Rhodes 4 Multiple authentication methods We want Sympa opened to any users and at the same time to interface with user’s home authentication services when available : Support multiple authentication service at the same time. Choose the appropriate authentication server depending on the user domain if possible

TNC2004 Rhodes 5 X509 user authentication Web : using mod_ssl environment variables inheritance. S/MIME signature : –Check if the sender and the signer are the same. –When mail subject is used for robot command, do not apply the s/mime authN method because headers are not part of the signature –use internally “openssl smime” command which does not check certificate status using CRL or OCSP Sympa also support S/MIME encryption message distribution (accept message encrypted using list certificate and encrypt message for each subscriber)

TNC2004 Rhodes 6 Central Authentication Service Yale university web Single Sign On Use cookie, redirections and a ticket that need to be validated against CAS server Support proxy credential : needed for Uportal Sympa’s channel. Not so easy to introduce into Sympa because CAS has not been designed to interoperate with any other authentication system.

TNC2004 Rhodes 7 CAS Client Sympa Redirection ticket=17429 Welcome u Who is he ? ticket=17429 ID=smith Search for ID=smith u LDAP redirection. Is that user authenticated ? Sympa interaction with one CAS server

TNC2004 Rhodes 8 CAS 1 CAS 2 Client Sympa non bloking redirection. Is that user authenticated ? no Non bloking redirection. Is that user authenticated ? yes ticket=17429 Welcome Who is he ? ticket=17429 ID=smith Interaction with multiple CAS servers

TNC2004 Rhodes 9 CAS 1 CAS 2 Client Sympa Welcome WAYF ? redirection. Is that user authenticated ? User : ? Password ? yes ticket=17429 Who is he ? ticket=17429 ID=smith Interaction with a chosen CAS server

TNC2004 Rhodes 10 What happens if one CAS server is out of order ? Any redirection is a dead end Choose by configuration for each CAS server if non blocking redirection is enabled Ping all CAS servers periodically to detect servers down (todo)

TNC2004 Rhodes 11 What about “CAS logout” ? Sympa stores the authentication method used in order to propose appropriate logout button Sympa erases its own session cookie and redirects the user to the CAS logout URL CAS has some insufficiencies about logout: there is no central logout service

TNC2004 Rhodes 12 link to use https basic password login with Sympa database backend or some ldap servers WAYF

TNC2004 Rhodes 13 X 509 Internal DB LDAP CAS Internal user attributes Shibboleth AuthZ scenario engine Authentication User attribute management Access control Authentication/Authorization

TNC2004 Rhodes 14 Managing access control in Sympa Separated from the authentication process (can also be applied to unauthenticated users) Configured for each list and each feature (subscribe, send, review,visibility…) Extensible behavior using authorization scenarios (distributed with a set of 100) Authorization is applied the same way on all 3 interfaces (mail, web, soap)

TNC2004 Rhodes 15 Authorization scenarios Sympa’s native ACL separated from the code A scenario is evaluated to provide (or not) access to a feature of Sympa –make the web interface highly adapted to the user’s profile (inaccessible features are not advertised) A scenario is made of ordered rules A rule is made of : –A condition –An authentication method –An action (decision) Condition can use LDAP user attributes

TNC2004 Rhodes 16 A sample authorization scenario for message distribution Expected behavior : –Private mailing list –Moderated for multipart messages –S/MIME (or HTTPS) authentication required for moderators is_editor([list->name],[sender]) md5,smime -> do_it ! is_subscriber([list->name],[sender]) smtp,md5,smime -> reject match([msg_header->Content-type],/multipart/) smtp,md5,smime -> editor true() smtp,md5,smime -> do_it Note that : Scenario evaluated line by line Scenario evaluation stops when a condition is matched md5 means : the sender’s address has been verified with an md5 challenge

TNC2004 Rhodes 17 Shibboleth architecture Developped by Internet2 Glue between local Single Sign-on servers to provide inter-institutional sharing of web ressources Shibboleth architecture made of 3 components : –Origin : installed in the user home organisation ; front- end to the local authN system and attributes database –Target : installed in front of a web ressource to control its access ; communicates with origin components –WAYF (Where Are You From) : the central component shared by a group of organization ; guides users to the origin component at their home org.

TNC2004 Rhodes 18 Shibboleth and Sympa Usage / Prerequisites Usage : –Building inter-institutional mailing lists with a strict definition of the targeted population Prerequisites for each institutions: –Local SSO + Shibboleth « target » package –Common definition of user attributes semantic (study branches, staff categories,…)

TNC2004 Rhodes 19 public area restricted area login Ressource Manager User attributes Attribute Authority Handle Service Origin WAYF SHARSHIRE Target identity attributes ShibbolethSympa

TNC2004 Rhodes 20 Access control based on Shibboleth user attributes Shibboleth user attributes : –Inherited via environment variables –Stored as session data in Sympa DB –Used in the authorization scenario engine Scenario sample rule: # check if the user is a geology or archeology student equal([user_attributes->SHIB_STUDY_BRANCH],’geology’) md5 -> do_it equal([user_attributes->SHIB_STUDY_BRANCH],’archeology’) md5 -> do_it

TNC2004 Rhodes 21 Conclusion Sympa users include French academic institutions + foreign universities. They are driving the developments. AA development plans: –SAML authentication on the SOAP interface –Building the « user attributes » layer in Sympa architecture –Validating/introducing Sympa with other Single Sign- On servers…