SYMPA based groupware

Because exchanging emailswas 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-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

Where we are at

Soon to come : big file sharing, collaborative document editing, data hub …

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

Architecture

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. 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.frList 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 thatSP 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 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 &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 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/

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.