Etude synchro : cas d'utilisation de LSC

This commit is contained in:
Paul Marillonnet 2017-06-27 17:58:44 +02:00
parent 75f06d3694
commit 574904e80b
1 changed files with 72 additions and 0 deletions

72
doc.md
View File

@ -3468,6 +3468,78 @@ requêtes :
# numResponses: 1
```
lsc-sample --run pour lancer la synchro
OK
l'exemple de test fonctionne en trois étapes :
Première phase : $ bin/lsc-sample --import sample.csv
la création d'une base de données relationnelle contenant une
table remplie à partir d'un fichier csv.
Le SGBDR utilisé ici est HSQLDB
Le fichier csv présente une première ligne permettant le nommage des attributs
dans la base.
Seconde phase : $ bin/lsc-sample --start-ldap-server
Lancement du server LDAPv3 (implémentation OpenDJ)
Le serveur ne contient pour l'instant aucune données
Troisième phase : $ bin/lsc-sample --run
Réconciliation des données entre la base de données relationnelle et l'annuaire
LDAP.
Pour comprendre comment est effectuée cette synchronisation, il faut étudier
le fichier de synchronisation fourni avec l'exemple.
Il s'agit du fichier lsc.xml
La configuration commence par une liste des différentes connexions que LSC doit
prendre en charge.
Ici, logiquement, seule deux connexions sont assurées par LSC:
```
<ldapConnection>
<name>dst-ldap</name>
<url>ldap://localhost:33389/dc=lsc-project,dc=org</url>
<username>cn=Directory Manager</username>
<password>secret</password>
<authentication>SIMPLE</authentication>
<referral>IGNORE</referral>
<derefAliases>NEVER</derefAliases>
<version>VERSION_3</version>
<pageSize>-1</pageSize>
<factory>com.sun.jndi.ldap.LdapCtxFactory</factory>
<tlsActivated>false</tlsActivated>
<saslMutualAuthentication>false</saslMutualAuthentication>
</ldapConnection>
```
On constate qu'il s'agit des principaux paramètres à fournir lors d'une tentative de connexion à un serveur LDAPv3.
Pas d'authentification mutuelle, pas de chiffrement TLS.
L'option factory pour la déclaration du module de gestion des contextes de connexion.
Pas de déréférencement des alias.
Protocole, hôte, port et DN de base précisés en une seule ligne:
ldap://localhost:33389/dc=lsc-project,dc=org
Côté base de données, une configuration plus succincte permet l'établissement de la connexion.
<databaseConnection>
<name>src-jdbc</name>
<url>jdbc:hsqldb:file:/tmp/lsc/hsqldb/lsc</url>
<username>sa</username>
<password></password>
<driver>org.hsqldb.jdbcDriver</driver>
</databaseConnection>
Pas de mot de passe requis
La partie suivante est plus intéressante, il s'agit des règles de synchronisation.
LSC peut prendre en charge plusieurs tâches de synchronisation à la fois, bien qu'une seule tâche est définie dans cet exemple.
Une fois la tâche nommée (MySyncTask), le chemin vers la classe Java en charge de l'opération de synchronisation est déclaré.
TODO: explication du code source du JavaBean
S'en suivent la déclaration des différentes méthodes pour la partie 'base source' de la synchronisation.
Côté cible, une fois déclaré le DN d'approvisionnement des entrées de la base, on peut définir la liste des attributs synchronisés.
Parmis eux doivent se trouver un ou plusieur attributs pivots, c'est-à-dire, un ou des attributs qui vont servir à LSC pour effectuer la correspondance entre les entrées de chacun de référentiels synchronisés.
L'ensemble de ces attributs pivot sert ainsi d'identifiant pour retrouver une même entité dans plusieurs référentiels.
//Pb: LSC permet-il des mécanismes de détection et de propagation des modifications de ces attributs pivots.
Jusque là il semble être clair que c'est l'unicité des attributs pivots à travers les différentes bases qui permet de détecter et propager les modifications sur les attributs secondaires, non pivots.
propertiesBasedSyncOptions définit la façon dont sera créé le DN d'une entrée LDAP à partir de l'adresse email dans la base de données relationnelle.
//CURRENT3
## Explications techniques Mik