Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dev:exporting_groups_in_ldap [2007/10/12 13:41]
serge.aumont@cru.fr
dev:exporting_groups_in_ldap [2015/03/18 11:30] (current)
Line 1: Line 1:
-====== ​Exporting ​Sympa mailing lists to LDAP ======+====== ​Publishing ​Sympa mailing lists to in a LDAP directory ​======
  
 ===== People involved in this development project ===== ===== People involved in this development project =====
  
-  * Sympa developers ​<​sympa-authors@cru.fr>​ +  * Sympa developers  
-  * Michael Gettes ​<​gettes@internet2.edu>​ +  * Michael Gettes, Internet2 ​ 
-  * Susan Neitsch ​<​Susan-Neitsch@cis-gw.tamu.edu>​ +  * Susan Neitsch, TAMU University 
 +  * Sylvain Amrani, French Gendarmerie 
 +  * José María Palacio Carabias, GMV 
 +  * Israel Cardenas, Borja Pacheco Ortega, Junta de Andalucia
  
 ===== Why? ===== ===== Why? =====
Line 20: Line 22:
 On the other hand most software natively implement LDAP connectors to query group definition. Therefore it would be useful to adapt Sympa so that it can export its groups data into an LDAP directory. Then third party application could just use their LDAP connectors. On the other hand most software natively implement LDAP connectors to query group definition. Therefore it would be useful to adapt Sympa so that it can export its groups data into an LDAP directory. Then third party application could just use their LDAP connectors.
  
 +===== Different options =====
  
 +There are different technical solutions to provide Sympa group definition through an LDAP interface :
 +  - Add LDAP provisioning code in Sympa. This use case is described in this document.
 +  - Use a third party SQL=>​LDAP synchronisation process. [[https://​sourcesup.renater.fr/​projects/​db2ldap/​|DB2LDAP]] software could be used.
 +  - Add another daemon to Sympa, being an LDAP server. The [[http://​search.cpan.org/​~aar/​Net-LDAP-Server-0.42/​|Net::​LDAP::​Server]] perl library could be used for that.
  
 ===== LDAP structure of a Sympa mailing list ===== ===== LDAP structure of a Sympa mailing list =====
Line 34: Line 41:
   * members/​owners/​moderators stored separately   * members/​owners/​moderators stored separately
  
-Two kind of LDAP structures are considered, each of them having its assets. +==== The LDAP structure ​====
- +
-==== Using groupOfNames ​==== +
- +
-FIXME eviter les adresses réelles, cela se termine tjrs par du spam.+
    
 Below is the representation of such a DIT : Below is the representation of such a DIT :
Line 44: Line 47:
 ou=sympaGroups ou=sympaGroups
   ou=members   ou=members
-    cn=mace-dir@internet2.edu (of type groupOfNames) +    cn=sample-list@test.edu (of type groupOfNames) 
-    cn=shibboleth-users@internet2.edu+    cn=another-list@test.edu
     ...     ...
   ou=owners   ou=owners
Line 53: Line 56:
  
 ou=People ou=People
-  cn=olivier.salaun-@cru.fr (of type inetOrgPerson)+  cn=john.smith@test.edu (of type inetOrgPerson)
  
 </​code>​ </​code>​
Line 59: Line 62:
 This organization has the benefit of using a standard groupOfNames LDAP object that most applications should be familiar with. On the other hand, for an LDAP client to fetch the members of a given group, it requires 2 consecutive search operations. This organization has the benefit of using a standard groupOfNames LDAP object that most applications should be familiar with. On the other hand, for an LDAP client to fetch the members of a given group, it requires 2 consecutive search operations.
  
-==== Using a new mailingList object ==== 
- 
-Below is the representation of such a DIT : 
-<​code>​ 
-ou=sympaGroups 
-  cn=mace-dir@internet2.edu (of type mailingList) 
-    members (multi-valued,​ containing email addresses) 
-    owners 
-    moderators 
-</​code>​ 
- 
-This organization allows LDAP clients to query group members within a single search query. On the other hand it does not allow to store member attributes other than the email address. 
  
 ==== Questions ==== ==== Questions ====
  
  
-Which organization would be appropriate?​ \\ +Should ​we use GroupOfNames objects or GroupOfUniqueNames?​\\
-If using the first solution, should ​we use GroupOfNames objects or GroupOfUniqueNames?​\\+
 Apart from the list address, subject, members, owners and moderators, what other list information should be published in the LDAP directory?​\\ Apart from the list address, subject, members, owners and moderators, what other list information should be published in the LDAP directory?​\\
 Should we store member informations such as name and reception mode? Should we store member informations such as name and reception mode?
Line 84: Line 74:
 The mailing list data in the LDAP directory need to be in sync with Sympa'​s own database. ​ The mailing list data in the LDAP directory need to be in sync with Sympa'​s own database. ​
  
-Therefore we could have a dedicated process that will periodically update the LDAP structure. However a better option would be to add the synchronization code in every places of the Sympa code where list members are updated. This solution would have advantages :+Therefore we could have a dedicated process that will periodically update the LDAP structure. However a better option would be to add the synchronization code in every places of the Sympa code where list members are updated. This solution would have advantages :
   - make the LDAP data always in sync with Sympa'​s own data,   - make the LDAP data always in sync with Sympa'​s own data,
   - synchronous update prevents the burden of comparing both LDAP and SYmpa list members,   - synchronous update prevents the burden of comparing both LDAP and SYmpa list members,
   - better integration of the feature in Sympa.   - better integration of the feature in Sympa.
  
-But there is also a problem with this solution : in case some update is not ok  (let's imagine the LDAP server is unavailible at the moment some user are added in a group), they will never be added in teh the LDAP directory.+We should setup an appropriate error handling. An add operations that fails should retry in some period of time.
  
 ===== Configuration parameters ===== ===== Configuration parameters =====
Line 99: Line 89:
  
 We already have generic code to connect to an LDAP directory given these informations. We already have generic code to connect to an LDAP directory given these informations.
 +
  
 ==== Questions ==== ==== Questions ====
Line 104: Line 95:
 Should the export_ldap parameters should be stored in sympa.conf, or in a dedicated configuration file?\\ Should the export_ldap parameters should be stored in sympa.conf, or in a dedicated configuration file?\\
 Should the export_ldap configuration should be a per virtual host config?\\ Should the export_ldap configuration should be a per virtual host config?\\
-Should the export ldap process actived for all lists or controled by a list parameter ? What are the relations with the review ​authorization scenario ​?+Should the export ldap process actived for all lists or controled by a list parameter ?\\ 
 +Exporting list members to an LDAP directory moves the data out of Sympa'​s control. Sympa can no longer enforce ​the authorization scenario ​rules to protect list members email addresses. This fact should be well explained in the Sympa documentation.
  
 We need to define if the LDAP branch where Sympa stores list data has a hard-coded structure or if it should be customizeable?​ We need to define if the LDAP branch where Sympa stores list data has a hard-coded structure or if it should be customizeable?​
  • dev/exporting_groups_in_ldap.1192189281.txt.gz
  • Last modified: 2007/10/15 11:34
  • (external edit)