entrouvert
/
paul-synchro
Archived
17
0
Fork 0
Code Issues Pull Requests Releases Activity

Documentation OpenLDAP

This commit is contained in:
Paul Marillonnet 2017-02-27 18:07:35 +01:00
parent 38cf2b64dd
commit 0ddb98a799
1 changed files with 19 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
doc.md
View File

@ -197,18 +197,29 @@ La recherche d'entrées dans un annuaire se fait selon une portée (*scope*) :
Les filtres définissent leur propre syntaxe d'expressions régulières et d'expressions booléennes pour imposer des conditions logiques sur les attributs des entrées recherchées.
Prenons par exemple la requête suivante :
TODOTODOTODO
```
"(|(telephoneNumber=*)(mail=*)(street=*))"
```
filtres => Revoir les filtres étendus TODO
opérations cf liste : 11 opérations à connaître (*abandon, add, bind, compare, delete, extended, modify, modify DN, rename, search, unbind*). Propriétés modulaires de SASL (délégation de l'authentification à un mécanisme tiers).
La RFC stipule que le symbole `|` désigne l'opérateur logique OU. Ainsi, la recherche ci-dessus renvoie toutes les entrées (à partir du DN définissant le sous-arbre de recherche) dont l'un des trois champs `telephoneNumber`, `mail` ou `street` est désigné.
URLs Echappement par caractères hexadécimal préfixé par %
`ldap[s]://<hostname>:<port>/<base_dn>?<attributes>?<scope>?&<filter>?<extensions>`
De façon similaire, l'opérateur logique ET est représenté par le symbole `&`.
Opérations côté client de type CRUD
On remarquera par ailleurs que la RFC standardise une syntaxe de requêtes étendue permettant d'exprimer des conditions logiques plus complexes que ce qui est présenté ici. Nous renvoyons le lecteur à la documentation en ligne abordant la notions de filtres étendus, notamment les paragraphes 2 et 3 de la RFC4515 (String representation of LDAP Search Filters).
Parti pris d'optimisation les lectures sur les écritures.
Les filtres ne prennent sens que par association aux différentes opérations effectuable sur l'annuaire . Elles sont au nombre de 11 : *abandon*, *add*, *bind*, *compare*, *delete*, *extended*, *modify*, *modify DN*, *rename*, *search*, *unbind*. Ces opérations appartiennent chacunes à l'une des quatre catégories CRUD (Create,Read, Update, Delete).
De par la nature-même de la structure d'annuaire, les développeurs de OpenLDAP ont pris le parti de proposer une implémentation optimisant les opérations de lecture au détriment des opérations d'écriture.
Enfin, il est important de noter que LDAP s'appuie sur les propriétés modulaires de SASL, lesquelles permettent délégation de l'authentification à un mécanisme tiers, spécialisé dans cette tâche.
//
//URLs Echappement par caractères hexadécimal préfixé par %
//`ldap[s]://<hostname>:<port>/<base_dn>?<attributes>?<scope>?&<filter>?<extensions>`
//
//Opérations côté client de type CRUD
//
//
#### Modèle d'information
DIT (*Directory Information tree*)
@ -1074,6 +1085,7 @@ https://docs.djangoproject.com/fr/1.10/topics/http/sessions/
http://stackoverflow.com/questions/20957388/what-is-a-context-in-django
https://docs.djangoproject.com/fr/1.10/topics/i18n/
http://ldap3.readthedocs.io/tutorial.html
https://tools.ietf.org/search/rfc4515
## A lire
http://support.novell.com/techcenter/articles/ana20011101.html
http://www.journaldunet.com/developpeur/xml/analyse/la-federation-d-identite-au-travers-de-saml.shtml