Gestion des utilisateurs

Familles systèmes utilisées

Les utilisateurs seront gérés par la famille “compte utilisateur” (USERACCOUNT). Les groupes d'utilisateurs seront gérés par la famille “groupe de compte” (GROUPACCOUNT).

La famille “compte utilisateur” aura les attributs suivants :

  1. login -obligatoire-
  2. password -obligatoire-
  3. nom affiché
  4. courriel
  5. identifiant système (calculé)
  6. informations : lien document personnel (lecture seule), lien vers un document tel que “personne” ⇒ en terme d'interface, les informations contenues dans ce document liée doivent être consultées et modifiables directement sur le compte de l'utilisateur.

Les paramètres familles :

  1. groupe par défaut

Méthode de “compte utilisateur” :

  1. transfertToLDAP

Cette famille sera responsable de la mise à jour de la table système “user”. Une action api permet de reconstruire la table “user” à partie de la table family.useraccount.

La famille “groupe de comptes” (hérité de dossier) aura les attributs suivants :

  1. nom du groupe
  2. description

Un groupe de compte aura les méthodes suivantes :

  1. getAccountMembers($recursive=true) : SearchDoc (liste des documents account du groupe et de ses dérivées (si recursive est vrai)
  2. getMailMembers($recursive=true): string (liste des adresses email concaténées des accounts)
  3. insertAccount($accountId) : string (error message) : l'id est soit un compte utilisateur soit un groupe de compte
  4. deleteAccount($accountId): string (error message)

Sécurité

Par défaut ces familles systèmes ont un profil administration (lecture pour all et écriture pour admin). Profil dynamique sur compte utilisateur permettant à l'utilisateur connecté de pouvoir modifier son password et son nom affiché. Création d'un contrôle de vue spécifique pour gérer cette modification de password.

- l'utilisateur ne peut que modifier son mot de passe
- comment répond on au besoin de gestion de groupes d'utilisateurs par un autre utilisateur (ex. délégation de la gestion d'un groupe d'utilisateur à un super utilisateur qui n'est pas admin mais qui a le droit), ne faut-il pas dissocier le droit de gérer des utilisateurs et groupes des droits documentaire. D'ou la question : quelle est l'intérêt de modéliser les utilisateurs et groupes par des documents ?
- ces familles système ne sont pas utilisables (recherche en particulier) hors de l'interface d'administration

Aide à la saisie

La fonction memberOf($idgroup, $displayname=””,) (fdl.php) permet de filtrer sur les membres (récursif) d'un groupe

Impact module freedom-networkuser

Ce module délivrera les familles “compte réseau” NETWORKUSERACCOUNT (hérité de USERACCOUNT), et “groupe réseau” NETWORKGROUPACCOUNT” (hérité de GROUPACCOUNT”).

NETWORKUSERACCOUNT

  1. ldap dn

Action :

  1. actualiser depuis le LDAP
  2. voir les infos LDAP

Interface proposée

Arbre des groupes. Sur un groupe on a la possibilités de :

  1. voir la liste des membres du groupe seul.
  2. voir la liste des membres du groupe et des sous-groupes.
  3. voir les propriétés des groupes ⇒ quelles propriétés ?
  4. modifier les membres (ajout et suppression)
  5. voir les droits du groupe (applicatif & documentaire 1))
  6. envoyer un courriel à l'ensemble des membres (mailto:)
  7. possibilité de manipuler les membres en lot (multi-sélection)

Sur un utilisateur :

  1. Comme sur un document “normal” ⇒ Non, un utilisateur n'est pas un document
  2. Modifier mes groupes (ajout ou suppression)
  3. voir les droits (applicatif & documentaire 2))

Le drag and drop d'un compte sur un groupe provoque l'ajout (ou le déplacement suivant touche shift/ctrl) du compte dans le groupe.

Migration

Un script wsh (convertiuser) permet de convertir les documents “IUSER” et “IGROUP” en compte. Pour chaque IUSER pur :

  1. un document “USER” est créé avec les infos non système de IUSER
  2. le document est converti en USERACCOUNT en récupérant le login, displayname = “prénom nom” et courriel ) us_mail.
  3. le document converti est lié avec sa fiche “personne” en modifiant l'attribut “informations”.

Pour chaque IGROUP pur :

  1. converti en GROUPACCOUNT

Pour chaque IUSER dérivé :

  1. la famille dérivée change d'héritage et est héritée de “personne” et non plus de “utilisateur”.
  2. un document de cette nouvelle famille est créée avec les infos non système de IUSER
  3. le document est converti en USERACCOUNT en récupérant le login, displayname = “prénom nom” et courriel )
  4. le document converti est lié avec sa fiche vers la famille spéciale

impact sur le code existant ?

Authentification et droits

L'authentification “interne” reste inchangé. Elle se fait sur la base des informations de la table “users”. Cette table perd ses colonnes “expires”, “passdelay”, “ntpasswordhash” et “lmpasswordhash”.

Les droits reste calculés à partir de la table group et users.

ne serait-il pas intéressant de conserver les mécanismes de gestion de mot de passe et lié à la gestion de connexion : changement forcé lors d'un première connexion, fréquence de modification du mot de passe, complexité du mot de passe, invalidation du compte (simple bouton) ?

1) , 2) ??
freedom_3/workinprogress/user_management.txt · Dernière modification: 05/05/2010 10:17 par marc