TNC2004 Rhodes 1 Authentication and access control in Sympa mailing list manager Serge Aumont &...
-
Upload
anis-hubbard -
Category
Documents
-
view
216 -
download
3
Transcript of 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
u
Who is he ?ticket=17429
ID=smith
Search email
for ID=smith
Email :[email protected]
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
Who is he ?ticket=17429
ID=smith
Interaction with multiple CAS servers
TNC2004 Rhodes9
CAS 1
CAS 2
ClientSympa
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