SYMPA based groupware Because exchanging emails was not enough
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 = [email protected] 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. [email protected], [email protected]?role=owner Attribute Values • Use official SYMPA mail addresses for roles. List Admins: #list-name#[email protected] List 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 that SP 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 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 &[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 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.
© Copyright 2024