Groupware/Sympa

Report
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:
[email protected]
List Editors:
[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.

similar documents