230 likes | 399 Views
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
E N D
SYMPA basedgroupware Becauseexchanging emails was not enough
SYMPA ? • Maillinglist server software • Nice web interface • Can manage lots of lists, supports vhosts, SaaSoriented • Can syncronizelistsmembersfromvariousdatasources • Flexible scenario based autorisation system
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)
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
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 =
SOAP • Easy to use • Lots of libraries • More securethan direct databasequerying • Requiresslightalteration of group-aware applications • Requiresheavyalterationof non-group-aware applications
VOOT • ExtendsOpenSocialspecification • Libraries are available • Three-leggedmembership data access model • OpenSocialenabled applications requirealmost no alterations • As complicated as SOAP for non-group-aware applications
Wherewe are at Soon to come : big file sharing, collaborative document editing, data hub …
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 ? »
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 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
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
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: • 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).
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.