Transcript Diapositive 1

Authentication and access
control in Sympa mailing list
manager
Serge Aumont & Olivier Salaün
May 2004
TNC2004 Rhodes
1
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
2
Authentication method
Sender confirmation challenge
Interface
mail
Password (allocation by email) web
LDAP authN backend
web
SSO: CAS
SSO: Shibboleth
User certificate
Web & SOAP
Web
Mail: S/MIME
Web: HTTPS
TNC2004 Rhodes
3
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 Rhodes
4
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 Rhodes
5
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
6
Sympa interaction with one CAS server
LDAP
Search
email
for
ID=smith
Email :
[email protected]
u
Sympa
Who is he ?
ticket=17429
ID=smith
TNC2004 Rhodes
Welcome
[email protected]
u
Client
Redirection
ticket=17429
CAS
redirection.
Is that user
authenticated
?
7
Interaction with multiple CAS servers
CAS 1
no
non bloking
redirection.
Is that user
authenticated ?
Sympa
Client
yes
ticket=17429
Who is he ?
ticket=17429
TNC2004 Rhodes
CAS 2
ID=smith
Welcome
[email protected]
Non bloking
redirection.
Is that user
authenticated
?
8
Interaction with a chosen CAS server
CAS 1
Welcome
[email protected]
Sympa
Client
WAYF ?
redirection.
Is that user
authenticated
?
ID=smith
yes
Who is he ?
ticket=17429
ticket=17429
TNC2004 Rhodes
User : ?
Password ?
CAS 2
9
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
10
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
11
link to use https
WAYF
TNC2004 Rhodes
basic password login with
Sympa database backend or
some ldap servers
12
Authentication/Authorization
Access
AuthZ scenario engine
control
TNC2004 Rhodes
X 509
LDAP
CAS
Authentication
Internal DB
management
LDAP
User attribute
Shibboleth
Internal user attributes
13
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
14
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
15
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 email address has been verified with an md5
challenge
TNC2004 Rhodes
16
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 ; frontend 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
17
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
18
Sympa
Shibboleth
Origin
Attribute
Authority
Handle
Service
public
area
login
User
Ressource
Manager
WAYF
attributes
restricted
area
identity
SHIRE
TNC2004 Rhodes
Target
attributes
SHAR
19
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
20
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 SignOn servers…
• http://www.sympa.org
TNC2004 Rhodes
21