inclusion SUPANN
This commit is contained in:
parent
4e6dece254
commit
9fe5b9fb42
53
doc.md
53
doc.md
|
|
@ -28,59 +28,6 @@ Compilation :
|
|||
|
||||
## SUPANN
|
||||
|
||||
### Présentation du standard
|
||||
SUPANN est une spécification de schéma d'annuaire propre à l'enseignement supérieur français.
|
||||
//Calqué sur ou du moins inspiré par le modèle organisationnel universitaire aux Etats-Unis.
|
||||
|
||||
Repose sur un schéma LDAP standard
|
||||
|
||||
Besoins de sécurité justifient l'utilisation d'un seul schéma de référentiel d'identités pour l'ensemble des établissements de l'enseignement supérieur français (EES).
|
||||
//En réalité, on dirait que chacun a sa propre compréhension du référentiel.
|
||||
|
||||
Pbatique, assez fortement nationale, de la fédération d'identités.
|
||||
Nécessité de la conformité sémantique et syntaxique des données de l'annuaire de chaque établissement : condition nécessaire à la mise en place d'une fédération d'identités.
|
||||
|
||||
Nombreux éléments LDAP génériques (dcObject, organisationalUnit, etc.)
|
||||
Notamment un attribut intéressant dans le cadre du POC : eduPersonPrincipalName
|
||||
|
||||
SupannRedId nécessaire aussi pour la pbatique des déménagements.
|
||||
|
||||
Mots-clé de préconisation au même titre que les RFC de l'IETF.
|
||||
DOIT (EXIGÉ), NE DOIT PAS, DEVRAIT (RECOMMANDÉ), NE DEVRAIT PAS (NON RECOMMANDÉ) et PEUT (OPTIONNEL)
|
||||
|
||||
### SUPANN et cadre légal
|
||||
La CNIL impose 5 contraintes concernant les données :
|
||||
- finalité
|
||||
- proportionnalité
|
||||
- durée de conservation limitée
|
||||
- sécurité/confidentialité
|
||||
- respect des droits des personnes
|
||||
|
||||
### Réutilisation de LDAP
|
||||
LDAP plus performant qu'un SGBDR pour ce qui est des lectures de données.
|
||||
|
||||
### Nomenclatures
|
||||
Réutilisation de spécifications de EES concernant certains attributs SUPANN
|
||||
|
||||
Cf la Base Centrale des Nomenclatures
|
||||
La nomenclature utilisée est mentionnée en début de valeur de l'attribut, entres accolades
|
||||
Exemple donné dans la doc, {SISE}...
|
||||
{SISE} symbolisant la nomenclature du système d'information pour le Suivi des Etudiants
|
||||
|
||||
On parle d'étiquetage des attributs
|
||||
|
||||
### Profils multiples
|
||||
|
||||
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 ?
|
||||
## DNS/Whois ? (pas vraiment de la GI ?)
|
||||
|
|
|
|||
|
|
@ -649,6 +649,59 @@ Exemple de la BPI qui génère un annuaire centrale à partir de plusieurs fichi
|
|||
|
||||
### Schéma SUPANN2009
|
||||
|
||||
#### Présentation du standard
|
||||
SUPANN est une spécification de schéma d'annuaire propre à l'enseignement supérieur français.
|
||||
//Calqué sur ou du moins inspiré par le modèle organisationnel universitaire aux Etats-Unis.
|
||||
|
||||
Repose sur un schéma LDAP standard
|
||||
|
||||
Besoins de sécurité justifient l'utilisation d'un seul schéma de référentiel d'identités pour l'ensemble des établissements de l'enseignement supérieur français (EES).
|
||||
//En réalité, on dirait que chacun a sa propre compréhension du référentiel.
|
||||
|
||||
Pbatique, assez fortement nationale, de la fédération d'identités.
|
||||
Nécessité de la conformité sémantique et syntaxique des données de l'annuaire de chaque établissement : condition nécessaire à la mise en place d'une fédération d'identités.
|
||||
|
||||
Nombreux éléments LDAP génériques (dcObject, organisationalUnit, etc.)
|
||||
Notamment un attribut intéressant dans le cadre du POC : eduPersonPrincipalName
|
||||
|
||||
SupannRedId nécessaire aussi pour la pbatique des déménagements.
|
||||
|
||||
Mots-clé de préconisation au même titre que les RFC de l'IETF.
|
||||
DOIT (EXIGÉ), NE DOIT PAS, DEVRAIT (RECOMMANDÉ), NE DEVRAIT PAS (NON RECOMMANDÉ) et PEUT (OPTIONNEL)
|
||||
|
||||
#### SUPANN et cadre légal
|
||||
La CNIL impose 5 contraintes concernant les données :
|
||||
- finalité
|
||||
- proportionnalité
|
||||
- durée de conservation limitée
|
||||
- sécurité/confidentialité
|
||||
- respect des droits des personnes
|
||||
|
||||
#### Réutilisation de LDAP
|
||||
LDAP plus performant qu'un SGBDR pour ce qui est des lectures de données.
|
||||
|
||||
#### Nomenclatures
|
||||
Réutilisation de spécifications de EES concernant certains attributs SUPANN
|
||||
|
||||
Cf la Base Centrale des Nomenclatures
|
||||
La nomenclature utilisée est mentionnée en début de valeur de l'attribut, entres accolades
|
||||
Exemple donné dans la doc, {SISE}...
|
||||
{SISE} symbolisant la nomenclature du système d'information pour le Suivi des Etudiants
|
||||
|
||||
On parle d'étiquetage des attributs
|
||||
|
||||
#### Profils multiples
|
||||
|
||||
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
|
||||
|
||||
|
||||
### Authentification et SSO
|
||||
|
||||
#### Kerberos (?)
|
||||
|
|
|
|||
Reference in New Issue