1 / 22

SYMPA based groupware

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 datasource s

rsmall
Download Presentation

SYMPA based groupware

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SYMPA basedgroupware Becauseexchanging emails was not enough

  2. SYMPA ? • Maillinglist server software • Nice web interface • Can manage lots of lists, supports vhosts, SaaSoriented • Can syncronizelistsmembersfromvariousdatasources • Flexible scenario based autorisation system

  3. SYMPA users • 90% of research and educationnalorganism in France are usingit • Ministries (defence, education, foreignaffairs …) • Hostingcompanies • NASA, UNESCO … • Most usersaren’tlocated in France (translated in a dozenlanguages)

  4. SYMPA achievements • Biggestlist scores at 1 600 000 subscribers • A server ishosting 32 000 lists • Anotherishosting 30 000 virtual hosts • A server with more than 3 000 000 subscribers

  5. From group-awareto groupware • Most of ourlists are used to communicatebetweenprojectmembers • Externalapps have ways to getlistmembers, listmembershipbasedauthorisationbegan to spread • SYMPA slowlybecame a group manager Virtual Organization =

  6. SOAP • Easy to use • Lots of libraries • More securethan direct databasequerying • Requiresslightalteration of group-aware applications • Requiresheavyalterationof non-group-aware applications

  7. VOOT • ExtendsOpenSocialspecification • Libraries are available • Three-leggedmembership data access model • OpenSocialenabled applications requirealmost no alterations • As complicated as SOAP for non-group-aware applications

  8. Wherewe are at Soon to come : big file sharing, collaborative document editing, data hub …

  9. Let’smake the worlda better place • VOsneed a way to authoriseaccess to their applications based on membership • No heavycoding/application alteringshouldberequired • Most VOs are alreadyusingfederated applications « Humm … What if a SP was able to get user membershipsfrom a SYMPA server and allowaccessbased on that ? »

  10. 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

  11. How isitbetter ? • Building a bilateral trust relationshipisneeded for SOAP and VOOT, not SYMPA-SAML-AA (wealready have metadata) • Restrictingaccess to an alreadyfederated application isonly a matter of configurating the SP

  12. Architecture

  13. Characteristics • Verynon-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

  14. 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

  15. 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.

  16. Attribute Release Restrictions • List administrator can restrict SPs allowed to get group member ship data • EntityIDs or '*' can be added to SYMPA list settings

  17. 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

  18. SAML Attribute Queries Three options to make the queries with Shibboleth: • Shibboleth Attribute Aggregationperforms query automatically upon login of user. Can retrieve authenticated user's mailing list memberships. • Shibboleth-bundled resolvertest binary:Maybe slow because it loads full configurationhttps://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPresolvertest • Using the Shibboleth Attribute Query plugin developed by our colleagues from GakuNin (JP).

  19. 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)

  20. 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.

  21. Status • Currently working Proof-of-concept • Looking for testers and use-cases • Demo, try it yourself (in French) : https://demo-federation.renater.fr/autorisation/

  22. 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.

More Related