SYMPA based groupware
Because exchanging emails
was not enough
SYMPA ?
• Mailling list server software
• Nice web interface
• Can manage lots of lists, supports vhosts,
SaaS oriented
• Can syncronize lists members from
various datasources
• Flexible scenario based autorisation
system
SYMPA users
• 90% of research and educationnal
organism in France are using it
• Ministries (defence, education, foreign
affairs …)
• Hosting companies
• NASA, UNESCO …
• Most users aren’t located in France
(translated in a dozen languages)
SYMPA achievements
• Biggest list scores at 1 600 000
subscribers
• A server is hosting 32 000 lists
• Another is hosting 30 000 virtual hosts
• A server with more than 3 000 000
subscribers
From group-aware
to groupware
• Most of our lists are used to communicate
between project members
• External apps have ways to get list
members, list membership based
authorisation began to spread
• SYMPA slowly became a group manager
=
my-list@lists.renater.fr
Virtual
Organization
SOAP
• Easy to use
• Lots of libraries
• More secure than direct database
querying
• Requires slight alteration of group-aware
applications
• Requires heavy alteration of non-groupaware applications
VOOT
• Extends OpenSocial specification
• Libraries are available
• Three-legged membership data access
model
• OpenSocial enabled applications require
almost no alterations
• As complicated as SOAP for non-groupaware applications
Where we are at
Soon to come : big file sharing, collaborative document editing, data hub …
Let’s make the world
a better place
• VOs need a way to authorise access to
their applications based on membership
• No heavy coding/application altering
should be required
• Most VOs are already using federated
applications
« Humm … What if a SP was able to get user memberships
from a SYMPA server and allow access based on that ? »
SYMPA as SAML Attribute
Authority
• Mailing list is a Virtual Organisation
• Membership and role in mailing list can be
expressed with an attribute
• Standard SAML Attribute Queries and
user's email address to get membership
attributes
• A VO should be able to easily tell which
SPs can get memberships
How is it better ?
• Building a bilateral trust relationship is
needed for SOAP and VOOT, not SYMPASAML-AA (we already have metadata)
• Restricting access to an already federated
application is only a matter of configurating
the SP
Architecture
Université X
1. Authentification
nom
email
eppn
SP
IdP
2. Attribute
Query
Sympa / Attribute Authority
nameID:
email
Sympa
Sympa
Config
3. Attributs
Cron
Sync
My
SQL
IdP
AA
...
Liste 1
Liste 2
Liste N
groups:
liste 1
liste 2
nom
email
eppn
groups
Application
Characteristics
• Very non-invasive because no or only
minimal changes are necessary in SYMPA
code.
• Benefit from SYMPA's various data base
connectors (SQL, LDAP, ...) to create and
sync mailing lists/groups
• Standard Shibboleth IdP with SSO
deactivated and only Attribute Authority
configured
Attribute to Express
Membership
• isMemberOf and hasMembers attributes
from eduPerson Schema:
http://middleware.internet2.edu/dir/docs/draftinternet2-mace-dir-ldap-edumember-latest.htm
• Mailing list addresses are used as values.
E.g. my-list@listes.renater.fr,
john.doe@example.org?role=owner
Attribute Values
• Use official SYMPA mail addresses for roles.
List Admins:
#list-name#-request@listes.renater.fr
List Editors:
#list-name#-editor@listes.renater.fr
• SYMPA also allows defining custom attributes
per list. They could be released too but for
the sake of simplicity that is not done
currently.
Attribute Release
Restrictions
• List administrator can restrict SPs allowed
to get group member ship data
• EntityIDs or '*' can be added to SYMPA list
settings
SAML Queries that
SP can make
• Get all lists and roles of a particular user:
NameID e.g. "john.doe@example.org"
• Get all lists from SYMPA instance:
NameID "toutes-listes@listes.renater.fr"
• Get all members of a list/VO:
NameID e.g. "my-list@listes.renater.fr"
• These are also the functions VOOT
supports
SAML Attribute Queries
Three options to make the queries with Shibboleth:
1. Shibboleth Attribute Aggregation performs query
automatically upon login of user. Can retrieve
authenticated user's mailing list memberships.
2. Shibboleth-bundled resolvertest binary:
Maybe slow because it loads full configuration
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeS
Presolvertest
3. Using the Shibboleth Attribute Query plugin
developed by our colleagues from GakuNin (JP).
Attribute Query with
Shibboleth Plugin
• Applications access URL:
/Shibboleth.sso/AttributeQuery
?entityID=https://pre-listes.renater.fr/idp/shibboleth
&format=urn:oid:0.9.2342.19200300.100.1.3
&nameId=toutes-listes@listes.renater.fr
• Security during Attribute Query is ensured
automatically by Shibboleth SP.
• Above handler URL is by protected by
Shibboleth SP with ACL (default is
127.0.0.1)
Known Issues
Email attribute as user identifier
• Disadvantage: Many email addresses on existing
mailing lists use private (Gmail, Hotmail) addresses
but IdPs release institutional email addresses.
• Hot-fix solution: Create account on CRU (home for the
homeless) IdP or ask list admin to change email
address from private to institutional address.
• Advantage I: No user invitation via email needed to get
eduPersonPrincipalName or alternative identifier
• Advantage II: In case an organisation deploys an own
IdP, no migration is necessary from CRU account to
organisation account because email address stays the
same.
Status
• Currently working Proof-of-concept
• Looking for testers and use-cases
• Demo, try it yourself (in French) :
https://demo-federation.renater.fr/autorisation/
Outlook
• Plan is to create a new service
• No name yet (working name "RENAauthZ")
• To lower barrier for potential users,
RENATER might run an SP Proxy that
could be put in front of any web application.
No need to install and configure an own SP.