TNC2004 Rhodes 1 Authentication and access control in Sympa mailing list manager Serge Aumont &...

TNC2004 Rhodes1

Authentication and access control in Sympa mailing list

manager

Serge Aumont & Olivier Salaün

May 2004

TNC2004 Rhodes2

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 Rhodes3

Authentication method Interface

Sender confirmation challenge mail

Password (allocation by email) web

LDAP authN backend web

SSO: CAS

SSO: Shibboleth

Web & SOAP

Web

User certificate Mail: S/MIME

Web: HTTPS

TNC2004 Rhodes4

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 email domain if possible

TNC2004 Rhodes5

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)

http://www.sympa.org/documentation/article_smime/sympasmime.html

TNC2004 Rhodes6

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 Rhodes7

CAS

ClientSympa

Redirection ticket=17429

Welcomesmith@dom.ed

u

Who is he ?ticket=17429

ID=smith

Search email

for ID=smith

Email :smith@dom.ed

u

LDAP

redirection.Is that user

authenticated?

Sympa interaction with one CAS server

TNC2004 Rhodes8

CAS 1

CAS 2

ClientSympa

non bloking redirection.Is that user

authenticated ?no

Non bloking redirection.Is that user

authenticated?

yesticket=17429

Welcomesmith@dom.edu

Who is he ?ticket=17429

ID=smith

Interaction with multiple CAS servers

TNC2004 Rhodes9

CAS 1

CAS 2

ClientSympa

Welcomesmith@dom.edu

WAYF ?

redirection.Is that user

authenticated?

User : ?Password ?

yesticket=17429Who is he ?

ticket=17429

ID=smith

Interaction with a chosen CAS server

TNC2004 Rhodes10

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 Rhodes11

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 Rhodes12

link to use https

basic password login with Sympa database backend or

some ldap serversWAYF

TNC2004 Rhodes13

X 5

09

Inte

rnal

DB

LDA

PLDAP

CA

S

Internal user attributes

Shi

bbol

eth

AuthZ scenario engine

Authentication

User attribute

management

Access

control

Authentication/Authorization

TNC2004 Rhodes14

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 Rhodes15

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 Rhodes16

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 -> rejectmatch([msg_header->Content-type],/multipart/) smtp,md5,smime -> editortrue() 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 email address has been verified with an md5 challenge

TNC2004 Rhodes17

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 Rhodes18

Shibboleth and SympaUsage / 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 Rhodes19

public area

restricted area

login RessourceManager

User

attributes

AttributeAuthority

HandleService

Origin

WAYF

SHARSHIRE

Target

identity attributes

ShibbolethSympa

TNC2004 Rhodes20

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 studentequal([user_attributes->SHIB_STUDY_BRANCH],’geology’) md5 -> do_itequal([user_attributes->SHIB_STUDY_BRANCH],’archeology’) md5 -> do_it

TNC2004 Rhodes21

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…

• http://www.sympa.org