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-awareto 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
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-group-
aware 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-group-
aware applications
Let’s make the worlda 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 SYMPA-SAML-AA (we already have metadata)
• Restricting access to an already federated application is only a matter of configurating the SP
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/draft-internet2-mace-dir-ldap-edumember-latest.htm
• Mailing list addresses are used as values. E.g. [email protected], [email protected]?role=owner
Attribute Values• Use official SYMPA mail addresses for roles.
List Admins: #list-name#[email protected] Editors:#list-name#[email protected]
• 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 thatSP can make
• Get all lists and roles of a particular user:NameID e.g. "[email protected]"
• Get all lists from SYMPA instance:NameID "[email protected]"
• Get all members of a list/VO:NameID e.g. "[email protected]"
• 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 configurationhttps://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPresolvertest
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 &[email protected]
• 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 IssuesEmail 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/