Redaction doc + LDIF de structuration de l'annuaire a adapter a SUPANN2009
This commit is contained in:
parent
f46c20b951
commit
3602704052
3755
Example.ldif
3755
Example.ldif
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,73 @@
|
|||
## Not overriding the hostname-derived default configuration ?
|
||||
|
||||
dn: dc=org
|
||||
objectClass: domain
|
||||
objectClass: top
|
||||
dc: org
|
||||
|
||||
dn: dc=entrouvert,dc=org
|
||||
objectClass: domain
|
||||
objectClass: top
|
||||
dc: entrouvert
|
||||
#
|
||||
dn: dc=dev,dc=entrouvert,dc=org
|
||||
objectClass: domain
|
||||
objectClass: top
|
||||
dc: dev
|
||||
|
||||
dn: dc=condorcet,dc=dev,dc=entrouvert,dc=org
|
||||
objectClass: domain
|
||||
objectClass: top
|
||||
dc: condorcet
|
||||
#aci: (target ="ldap:///dc=entrouvert,dc=lan")(targetattr !=
|
||||
# "userPassword")(version 3.0;acl "Anonymous read-search access";
|
||||
# allow (read, search, compare)(userdn = "ldap:///anyone");)
|
||||
#aci: (target="ldap:///dc=entrouvert,dc=lan") (targetattr =
|
||||
# "*")(version 3.0; acl "allow all Admin group"; allow(all) groupdn =
|
||||
# "ldap:///cn=Directory Administrators,ou=Groups,dc=entrouvert,dc=lan";)
|
||||
|
||||
dn: ou=Servers,dc=condorcet,dc=dev,dc=entrouvert,dc=org
|
||||
objectClass: organizationalUnit
|
||||
objectClass: top
|
||||
description: Company Servers
|
||||
ou: Servers
|
||||
|
||||
dn: ou=Groups,dc=condorcet,dc=dev,dc=entrouvert,dc=org
|
||||
objectClass: organizationalunit
|
||||
objectClass: top
|
||||
ou: Groups
|
||||
|
||||
dn: cn=Managers,ou=groups,dc=condorcet,dc=dev,dc=entrouvert,dc=org
|
||||
objectClass: groupOfUniqueNames
|
||||
objectClass: top
|
||||
ou: groups
|
||||
description: People who can manage accounting entries
|
||||
cn: Managers
|
||||
|
||||
dn: ou=People,dc=condorcet,dc=dev,dc=entrouvert,dc=org
|
||||
objectClass: organizationalunit
|
||||
objectClass: top
|
||||
ou: People
|
||||
|
||||
dn: uid=jmorrison,ou=People,dc=condorcet,dc=dev,dc=entrouvert,dc=org
|
||||
objectClass: person
|
||||
#objectClass: cos
|
||||
objectClass: inetOrgPerson
|
||||
objectClass: organizationalPerson
|
||||
objectClass: posixAccount
|
||||
objectClass: top
|
||||
uid: jmorrison
|
||||
#classOfService: gold
|
||||
userpassword: chevron
|
||||
facsimiletelephonenumber: +1 408 555 4661
|
||||
givenname: Jim
|
||||
cn: Jim Morrison
|
||||
telephonenumber: +1 408 555 9445
|
||||
sn: Morrison
|
||||
roomnumber: 2290
|
||||
homeDirectory: /home/jmorrison
|
||||
mail: jmorrison@example.com
|
||||
l: Pere Lachaise
|
||||
ou: People
|
||||
uidNumber: 1119
|
||||
gidNumber: 1000
|
32
doc.md
32
doc.md
|
@ -516,6 +516,13 @@ On parle d'étiquetage des attributs
|
|||
|
||||
Comment modéliser le lien entre les différents profils, rattachés à une seule identité réelle
|
||||
TODO explication des différentes stratégies pou remédier à ce problème
|
||||
attributs composites
|
||||
référencement (système de pointeurs)
|
||||
reconstitution d'un profil par informations contenues à différents endroits de l'annuaire -> contournement du problème par non-duplication des données
|
||||
regroupement des profils d'une personne au sein d'un même groupe
|
||||
aliases TODO pourquoi ?
|
||||
pointeurs TODO
|
||||
|
||||
|
||||
## PABX ?
|
||||
## NIS ?
|
||||
|
@ -660,7 +667,8 @@ TODO : Section 1.2 (*Environmental Assumptions*) mérite d'être détaillée ici
|
|||
TODO Installation et déploiement en local
|
||||
TODO Ecriture d'un dummy SP pour tester Authentic ??
|
||||
|
||||
TODO Expliquer les particularités de la licence GNU Affero GPL (APGL)
|
||||
TODO Expliquer les particularités de la licence GNU Affero GPL (APGL) :
|
||||
- l'utilisation du code pour des applications Web déployées est pris en compte dans le caractère transitif ("contaminant") de la licence.
|
||||
TODO Quel intérêt de licencier la documentation sous Creative Commons ?
|
||||
#### Documentation
|
||||
Comprendre l'interaction avec Lasso pour le support SAMLv2
|
||||
|
@ -1885,8 +1893,30 @@ Gadjo sur la page finale passerelle
|
|||
Adaptation SUPANN2009
|
||||
|
||||
## Explications techniques Mik
|
||||
|
||||
//EN COURS
|
||||
|
||||
Se concentrer sur l'étude de synchro et d'approvisionnement en tant que telle
|
||||
La partie de mapping entre un événement déclenché et l'action WCS à effectuer mérite réflexions.
|
||||
|
||||
Dans quelle mesure le connecteur pourra être générique ?
|
||||
Les mêmes règles ne s'appliqueront-elles pas à tous les connecteurs ?
|
||||
|
||||
Le connecteur est en fait utilisé en écriture seulement : il sert à des fins d'approvisionnement et de synchronisation
|
||||
|
||||
Pour la lecture, un simple script ou outil de polling sera utilisé
|
||||
|
||||
Une des problématiques centrales à cette étude est la façon d'éviter les boucles/effets de bords provoqués par les changements en cascade sur les différents référentiels. Une modification effectuée par le système d'approvisionnement et de synchro ne doit pas être confondue avec une modification externe, nécessitant une éventuelle synchro avec d'autre référentiels
|
||||
|
||||
Plusieurs solutions s'offrent à nous pour remédier à ce problème :
|
||||
- garder une historique des actions (timestamp/horodatage) dans WCS pour ne pas les faire remonter lors du polling
|
||||
Cette solution nécessite une synchronisation de l'horloge des différentes briques logicielles de l'infra
|
||||
- utiliser un marqueur/flag du type `performedByWCS` pour chacunes des actions appliquées à un référentiel
|
||||
Le système de polling ne concernera que les actions ne portant pas le marqueur
|
||||
|
||||
=> TODO aller chercher un ou plusieurs scenario de processus en entreprise justifiant un outil de synchro
|
||||
Dans une deuxième phase, il faudra étudier ce qui serait déjà possible avec les outils EO tels quel
|
||||
|
||||
|
||||
# Ecriture connecteur
|
||||
Première étape :
|
||||
|
|
Reference in New Issue