inclusion LSC
This commit is contained in:
parent
1dc8a6d16b
commit
4e6dece254
34
doc.md
34
doc.md
|
|
@ -19,40 +19,6 @@ Compilation :
|
|||
## Acronymes
|
||||
|
||||
# Annuaires
|
||||
### LDAP Synchronization Connector (LSC)
|
||||
Il s'agit d'un connecteur permettant la synchronisation entre ApacheDS et OpenLDAP TODIG
|
||||
//Lire la doc, quelle configuration ? Quels cas d'usages ? Quelles limites ? Quels partis pris pour l'implémentation du connecteur ?
|
||||
Simplement une interface entre deux APIs ?
|
||||
Ou bien utilisation de mécanismes sous-jacents, càd qui ne se limitent pas strictement à l'API ?
|
||||
|
||||
Licence BSD
|
||||
Ecrit en Java
|
||||
|
||||
Philosophie de l'outil LSC :
|
||||
Scripts génériques, plus simple et plus stable que le développement de solutions en interne ?
|
||||
Deux niveaux de synchro:
|
||||
- L'identité d'une personne en tant que telle, c'est-à-dire les informations qui définissant son *compte*.
|
||||
- Les informations annexes qui décrivent l'identité de la personne (numéro de téléphone, email, etc)
|
||||
|
||||
Pour la synchronisation, seulement trois opérations du schéma CRUD usuel sont retenues. Il n'y a pas besoin de lecture (READ)
|
||||
CREATE, UPDATE et DELETE sont suffisants
|
||||
|
||||
La synchronisation est effectuée en deux phases:
|
||||
- la première phase consiste en la synchronisation à proprement parler :
|
||||
* lecture des entrées du référentiel source.
|
||||
Seuls les attributs déclarés explicitement sont retenus (on parle d'attributs pivot)
|
||||
* //TODO Quelles différences entre pivotAttributes et fetchedAttributes ?
|
||||
=> Attributs pivots : ceux dont la modification va engendrer un mécanisme de re-synchronisation ?
|
||||
NON : les attributs pivots servent à effectuer le mapping entre entrées source et destination
|
||||
=> Attributs récupérés : ceux qui vont êtres synchronisés (vers un autre référentiel)
|
||||
* utilisation de JavaBeans pour le transfert des attributs sycnhronisés
|
||||
* verification que les conditions de synchronisations sont remplies avant d'effectuer les changements sur le référentiel source
|
||||
- la seconde phase est une phase de nettoyage des référentiels synchronisés.
|
||||
Il s'agit de synchroniser les suppression effectuée sur l'un des référentiels. Le même système d'attributs pivots est utilisé pour le mapping des entrées entre plusieurs référentiels.
|
||||
|
||||
//'Success stories' sur le site de LSC pas assez détaillées
|
||||
Exemple de la BPI qui génère un annuaire centrale à partir de plusieurs fichiers CSV
|
||||
|
||||
//BOOKMARK
|
||||
|
||||
#### OpenDJ
|
||||
|
|
|
|||
|
|
@ -613,7 +613,39 @@ Le backup se fait par lecture des entrées de configuration de l'annuaire, au fo
|
|||
Quels mécanismes assurant la sécurité des données de l'annuaire, des échanges clients/serveur ?
|
||||
Contrôle d'accès ? -> Standardisé par la RFC LDAPv3 ?
|
||||
La configuration est manipulable par écriture/lecture de fichiers LDIF dans <apacheds_base>/conf/../\*.ldif
|
||||
###### LDAP Synchronization Connector (LSC)
|
||||
Il s'agit d'un connecteur permettant la synchronisation entre ApacheDS et OpenLDAP TODIG
|
||||
//Lire la doc, quelle configuration ? Quels cas d'usages ? Quelles limites ? Quels partis pris pour l'implémentation du connecteur ?
|
||||
Simplement une interface entre deux APIs ?
|
||||
Ou bien utilisation de mécanismes sous-jacents, càd qui ne se limitent pas strictement à l'API ?
|
||||
|
||||
Licence BSD
|
||||
Ecrit en Java
|
||||
|
||||
Philosophie de l'outil LSC :
|
||||
Scripts génériques, plus simple et plus stable que le développement de solutions en interne ?
|
||||
Deux niveaux de synchro:
|
||||
- L'identité d'une personne en tant que telle, c'est-à-dire les informations qui définissant son *compte*.
|
||||
- Les informations annexes qui décrivent l'identité de la personne (numéro de téléphone, email, etc)
|
||||
|
||||
Pour la synchronisation, seulement trois opérations du schéma CRUD usuel sont retenues. Il n'y a pas besoin de lecture (READ)
|
||||
CREATE, UPDATE et DELETE sont suffisants
|
||||
|
||||
La synchronisation est effectuée en deux phases:
|
||||
- la première phase consiste en la synchronisation à proprement parler :
|
||||
* lecture des entrées du référentiel source.
|
||||
Seuls les attributs déclarés explicitement sont retenus (on parle d'attributs pivot)
|
||||
* //TODO Quelles différences entre pivotAttributes et fetchedAttributes ?
|
||||
=> Attributs pivots : ceux dont la modification va engendrer un mécanisme de re-synchronisation ?
|
||||
NON : les attributs pivots servent à effectuer le mapping entre entrées source et destination
|
||||
=> Attributs récupérés : ceux qui vont êtres synchronisés (vers un autre référentiel)
|
||||
* utilisation de JavaBeans pour le transfert des attributs sycnhronisés
|
||||
* verification que les conditions de synchronisations sont remplies avant d'effectuer les changements sur le référentiel source
|
||||
- la seconde phase est une phase de nettoyage des référentiels synchronisés.
|
||||
Il s'agit de synchroniser les suppression effectuée sur l'un des référentiels. Le même système d'attributs pivots est utilisé pour le mapping des entrées entre plusieurs référentiels.
|
||||
|
||||
//'Success stories' sur le site de LSC pas assez détaillées
|
||||
Exemple de la BPI qui génère un annuaire centrale à partir de plusieurs fichiers CSV
|
||||
|
||||
### Schéma SUPANN2009
|
||||
|
||||
|
|
|
|||
Reference in New Issue