inclusion wcs + passerelle
This commit is contained in:
parent
c9d4acc871
commit
0c2b3d5a29
104
doc.md
104
doc.md
|
|
@ -79,110 +79,6 @@ Licence Apache
|
|||
|
||||
# Formulaires
|
||||
|
||||
## w.c.s.
|
||||
L'outil de gestion de formulaires et de workflow a été utilisé dans la mise en place du POC. L'utilisation du protocole https nécessite d'installer modules Apache ssl (l'une des implémentations openssl ou gnutls), scgi, rewrite.
|
||||
|
||||
La gestion de l'authentification dans w.c.s. nécessite la définition d'une méthode de signature. La méthode retenue est
|
||||
```
|
||||
BASE64(HMAC-HASH(query_string+'algo=HASH×tamp=' + timestamp + '&orig=" + orig, clé))
|
||||
```
|
||||
|
||||
BASE64 désigne l'encodage en base 64 (i.e. sur 6 octets) de la signature. Par ailleurs, HMAC-HASH est la fonction de hachage utilisée pour signer les messages. Spécifique à la génération de code d'authentification, cette méthode repose sur l'utilisation d'une clé secrète.
|
||||
|
||||
|
||||
Retrait de l'exception enpêchant l'absence de signature dans les appels à l'API -> Commentée
|
||||
Pas pertinent pour l'instant dans le cadre du POC
|
||||
|
||||
|
||||
Gestion locale de l'authent, pas de recours à un IdP pour w.c.s. : pas nécessaire dans le cadre du POC ?
|
||||
Se connecter en tant qu'admin pour pouvoir accéder aux interfaces de gestion des formulaires en attente d'acceptation
|
||||
|
||||
Quel algo de hachage pour le champ password en wcs ?
|
||||
|
||||
### API ReST
|
||||
L'API proposée par l'outil w.c.s. suit les conventions REST telles que définies par Roy Fielding au début des années 2000.
|
||||
|
||||
Ce design pattern propose une utilisation cohérente et consistante des méthodes HTTP (RFC7231) comme unique moyen de communication entre un client et un fournisseur de service.
|
||||
|
||||
Par convention, à chaque méthode HTTP est associée un action :
|
||||
- POST pour la création d'une ressource sur le serveur
|
||||
- PUT pour la mise à jour d'une ressource
|
||||
- GET pour la lecture
|
||||
- DELETE pour la suppression
|
||||
|
||||
TODO HATEOAS ?
|
||||
|
||||
### JSON
|
||||
|
||||
Le format de données utilisé pour la communication avec w.c.s. est JSON (JavaScript Object Notation).
|
||||
Cette notation déclarative permet la description d'objets, en fournissant un ensemble de type clé-valeur structuré.
|
||||
|
||||
Prenons l'exemple de la définition d'un schéma de formulaire par w.c.s :
|
||||
|
||||
```
|
||||
json
|
||||
{
|
||||
"always_advertise": true,
|
||||
"category": "test2",
|
||||
"category_id": "2",
|
||||
"confirmation": true,
|
||||
"description": null,
|
||||
"detailed_emails": true,
|
||||
"disabled": false,
|
||||
"disabled_redirection": null,
|
||||
"discussion": false,
|
||||
"enable_tracking_codes": false,
|
||||
"expiration_date": null,
|
||||
"fields": [
|
||||
{
|
||||
"label": "Email",
|
||||
"prefill": {
|
||||
"type": "none"
|
||||
},
|
||||
"required": true,
|
||||
"type": "string",
|
||||
"varname": "email"
|
||||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
On remarque ainsi la façon dont listes et dictionnaires sont utilisées pour la description structurelles des différents champs définissant un objet.
|
||||
(Champs multivalués, inclusion de sous-objets, etc).
|
||||
|
||||
### Plugin Passerelle
|
||||
Le plugin passerelle fournit un ensemble de connecteurs permettant le dialogue entre w.c.s. et des sources de données et services de nature différentes.
|
||||
|
||||
Lors de la mise en place du POC, Passerelle a été utilisé pour l'établissement de la connexion LDAP depuis w.c.s.
|
||||
|
||||
Nous détaillons ici le scénario d'utilisation de Passerelle tel qu'implémenté dans le POC : Une fois l'entrée w.c.s. renseignée par l'utilisateur et complétée par l'agent, le plugin passerelle peut alors exploiter l'API REST pour aller chercher les données relatives aux réponses du formulaire, pour aller créer l'entrée LDAP.
|
||||
L'interface avec le serveur OpenLDAP se fait à l'aide de la bibliothèque python `ldap3`.
|
||||
|
||||
La première étape de l'implémentation, après définition de l'interface, est l'écriture des fonctions du package `utils`, qui vont exploiter ldap3.
|
||||
|
||||
L'interface de LDAP n'est pas 'pythonique' et depassée, car basée sur l'idée que les opérations lourdes doivent être effectuées sur le client. //TODIG
|
||||
|
||||
Cf ldap3 abstraction layer
|
||||
|
||||
Une fois notre cas d'utilisaton spécifique de l'annuaire mis en place, nous tâchons d'implémenter un connecteur LDAP générique, basé sur le connecteur CSV déjà présent dans Passerelle.
|
||||
Ce connecteur devra supporter un grand nombre d'opérations sur un annuaire du choix de l'utilisateur. Ainsi, l'interface de saisie de la requête LDAP laisse l'utilisateur libre de préciser tous les paramètres de la requête à effectuer sur l'annuaire.
|
||||
|
||||
La gestion des droits est laissée aux soins du serveur LDAP qui gère ses propres contrôles d'accès (par des ACL).
|
||||
|
||||
TODO Serveur, credentials et DN founis par l'utilisateur à la création du connecteur ? DONE
|
||||
|
||||
Il est nécessaire d'effectuer quelques recherches documentaires sur l'API python ldap3 pour la mise en place d'une interface Web de requêtes sur le connecteur.
|
||||
|
||||
Plusieurs points sont à mentionner ici:
|
||||
- ldap3 prend en charge les modifications sur l'annuaire par utilisation d'un fichier LDIF (LDAP Data Interchange Format).
|
||||
|
||||
TODO http://ldap3.readthedocs.io/operations.html
|
||||
|
||||
### Config SMTP
|
||||
Lors de la réalisation du POC, la phase de demande de création d'un compte invité sur le méta-annuaire
|
||||
Une configuration SMTP est nécessaire pour l'automatisation des alertes email lorsqu'un
|
||||
TODO rappel SMTP
|
||||
|
||||
# POC
|
||||
## Presentation
|
||||
Dans le cadre du projet Campus Condorcet, les annuaires de différents établissements doivent être regroupés en un méta-annuaire central. Aussi des problématiques d'homogénéisation de données hétérogènes se pose.
|
||||
|
|
|
|||
|
|
@ -503,6 +503,109 @@ django.contrib.auth.models.User
|
|||
|
||||
|
||||
## w.c.s / Passerelle
|
||||
L'outil de gestion de formulaires et de workflow a été utilisé dans la mise en place du POC. L'utilisation du protocole https nécessite d'installer modules Apache ssl (l'une des implémentations openssl ou gnutls), scgi, rewrite.
|
||||
|
||||
La gestion de l'authentification dans w.c.s. nécessite la définition d'une méthode de signature. La méthode retenue est
|
||||
```
|
||||
BASE64(HMAC-HASH(query_string+'algo=HASH×tamp=' + timestamp + '&orig=" + orig, clé))
|
||||
```
|
||||
|
||||
BASE64 désigne l'encodage en base 64 (i.e. sur 6 octets) de la signature. Par ailleurs, HMAC-HASH est la fonction de hachage utilisée pour signer les messages. Spécifique à la génération de code d'authentification, cette méthode repose sur l'utilisation d'une clé secrète.
|
||||
|
||||
|
||||
Retrait de l'exception enpêchant l'absence de signature dans les appels à l'API -> Commentée
|
||||
Pas pertinent pour l'instant dans le cadre du POC
|
||||
|
||||
|
||||
Gestion locale de l'authent, pas de recours à un IdP pour w.c.s. : pas nécessaire dans le cadre du POC ?
|
||||
Se connecter en tant qu'admin pour pouvoir accéder aux interfaces de gestion des formulaires en attente d'acceptation
|
||||
|
||||
Quel algo de hachage pour le champ password en wcs ?
|
||||
|
||||
### API ReST
|
||||
L'API proposée par l'outil w.c.s. suit les conventions REST telles que définies par Roy Fielding au début des années 2000.
|
||||
|
||||
Ce design pattern propose une utilisation cohérente et consistante des méthodes HTTP (RFC7231) comme unique moyen de communication entre un client et un fournisseur de service.
|
||||
|
||||
Par convention, à chaque méthode HTTP est associée un action :
|
||||
- POST pour la création d'une ressource sur le serveur
|
||||
- PUT pour la mise à jour d'une ressource
|
||||
- GET pour la lecture
|
||||
- DELETE pour la suppression
|
||||
|
||||
TODO HATEOAS ?
|
||||
|
||||
### JSON
|
||||
|
||||
Le format de données utilisé pour la communication avec w.c.s. est JSON (JavaScript Object Notation).
|
||||
Cette notation déclarative permet la description d'objets, en fournissant un ensemble de type clé-valeur structuré.
|
||||
|
||||
Prenons l'exemple de la définition d'un schéma de formulaire par w.c.s :
|
||||
|
||||
```
|
||||
json
|
||||
{
|
||||
"always_advertise": true,
|
||||
"category": "test2",
|
||||
"category_id": "2",
|
||||
"confirmation": true,
|
||||
"description": null,
|
||||
"detailed_emails": true,
|
||||
"disabled": false,
|
||||
"disabled_redirection": null,
|
||||
"discussion": false,
|
||||
"enable_tracking_codes": false,
|
||||
"expiration_date": null,
|
||||
"fields": [
|
||||
{
|
||||
"label": "Email",
|
||||
"prefill": {
|
||||
"type": "none"
|
||||
},
|
||||
"required": true,
|
||||
"type": "string",
|
||||
"varname": "email"
|
||||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
On remarque ainsi la façon dont listes et dictionnaires sont utilisées pour la description structurelles des différents champs définissant un objet.
|
||||
(Champs multivalués, inclusion de sous-objets, etc).
|
||||
|
||||
### Plugin Passerelle
|
||||
Le plugin passerelle fournit un ensemble de connecteurs permettant le dialogue entre w.c.s. et des sources de données et services de nature différentes.
|
||||
|
||||
Lors de la mise en place du POC, Passerelle a été utilisé pour l'établissement de la connexion LDAP depuis w.c.s.
|
||||
|
||||
Nous détaillons ici le scénario d'utilisation de Passerelle tel qu'implémenté dans le POC : Une fois l'entrée w.c.s. renseignée par l'utilisateur et complétée par l'agent, le plugin passerelle peut alors exploiter l'API REST pour aller chercher les données relatives aux réponses du formulaire, pour aller créer l'entrée LDAP.
|
||||
L'interface avec le serveur OpenLDAP se fait à l'aide de la bibliothèque python `ldap3`.
|
||||
|
||||
La première étape de l'implémentation, après définition de l'interface, est l'écriture des fonctions du package `utils`, qui vont exploiter ldap3.
|
||||
|
||||
L'interface de LDAP n'est pas 'pythonique' et depassée, car basée sur l'idée que les opérations lourdes doivent être effectuées sur le client. //TODIG
|
||||
|
||||
Cf ldap3 abstraction layer
|
||||
|
||||
Une fois notre cas d'utilisaton spécifique de l'annuaire mis en place, nous tâchons d'implémenter un connecteur LDAP générique, basé sur le connecteur CSV déjà présent dans Passerelle.
|
||||
Ce connecteur devra supporter un grand nombre d'opérations sur un annuaire du choix de l'utilisateur. Ainsi, l'interface de saisie de la requête LDAP laisse l'utilisateur libre de préciser tous les paramètres de la requête à effectuer sur l'annuaire.
|
||||
|
||||
La gestion des droits est laissée aux soins du serveur LDAP qui gère ses propres contrôles d'accès (par des ACL).
|
||||
|
||||
TODO Serveur, credentials et DN founis par l'utilisateur à la création du connecteur ? DONE
|
||||
|
||||
Il est nécessaire d'effectuer quelques recherches documentaires sur l'API python ldap3 pour la mise en place d'une interface Web de requêtes sur le connecteur.
|
||||
|
||||
Plusieurs points sont à mentionner ici:
|
||||
- ldap3 prend en charge les modifications sur l'annuaire par utilisation d'un fichier LDIF (LDAP Data Interchange Format).
|
||||
|
||||
TODO http://ldap3.readthedocs.io/operations.html
|
||||
|
||||
### Config SMTP
|
||||
Lors de la réalisation du POC, la phase de demande de création d'un compte invité sur le méta-annuaire
|
||||
Une configuration SMTP est nécessaire pour l'automatisation des alertes email lorsqu'un
|
||||
TODO rappel SMTP
|
||||
|
||||
|
||||
## ReSTful APIs
|
||||
|
||||
|
|
|
|||
Reference in New Issue