FR2805628A1 - Procede d'administration deleguee des donnees d'un annuaire d'entreprise - Google Patents

Abstract

La présente invention conceme un procédé d'administration déléguée des données d'un annuaire d'entreprise ayant une structure arborescente et manipulant des éléments d'information d'un système d'information décrits respectivement dans des concepts élémentaires du système d'information appelé CESI et par lesquels une instance, ou entrée d'annuaire, est modélisée sous forme de formulaires, ou panels, correspondant à des ensembles d'attributs de l'entrée, caractérisé en ce qu'il consiste à modéliser les entrées de l'annuaire sous forme de CESI de manière à les rendre aptes à recevoir une délégation d'administration sur les données, et à modéliser des habilitations sous forme de domaines d'administration pour définir les utilisateurs habilités et leurs portées respectives ainsi que les données pouvant être administrées dans le domaine considéré.

Description

Procédé d'administration déléguée des données annuaire d'entreprise présente invention se situe dans le domaine des annuaires d'entreprise.

Elle concerne plus particulièrement un procédé d'administration déléguée des données d'un annuaire" d'entreprise sécurisé et prenant en compte la diversité informations gérées, notamment dans des architectures intranet architectures intranet s'articulent aujourd'hui autour composant devenu essentiel : l'annuaire d'entreprise. Celui-ci répertorie stocke les informations concernant toutes les ressources d'un système d'information telles les utilisateurs, les organisations, les machines et les applications. La nature des informations stockées concerne le plus souvent données identification, les profils, les privilèges ainsi que le paramétrage applicatif. Ainsi, les utilisateurs comme les applications du système information accèdent à l'annuaire pour quérir des informations afin d'authentifier un intervenant ou connaître ses habilitations.

applications accèdent en outre à l'annuaire pour obtenir leurs paramètres configuration.

L'annuaire devient donc un composant clé pour l'administration l'intranet et applications qui le composent. Les principales qualités attendues pour un annuaire sont la facilité d'intégration : le protocole standardisé LDAPv3, abréviations anglo-saxonnes pour "Lightweight Directory Access Protocol", adopté par les applications de type serveur ou client, garantit une intégration aisée avec l'annuaire; la distribution : les mécanismes de réplication, ou "refferal" selon la terminologie anglo-saxonne, permettent la distribution aisee l'annuaire au travers du réseau intranet indépendamment du nombre sites ; les performances: les produits permettent à ce jour resolution de plusieurs centaines de requêtes par seconde et supportent plus d'un million d'entrées ; - l'administration<B>:</B> l'administration de l'annuaire doit être susceptible fournir des outils nécessaires aux personnes à même d'administrer données de l'annuaire. Elle doit prendre en compte en outre la diversité informations gérées, c'est-à-dire la diversité des applications et la diversite des administrateurs.

Les systèmes d'information sont souvent contraints à une mutualisation ressources informatiques de façon à minimiser les coûts d'infrastructure d'exploitation. Cette mutualisation permet bien souvent aussi, développement de nouveaux services tels que par exemple la haute disponibilite.

Toutefois, mutualisation des ressources ne doit pas s'accompagner éloignement des centres de décision sous peine d'engendrer le refus par utilisateurs terrain d'un outil devenu lourd et difficile à gérer. C'est pourquoi, si la mutualisation des ressources permet la factorisation des services d'administration système, en revanche l'administration des données doit être déléguée auprès des gestionnaires locaux qui possèdent l'information et qui sont à même de prendre les décisions les plus appropriées avec la meilleure réactivité.

Par "administration des données", il faut comprendre non pas "administration des donnees de l'annuaire", mais "administration des données des applications". En effet, l'administration des données ne doit pas avoir pour objectif d'administrer l'annuaire mais bien d'administrer, depuis un point unique, multiples applications de l'intranet. L'administration des données assure mutualisation de l'administration des différentes applications de l' intranet.

Une administration déléguée des données d'un annuaire d'entreprise nécessite - une modélisation des habilitations pour définir - utilisateurs habilités ; - portée de l'administration appelée également "domaine"; et - les données pouvant être administrées dans le domaine (notion de filtre) ; - un procédé qui contrôle l'accès des administrateurs en vérifiant leurs habilitations.

On connaît des solutions proposant des annuaires d'entreprise notamment une solution développée par la société Oblix. Cependant, cette solution introduit des informations propres dans les données gérées et nécessite une modification du schéma d'annuaire.

La société Calendra propose une solution appelée "Calendra Directory Manager". Cette solution ne propose pas une délégation une sous- délégation d'administration sur les données. Par ailleurs, cette solution se base sur un mécanisme de contrôle d'accès propre à l'annuaire, ce le sollicite anormalement.

société Atos (Martien) propose une solution appelée "Webdir". Cette solution ne propose pas une administration fine s'appuyant sur une modélisation par formulaire des données de l'annuaire.

présente invention à pour but de pallier les inconvénients précités et de répondre aux exigences définies précédemment.

présente invention propose les avantages suivants procédé d'administration a notamment pour avantage demeurer compatible avec les contraintes des architectures annuaire modulaires, tant en terme d'évolution du schéma que de distribution de l'annuaire ou la politique sécurité adoptée.

procédé ne nécessite ni modification du schéma d'annuaire données administrées ni adjonction d'attributs spécifiques. II repose sur l'arborescence l'annuaire et la structuration des données en formulaires, appelés également "panels" dans la suite de la description, par le procédé indépendamment de l'annuaire.

procédé selon l'invention fournit ainsi un outil adapté et sécurisé au gestionnaire qui possède effectivement les données nécessaires pour prendre décision d'administration. Un premier objectif de la présente invention est de faciliter la gestion des utilisateurs la création de modèles. En effet, un ensemble modèles permet de predéfinir les ressources allouées aux utilisateurs. Ainsi, par l'allocation modèle, l'utilisateur hérite de l'accès à un ensemble déterminé d'applications intranet.

Un deuxième objectif de la présente invention est de pouvoir controler l'accès aux fonctions gestions des données de l'annuaire.

Un troisième objectif de la présente invention est de pouvoir controler l'accès aux fonctions gestions des habilitations.

A cet effet, l'invention a pour premier objet un procédé d'administration déléguée données d'un annuaire d'entreprise ayant une structure arborescente et manipulant des éléments d'information système d'information décrits respectivement dans des concepts élementaires du système d'information appelé CESI et par lesquels une instance, ou entrée d'annuaire, modélisée sous formes de formulaires, ou panels, correspondant a des ensembles d'attributs de l'entrée.

Selon l'invention, le procédé consiste à modéliser les entrées de l'annuaire sous forme CESI de manière à les rendre aptes à recevoir une délégation d'administration sur les données, et à modéliser des habilitations sous forme de domaines d'administration pour définir les utilisateurs habilites et leurs portées respectives ainsi que les données pouvant être administrees dans le domaine considéré.

L'invention pour deuxième objet une architecture d'une application d'administration déléguée mettant en oeuvre le procédé décrit ci-dessus.

Elle comporte un poste client et un serveur annuaire reliés par réseau de communication le poste client comportant - un navigateur Web en charge du protocole d'accès au serveur; - une applet destinée à gérer l'interface utilisateur; le serveur annuaire comportant - un serveur Web gérant le protocole de communication avec le poste client; - une servlet qui assure la gestion des données de l'annuaire conformément aux habilitations, et la gestion des habilitations ; - un moteur de servlet couplée à la servlet gérant les ressources de servlet ; - un annuaire comprenant les données gérées; - une base des habilitations; et - un fichier de configuration décrivant la structuration des données l'annuaire sous forme de CESI.

D'autres avantages et caractéristiques de la présente invention apparaîtront a la lecture la description qui suit faite en référence aux figures annexées qui représentent - la figure , une architecture générale d'une application mettant en oeuvre procède selon l'invention ; - la figure le diagramme de paquetages de la servlet mis en oeuvre dans procède selon l'invention ; - la figure le diagramme de classes du paquetage domaine de la servlet ; - la figure le diagramme de classes du paquetage infra servletlapplet selon l'invention ; - la figure l'arbre des tâches ; et - la figure un scénario d'une communication appletlservlet.

La présente invention s'appuie sur différents concepts et définitions qui sont explicités ' après.

Le procédé selon l'invention administre des éléments d'information du système d'information. Ceux-ci sont dotés d'un type, "typés", pour être apte à être administres suivant une délégation d'administration donnée.

Un type appelé un CESI, abréviations pour "Composant Elémentaire du Système d'Information".

Une instance, ou entrée d'annuaire, est appelée EntreeCESI.

Les EntreeCESI, gérées dans l'annuaire par le procédé selon l'invention, sont modélisées sous forme d'un ensemble de formulaires appelés également "panels". La définition d'un CESI comprend en particulier un label, le critère de recherche LDAP des entrées d'annuaire, une liste ordonnée de panels, le critère de visualisation, la liste des attributs à partir desquels une recherche peut être menée.

Un panel permet de modéliser un profil par une famille d'attribut. comprend un label et une liste ordonnée d'attributs.

Les attributs panels correspondent aux attributs des entrées d'annuaire. Ils sont définis un label représentatif et l'attribut d'annuaire correspondant. Des notions syntaxes plus fines que celles définies par schéma d'annuaire sont nécessaires pour prendre en compte des listes énumerées (par ex: vrai, faux). plus, la valeur d'initialisation est paramétrable pour pouvoir tenir compte valeur d'autres attributs.

Les deux profils utilisateurs de l'application sont le profil administrateur système et profil administrateur délégué.

L'administrateur système installe la solution et accède aux fichiers de configuration. plus, il définit les délégations racines.

L'administrateur délégué gère, dans un domaine de délégation déterminé et en fonction.des regles qui définissent celui-ci, les données de l'annuaire. II peut, de plus, sous-déléguer la gestion des données de l'annuaire ' un autre administrateur.

Un domaine d'administration est défini - par une portée: l'implémentation de cette portée s'appuie noeud d'annuaire ' partir duquel les données appartenant à la sous-arborescence définie par noeud sont gérées; - par un groupe d'administrateurs délégués pouvant comprendre sous- groupe d'administrateurs (administrateurs sous-délégués) ; - par des privilèges, c'est-à-dire, par des droits de création et destruction d'entrées d'annuaire répondant à un type déterminé, et droits de modification sur des ensembles d'attributs de l'entrée: l'implementation de la définition des types d'entrées d'annuaire s'appuie sur le concept du CESI défini ci-dessus<B>;</B> les ensembles d'attributs étant définis par des panels. A titre remarque, l'obtention in extenso de la liste des administrateurs délégués, pour un domaine d'administration déterminé, nécessite donc de calculer contenu d'un groupe et des sous-groupes associés, s'il y a lieu. De plus, la liste hérite aussi des administrateurs délégués des domaines d'administration supérieurs.

Le procedé d'administration et de contrôle d'accès selon l'invention est décrit ci-après.

Le privilège de création sur un CESI déterminé, donne le droit à un administrateur du domaine d'administration de créer dans la sous- arborescence une entrée d'annuaire typée par le CESI.

Le privilege de destruction sur un CESI déterminé, donne le droit â un administrateur du domaine d'administration de détruire dans la sous- arborescence une entrée d'annuaire du type du CESI spécifié.

Les privileges de création et de destruction sur un CESI déterminé, donnent droits à un administrateur du domaine d'administration de déplacer dans sous-arborescence une entrée d'annuaire du type du CESI spécifié.

Le droit modification sur un panel déterminé d'un CESI déterminé, donne droit à un administrateur du domaine d'administration de mettre à jour attributs appartenant au dit panel d'une entrée d'annuaire répondant au type défini par le dit CESI dans la sous-arborescence.

Au cas où parmi les attributs modifiables se trouve l'attribut employé pour RDN, abréviations anglo-saxonnes pour "Relative Distinguished Name", privilège donne le pouvoir de renommer l'entrée d'annuaire dans l'annuaire. cas où parmi les attributs modifiables se trouve l'attribut employé pour nommer l'entrée sur fIHM (abréviations pour Interface Homme Machine ), le privilège donne pouvoir de renommer l'entrée sur l'IHM.

Un domaine d'administration n'ayant pas de possesseur. L'administration d'une habilitation nécessite simplement de bénéficier d'une habilitation supérieure terme portée et de privilèges. Un administrateur ayant reçu une délégation d'administration, est habilité à déléguer ' nouveau (sous-déléguer) tout ou partie de l'habilitation dont il bénéficie.

Un sous-domaine d'administration est ainsi créé et peut être limité - soit niveau de la portée, à ce moment, la sous-délégation n' définie que une sous-arborescence de la portée initiale; - soit niveau des privilèges, dans ce cas, la sous-délégation définie sur ensemble de CESI ou un ensemble de panels plus restreint que dans l'habilitation reçue ; - soit suivant une combinaison des deux points précédents.

Une habilitation est modifiable par tout administrateur ayant domaine d'administration égale ou plus large en terme de portée et terme de privilèges. Le domaine peut être étendu au domaine de l'administrateur, restreint, encore la liste des bénéficiaires modifiée.

Une habilitation peut être détruite par tout administrateur ayant domaine d'administration égale ou plus large en terme de couverture et terme de privilèges.

Sous réserve des droits de création et destruction sur le CESi gère, l'entrée d'annuaire est déplacée librement à l'intérieur du domaine d'administration. En revanche, l'administrateur ne possédant pas de droits de création dehors de son domaine, l'entrée d'annuaire ne peut être exportée.

De plus, un administrateur ne possédant de droits de destruction dehors de son domaine, ne peut détruire une entrée extérieure à son domaine pour l'importer. Il est évidemment indispensable qu'un administrateur puisse détruire des ressources en dehors du domaine dont il est responsable.

Pour déplacer une entrée d'annuaire d'un domaine d'administration à un autre, par exemple lors de la mutation d'une personne, il est préférable de créer dans l'annuaire, une zone d'échange ou "sas" sur laquelle tous les administrateurs ont droit de création et destruction sur tous les types d'objet. Dés lors, pour déplacer une entrée, l'administrateur exportant déplace l'entrée vers la zone sas puis l'administrateur recevant importe l'entrée à l'endroit approprié et, si besoin, met à jour l'entrée.

Le procédé selon l'invention permet de naviguer dans la structure arborescente de l'annuaire. Les données de l'annuaire ou les habilitations sont gérées à partir du DN courant, abréviations anglo-saxonnes pour "Distinguished Name". La navigation dans l'annuaire permet de se déplacer dans l'arborescence en parcourant les DN. Ainsi pour le DN courant, l'ensemble des RDN directement sous-jacents est proposé. L'utilisateur peut sélectionner l'un des RDN sous- jacents pour déplacer le DN courant vers le bas de l'arbre; mais peut aussi selectionner l'un des RDN qui composent le DN courant pour remonter l'arbre.

visualisation de chacun des RDN est assurée par une icône la valeur attribut remarquable. Ceux-ci dépendent du CESI correspondant. Ainsi, dans le cas où l'entrée correspondante correspond à un CESI reconnu, l'icône l'attribut visualisés sont spécifiés par le CESI ; dans le cas contraire et par defaut, c'est l'icône par défaut et l'attribut composant le qui sont visualisés.

gestion des données de l'annuaire selon l'invention est decrite ci-après successivement pour la visualisation, la recherche et l'édition entrées de l'annuaire.

L'entrée d'annuaire correspondant au DN courant sélectionné par navigation visualisée. La visualisation dépend du type de l'entrée.

le type d'objet ne fait pas partie des CESI connus, l'entrée est présentée de façon brute par la liste des attributs qui la composent.

Dans le cas où l'entrée correspond à un CESI identifié, les panels applicatifs représentant l'objet ainsi que les attributs qui les composent sont visualisés. attributs spécifiés dans les panels ne sont toutefois pas nécessairement presents : c'est le schéma d'annuaire qui spécifie le caractère requis ou facultatif des attributs.

La recherche est contextuelle à partir du point courant de l'annuaire ou dans tout l'annuaire. Elle s'effectue en saisissant un type d'objet ou CESI recherché et pour ce CESI l'attribut sur lequel se fait la recherche un type d'opération : commence par [contient ! finit par une valeur.

mode avancé de recherche permet de saisir les informations ci-dessus quel soit l'objet recherché.

L'edition des entrées permet les opérations de création ; modification ; destruction ; renommage ; et déplacement.

Pour chacune de ces opérations, les droits de l'administrateur sont vérifiés par l'application vis-à-vis du domaine de délégation et des panels administrés pour le type d'objet.

création consiste à créer dans le noeud courant une entree d'annuaire correspondant à un CESI. L'entrée en cours de création est alors visualisée en edition. Elle comporte les valeurs préinitialisées en fonction CESI choisi. L'administrateur modifie si besoin, remplit les champs obligatoires et valide. L'entrée est alors insérée dans l'annuaire.

destruction d'une entrée implique la destruction de toutes entrées sous- jacentes.

Le renommage d'une entrée peut être compris de deux façons doivent être maintenues transparentes à l'utilisateur. En effet, il s'agira le plus souvent de renommer simplement l'attribut remarquable utilisé pour visualiser une entrée, exemple le "cn" (CommonName).

Pour ce faire, il suffira à l'utilisateur de modifier l'attribut dont il question, le " dans l'exemple. Toutefois, il peut se faire que cet attribut soit aussi utilisé pour construire le RDN. Dans ce cas, l'application devra aussi modifier le RDN. Pour déplacer une entrée de l'annuaire, l'administrateur devra posséder droits sur la destination.

Outre, les fonctions évoquées ci-dessus, l'éditeur propose les facilités d'édition usuelles telles que : Couper, Copier, Coller sur des entrées ou sur données attribut de l'entrée.

gestion des habilitations est décrite ci-après successivement pour visualisation, la recherche et l'édition des habilitations.

délégations s'appliquant sur le DN courant sélectionné par la navigation sont visualisées. Un onglet est proposé par habilitation.

recherche est contextuelle à partir du point courant de l'annuaire ou dans tout l'annuaire.

habilitations peuvent être recherchées suivant leur nom ; et les administrateurs qui en bénéficient. L'édition des habilitations permet les opérations de création ; modification ; destruction ; renommage ; Pour chacune de ces opérations, les droits de l'administrateur sont vérifiés l'application vis-à-vis du domaine de délégation et des panels administrés pour le type d'objet.

Lors de la création, un administrateur ayant reçu une délégation d'administration est habilité à déléguer à nouveau tout ou partie de l'habilitation dont il bénéficie. Le sous-domaine d'administration ainsi créé, peut être restreint soit au niveau de la portée : à ce moment, la sous-délégation n'est définie que sur une sous-arborescence de la couverture initiale<B>;</B> soit au niveau des privilèges : dans ce cas, la sous-délégation est définie sur un ensemble de CESI ou un ensemble de panels plus restreint que dans l'habilitation reçue; - soit une combinaison des deux points précédents.

Une habilitation est modifiable par tout administrateur ayant un domaine d'administration égale ou plus large en terme de portée et en terme de privilèges. Le domaine peut être étendu au domaine de l'administrateur, restreint, ou encore la liste des bénéficiaires modifiée.

L'architecture générale de l'outil mis en oeuvre par le procédé selon l'invention est illustrée à la figure 1.

Elle s'appuie sur les technologies de l'Internet.

Elle comporte une partie cliente, poste client, et une partie serveur, serveur annuaire.

La partie cliente héberge - un navigateur Web en charge du protocole d'accès au serveur; et - un composant logiciel destiné à gérer l'interface utilisateur, appelé également une "applet", et une base sécurité.

La partie serveur héberge - un serveur Web gérant le protocole de communication avec la partie cliente; - un composant logiciel qui assure la gestion des données de l'annuaire conformément aux habilitations et à la gestion des habilitations, appelé également une "servlet".; - un annuaire comprenant les données gérées; - une base des habilitations; et - un fichier de configuration contenant la description de la structuration données de l'annuaire.

La modélisation des entrées de l'annuaire pour les rendre aptes à etre administrés suivant une délégation d'administration s'appuie sur - la structure arborescente de l'annuaire; et - des ensembles d'attributs existants dans les entrées. Les composants sont écrits en langage Java.

Du côté client, l'implémentation supporte le JDK 1.1.6 de façon à éviter le déploiement d'un "plug-in", logiciel de visualisation de fichiers téléchargeable. Un JDK, abréviations anglo-saxonnes pour "Java Development Kit", est un outil de développement de logiciels de JavaSoft permettant d'écrire des applications en Java.

Du côté serveur, l'implémentation est décrite en JDK 1.2 et JDK 2, et supportée par exemple par le produit logiciel 4.5 de Weblogic (BEA) ou Netscape Enterprise Server 4 ou un serveur Web associé à un moteur de Servlet tel que JRun (Allaire).

Les échanges entre les deux composants, fapplet et la servlet, respectent le protocole HTTP, abréviations anglo-saxonnes pour "Hyper Text Transfer Protocol".

L'authentification est prise en charge par le serveur Web.

Dans le cas où celui-ci n a pas la capacité de réaliser complètement l'opération, c'est la servlet qui s'en charge.

Cette architecture apporte principaux avantages suivants - aucune extension schéma d'annuaire ni adjonction d'attributs spécifiques ; - aucun déploiement sur postes client : les paquetages nécessaires sont téléchargés tandis que seul le serveur nécessite une installation ; - indépendance de la plate-forme: la dépendance est localisée dans le serveur qui héberge servlet et c'est à celui-ci de s'affranchir de la dépendance plate-forme - indépendance vis-à-vis protocole de sécurité : c'est au navigateur et au serveur Web de gérer protocole mis en ceuvre, sécurisé ou non, c'est-à- dire HTTP ou HTTPS, à ces mêmes composants de gérer le contrôle d'accès par identifiant/ de passe ou par certificat.

L'applet dépend du navigateur et du JDK intégré tel que - Netscape Communicator 4.5 ; - Microsoft Internet Explorer 0 ; Ceux-ci sont nécessaires pour support - du protocole HTTP 1.1 ; - la base de sécurité dans le cas d'activation des mécanismes à base de certificat; et - l'environnement d'exécution de l'applet en Java sur base du JDK .1.6.

La servlet dépend du serveur Web et du moteur de servlet - Netscape Enterprise Server 3.6 et Allaire JRun <B>3.6;</B> - Netscape Enterprise Server 4 ; - BEA WebLogic 4.5 et JDK 1.2. Ceux-ci sont nécessaires pour le support - protocole HTTP 1.1 ; - la base de sécurité dans le cas de l'activation des mécanismes à base certificat ; - l'environnement d'exécution de servlet Java sur la base JSDK 2 et du 1.2 ; De plus, la servlet s'appuie sur une souche protocolaire d'acces à LDAP en environnement Java. II s'agit du JNDI fourni par Sun.

- JNDI permet d'accéder aux annuaires LDAP v3 tels que exemple - Netscape Directory Server 4 ; et - Isocor Global Directory Server.

On decrit ci-après en détail les différentes fonctionnalités composants de l'architecture générale de la figure 1.

Le serveur Web gère l'authentification en se connectant annuaires des utilisateurs et fournit l'information d'identification aux servlets. L'identification de l'utilisateur est véhiculée dans l'entête HTTP.

Le moteur de servlet gère les ressources servlet et notamment - désactive les sessions abandonnées par un mécanisme de temporisation connu sous la terminologie anglo-saxonne "timeout" ; et - assure une répartition de charge par l'exécution de la servlet dans des "threads" (sous-ensembles de processus).

Le fichier de configuration, config, comprend deux types d'information - des paramètres de type système tels que l'accès au serveur d'annuaire stockant les données gérées ; et - la description des modèles de données d'annuaire (ou CESI) permet de les rendre administrables en fonction de délégation d'administration.

servlet s'appuie sur le fichier de configuration précité.

Elle se connecte à l'entrée de l'annuaire avec un "bindDN" (fonction spécifique connexion de la servlet) et lui confère les droits suffisant pour l'administration des données par le procédé selon l'invention.

figure 2 illustre le diagramme de paquetages de la servlet - en ceuvre dans le procédé selon l'invention.

paquetage, on entend un ensemble de classes Java.

cette figure, la servlet est divisée en différents paquetages : paquetage "domaine", le paquetage "infra" et le paquetage "util" qui est transverse aux deux autres.

rôle de chacun de ces paquetages est décrit ci-après.

paquetage "domaine" contient les classes qui modélisent le domaine de l'application, c'est-à-dire les entrées de l'annuaire à administrer les classes necessaires pour assurer les fonctions d'administration et de delégation. Ce paquetage est divisé en deux couches selon le principe du pattern "knowledge - operational level" ; on utilisera les termes "niveau descriptif' et "niveau opérationnel" comme les traductions respectivement de "knowledge level" et "operational level".

couche "descriptif' correspond au niveau descriptif du domaine. Ce niveau contient la description de la structure du niveau opérationnel et les règles de gestion qui s'y appliquent.

couche "operationnel" correspond au niveau opérationnel. Ce niveau contient la représentation des entités du domaine en conformité avec la structure et les règles exprimées par le niveau descriptif.

paquetage "infra" correspond à la couche infrastructure d'accès qui contient objets nécessaires pour accéder au domaine. Cette couche contient un paquetage servletApplet" qui fournit à l'applet du poste client un accès au domaine l'intermédiaire de servlets.

Le paquetage "util" contient les classes de niveau utilitaire.

La figure illustre le diagramme de classes du paquetage domaine.

Ce diagramme permet d'illustrer comment s'organise. la relation entre le niveau descriptif le niveau opérationnel. On trouve en haut du diagramme le niveau descriptif en bas du diagramme le niveau opérationnel.

Les différentes classes représentées sur ce diagramme sont décrites ci-après. Par commodité on appellera directement chaque classe par son libelle commençant par une majuscule (par exemple Habilitation correspond à classe Habilitation).

CESI représente un Composant Elémentaire du Système d'Information. C'est description des éléments à administrer.

CESIR et CESINR correspondent respectivement à des CESI Reconnu et I Non Reconnu. Les CESI sont décrits dans le fichier de configuration, avec notamment leur correspondance avec les entrées de l'annuaire. La description des entrées pour lesquelles une correspondance avec un CESI est trouvee sera contenue dans un objet de type CESIR. La description des entrées pour lesquelles aucune correspondance n'est trouvée sera contenue dans un objet de type CESINR.

PanneauType contient la description des attributs a afficher dans un fenêtre (ou panneau) associée à un CESI.

AttributType contient les informations décrivant la manière d'afficher un attribut. ValeurParDefaut contient la valeur par défaut à donner à certains attributs. HabilitationType représente les types d'habilitations, c'est à dire les droits modification, de création ou de destruction que peut conférer une habilitation a un CESI.

EntreeCESI est l'interface qui représente une entrée de l'annuaire en tant que CESI. EntreeCESIReelle et EntreeCESISmart réalisent l'interface avec EntreeCESI. Ces classes sont utilisées pour implémenter un mécanisme gestion de l'espace mémoire occupé par les CESI.

Habilitation contient les instances d'habilitation. Une instance cette classe représente une habilitation d'un ensemble de CESI sur une partie l'annuaire et/ou sur PanneauType de cette partie d'annuaire. Les droits inhérents à cette habilitation sont donnés par HabilitationType associee à cette Habilitation.

Panneau représente une des fenêtre, ou panel, à afficher pour présenter un sous-ensemble des attributs d'une classe CESI. Le paramétrage l'affichage du panneau donné par l'objet de type PanneauType associé.

Attribut represente les attributs à afficher dans les panneaux. La façon d'afficher l'attribut est déterminée par l'objet de type AttributType associé.

On décrit ci-après les relations entre les niveaux descriptif et operationnel.

Le niveau descriptif impose des contraintes sur le niveau operationnel, ces contraintes sont listées ci-après.

Seules EntreeCESI ayant un type CESI lié à une HabilitationType peuvent avoir le rote d'administrateur d'une Habilitation.

Lors d'une délégation d'habilitation les droits délégués à EntreeCESI doivent etre définis dans l'HabilitationtType du CESI associé à l'EntreeCESI recevant l'habilitation.

Pour déléguer un droit de création il faut que l'HabilitationType du type de CESI de l'EntreeCESI créant la délégation autorise les créations. Cette contrainte différente de celle qui consiste à empêcher une EntreeCESI de déléguer habilitations supérieures à celle qu'elle possède, cette dernière étant une contrainte uniquement opérationnelle.

Les panels associés à une EntreeCESI doivent correspondre un ' un et dans l'ordre PanneauType associés au CESI lié à cette EntreeCESI.

Les attributs associés à un Panneau doivent correspondre à un aux AttributType associés au PanneauType lié à ce Panneau La valeur par défaut d'un Attribut doit être la valeur definie par la ValeurParDefaut liée à l'AttributType associé à cette Attribut. plus cette ValeurParDefaut doit être associé à un CESI de même type celui de l'EntreeCESI qui contient le panneau contenant l'attribut.

Les Habilitation de modification (celles qui sont associees à une HabilitationType qui autorise les modifications) s'appliquent sur des PanneauType. L'objet Habilitation est alors lié à une HabilitationType qui autorise les modifications, un ou plusieurs PanneauType une EntreeCESI qui donne la portee de l'Habilitation et une EntreeCESI représente l'administrateur l'habilitation.

Le niveau descriptif s'initialise avec les données du fichier configuration. Tous les objets niveau sont construits à la lecture de ce fichier.

La gestion habilitations et des EntreeCESI est effectuee au niveau opérationnel.

Les habilitations sont stockées dans la base des habilitations acquises à l'initialisation servlet après l'initialisation du niveau descriptif. Les objets correspondants sont construits une fois pour toute. Ces informations ne sont plus lues dans l'annuaire par la suite ce qui suppose qu'il n'y ait qu'une instance du serveur par annuaire (les données sont toujours lues en mémoire même si les mises à jour se font en parallèle dans l'annuaire). Néanmoins, la base est synchronisée sur la mise à jour des habilitations.

La figure 4 illustre le diagramme des différentes classes du paquetage infra pour l'infrastructure Servlet-Applet.

Ce paquetage contient principalement deux classes: Environnement et Session.

La classe Environnement correspond à un "Singleton", donc accessible directement par tous les objets de l'application. Cette classe maintient des liens vers - la liste de tous les CESI créés pendant la phase d'initialisation du niveau descriptif ; - la liste de tous les AttributType créés pendant la phase d'initialisation du niveau descriptif ; - la liste de tous les CESI sur lesquels une délégation peut être effectuée ; et - la référence du nceud racine de l'arbre des EntreeCESI.

La classe Session représente une session client, utilise l'objet HTTPSession de Java et garde un lien sur - l'EntreeCESI qui représente le client. Pour préserver l'intégrité des habilitations d'un client pendant toute sa session, c' à dire le préserver d'une restriction de délégation en cours de session, Session pointe sur une duplication de l'EntreeCESI représentant le client la session. Avec l'entrée sont dupliqués tous les objets représentant habilitations et les entrées représentant les portées. Tous les tests droits concernant le client se feront par rapport à cette EntreeCESI dupliquée alors que toutes les modifications d'habilitation se feront sur les EntreeCESI de référence.

- l'EntreeCESI courant du client.

La classe Session gère un identifiant unique de session accessible par la méthode getSessionldent().

II faut mettre en oeuvre un mécanisme de détection fin de session sur "timeout" d'inactivité pour pouvoir en fin session appeler removeSessionUse() sur la racine de l'arbre.

Le paquetage util contient les classes nécessaires pour entre autres, l'analyse chaînes XML de communication entre le serveur et clients, les accès à l'annuaire LDAP, etc.

lui-même organisé en paquetage.

navigateur Web client doit permettre l'exécution d'applet Java version 1.1.6. composants graphiques supplémentaires pour l'exécution de l'applet sont amenés par l'applet. II s'agit des paquetages JFCISwing.

"cookies", données créées par un serveur Web et qui sont enregistrées l'ordinateur d'un utilisateur, sont utilisés lors des mécanismes d'authentifications et doivent donc être supportés et activés dans le navigateur client. L'applet doit fournir un environnement graphique pour visualisation/modification des informations de l'annuaire fournies par la servlet. Elle gère l'interaction utilisateur (clavier<I>l</I> souris<I>l</I> interface graphique) retourne les informations à la servlet.

La figure 5 illustre l'arbre des tâches qui se décompose dans sa partie superieure, dans le sens de la figure, par un premier arbre représentatif principales tâches effectuées par le client, et les arbres représentatifs respectivement de la tâche "Se connecter", Administrer Annuaire", "Rechercher", "Sélectionner un CESI", "Consulter CESI" et "Gérer les Habilitations".

L'applet est téléchargée à partir du serveur. Les composants téléchargés sont - l'applet stricto sensu ; et - classes nécessaires au fonctionnement de l'applet et non fournies par le du navigateur (Swing).

On decrit ci-après les flux de données et la synchronisation des noeuds.

Pour gestion des CESI, la mise à jour de la modélisation des données de l'annuaire nécessite. la relance du serveur pour être prise en compte.

Pour gestion des données, les accès aux nceuds de l'arbre doivent être synchronisés entre les différents "threads" d'exécution des serviets. II faut pour cela mettre en place un mécanisme de synchronisation de type "lecteur- écrivains" favorisant les lecteurs.

Cette gestion de synchronisation doit être transparente pour les clients l'arbre et prise en compte dans la classe "EntreeCESISmart".

Seule les accès unitaires aux entrées de l'annuaire seront synchronises. L'application n'assure pas au clients des propriétés transactionnelles sur lectures l mises à jour de plusieurs noeuds. Notamment l'application n'assure pas la répétabilité des lectures (des mises à jour peuvent avoir eu lieu entre deux lectures) ni l'absence de lectures fantômes (une suppression peut avoir eu lieu entre deux lectures).

La cohérence des données au niveau unitaire sera assurée dans la mesure les mises à jour s'effectueront dans la même requête LDAP et que l'annuaire cible assurera l'atomicité, la cohérence, l'isolation et la durabilité des mises à jour.

Pour la gestion des habilitations, les accès aux habilitations sont synchronisés entre les différents "threads" d'exécution des servlets. Il faut pour cela mettre en place un mécanisme de synchronisation de type "lecteur-écrivains" favorisant les lecteurs.

L'application n'assure pas la répétabilité des lectures les habilitations lectures (des mises à jour peuvent avoir eu lieu entre deux lectures) ni l'absence de lecture fantômes (une suppression peut avoir lieu entre deux lectures). Afin de se protéger, les sessions prennent copie de leur habilitation à son initialisation. C'est cette copie qui fait pour la durée de la session. Une modification de l'habilitation par un tiers donc pas d'impact sur les sessions en cours sauf si elle est faite par le détenteur même de la session.

La communication entre applet et servlet suppose une phase d'authentification et l'établissement d'une session puis un protocole d'échange d'informations. Celui-ci est par exemple basé sur le langage XML, abréviations anglo- saxonnes pour "eXtendable Mark up Language".

exemple de scénario de communication entre applet servlet est illustré à figure 6.

phase 1, dans la partie supérieure de la figure se rapporte à l'authentification et l'ouverture de la session.

phase 2, dans la partie inférieure de la figure se rapporte à la communication proprement dite.

servlet et l'applet communiquent par échanges de messages XML sur le HTTP standard.

structure des données d'habilitation stockées dans la base des habilitations implémentées par l'annuaire, est décrite ci-après.

entrées ne nécessitent pas d'extension de schéma ou d'adjonction d'attribut. habilitation est enregistrée dans la base des habilitations sous la forme groupe et peut par exemple s'organiser suivant le tableau ci-dessous

<B>..............</B> <SEP> ::::.:.:::.....: <SEP> :
<tb> :::..::..:::.:
<tb> ...:::::::::.:...::..::::: <SEP> .:...::::::::::::::
<tb> .. <SEP> ...... <SEP> <B>. <SEP> .. <SEP> ...........</B> <SEP> ................... <SEP> `--:::::>::::...:::. <SEP> <B>0</B> <SEP> :....::.. <SEP> 0...::...` <SEP> :.:: <SEP> .:. <SEP> : <SEP> ........ <SEP> , <SEP> ...
<tb> <B>. <SEP> . <SEP> ....</B>...................................... <SEP> ................................. <SEP> ..t. <SEP> ......... <SEP> .... <SEP> ... <SEP> ..... <SEP> . <SEP> ... <SEP> .................:.. <SEP> ..:.::. <SEP> :. <SEP> :. <SEP> ::::::. <SEP> .::
<tb> . <SEP> . <SEP> :. <SEP> :. <SEP> :::::::.:.: <SEP> :..:.. <SEP> ..... <SEP> .......
<tb> .............................................................J.......................................?........................................................ <SEP> .............. <SEP> :.... <SEP> ................
<tb> .. <SEP> .:.:. <SEP> ....: <SEP> .:frfl0n. <SEP> ......... <SEP> ... <SEP> .... <SEP> .. <SEP> ................ <SEP> . <SEP> . <SEP> .. <SEP> .t....I. <SEP> .arat................... <SEP> ... <SEP> ..E.e <SEP> .fie <SEP> ... <SEP> .... <SEP> ,:.
<tb> :. <SEP> ........... <SEP> ................... <SEP> .. <SEP> .... <SEP> ........ <SEP> . <SEP> .... <SEP> ........... <SEP> ............. <SEP> ....... <SEP> <B>..........</B> <SEP> .............:. <SEP> :. <SEP> : <SEP> ... <SEP> :.. <SEP> .......... <SEP> .... <SEP> <B>..... <SEP> ......</B> <SEP> . <SEP> ......... <SEP> . <SEP> .. <SEP> ...........t....... <SEP> <B>P</B> <SEP> ........ <SEP> . <SEP> .
<tb> ..... <SEP> ....................................
<tb> cn <SEP> Nom <SEP> de <SEP> la <SEP> délégation <SEP> Requis <SEP> cis <SEP> Delegation
<tb> pour <SEP> la
<tb> gestion <SEP> du
<tb> personnel
<tb> uniquemember <SEP> Les <SEP> ayants <SEP> droit <SEP> Facultatif <SEP> cis <SEP> uid=dakers
<tb> =people,o=airi
<tb> us.com
<tb> description <SEP> Informations <SEP> sur <SEP> la <SEP> Facultatif <SEP> cis <SEP> et <SEP> format <SEP> ou=people,o=
<tb> applicatif
<tb> délégation <SEP> : <SEP> airius.com,
<tb> {CESI.Nom
<tb> Portée <SEP> panneau}:{CE <SEP> iluser.mail,
<tb> Droits <SEP> en <SEP> création <SEP> I <SEP> SI.Create}:{C <SEP> luser.detail
<tb> écriture <SEP> ! <SEP> destruction <SEP> de <SEP> ESI.Delete} <SEP> ailuser.create:
<tb> CESI <SEP> mailuser.delet
<tb> e

Claims (1)

<B><U>REVENDICATIONS</U></B> 1. Procédé d'administration déléguée des données d'un annuaire d'entreprise stocké dans des moyens de mémoire et accessible via un réseau de communication au moyen d'un poste client, ledit annuaire ayant une structure arborescente et manipulant des éléments d'information système d'information décrits respectivement dans des composants élementaires du systeme d'information appelé CESI et par lesquels une instance, ou entrée d'annuaire, est modélisée sous forme de formulaires, ou panels, correspondant à ensembles d'attributs de l'entrée, caractérisé en ce consiste à modeliser les entrées de l'annuaire sous forme de CESI manière à les rendre aptes à recevoir une délégation d'administration sur données, et à modeliser des habilitations sous forme de domaines d'administration pour définir les utilisateurs habilités, du réseau en question, leurs portées respectives ainsi que les données pouvant être administrées dans le domaine considéré. 2. Procédé selon la revendication 1, caractérisé en ce domaine d'administration est défini - une portée s'appuyant sur un noeud de l'annuaire à partir duquel les données appartenant à la sous-arborescence définie par ce noeud sont gerées ; - un groupe d'administrateurs délégués pouvant comprendre un sous- groupe d'administrateurs ; - des privilèges, c'est-à-dire des droits de création et destruction d'entrées répondant à un type déterminé et des droits de modification sur ensembles d'attributs de l'entrée. 3. Procédé selon la revendication 2, caractérisé en ce que - privilège de création sur un CESI déterminé, donne droit à un administrateur du domaine d'administration de créer dans la sous- arborescence une entrée d'annuaire typée par le CESI ; - le privilège de destruction sur un CESI déterminé, donne droit à un administrateur du domaine d'administration de détruire dans la sous- arborescence une entrée d'annuaire typée par le CESI ; - les privilèges de création et destruction sur un CESI détermine donnent les droits à un administrateur du domaine d'administration de déplacer dans la sous-arborescence une entrée d'annuaire typée par le CESI ; - le privilège de modification sur un panel déterminé d'un I déterminé, donne le droit à un administrateur du domaine d'administration de mettre à jour les attributs appartenant au dit panel d'une entree d'annuaire répondant au type défini par le dit CESI dans la sous-arborescence. 4. Procedé selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'un domaine d'administration n'ayant pas de possesseur attitré, l'administration d'un domaine nécessite d'une habilitation supérieure en terme de portee et de privilèges. 5. Procedé selon la revendication 4, caractérisé en ce qu'un administrateur ayant reçu une délégation d'administration, est habilité à sous-déleguer tout ou partie l'habilitation dont il bénéficie. 6. Procedé selon la revendication 5, caractérisé en ce que la sous-délégation consiste à créer un sous-domaine d'administration limité en portée ; la sous- délégation n'étant définie que sur une sous-arborescence de la portée initiale. 7. Procédé selon la revendication 5, caractérisé en ce que la sous-délégation consiste à créer un sous-domaine d'administration limité en privilèges; la sous- délégation n'étant définie que sur un ensemble de CESI ou un ensemble de panels plus restreint que dans l'habilitation initiale. 8. Procédé selon la revendication 5, caractérisé en ce que la sous-délégation consiste - à créer un sous-domaine d'administration limité en portée ; sous- delégation n'étant définie que sur une sous-arborescence de portée initiale ; et - à créer un sous-domaine d'administration limité en privilèges ; sous- delégation n'étant définie que sur un ensemble de CESI ou un ensemble de panels plus restreint que dans l'habilitation initiale. 9. Procédé selon la revendication 5, caractérisé en ce qu'une habilitation est modifiable par tout administrateur ayant un domaine d'administration egale ou plus large en terme de portée et en terme de privilèges ; le domaine pouvant être étendu au domaine de l'administrateur, restreint , ou encore la liste des béneficiaires modifiée. 10. Procédé selon la revendication 5, caractérisé en ce qu'une habilitation peut être détruite par tout administrateur ayant un domaine d'administration egale ou plus large en terme de couverture et en terme de privilèges. 11. Architecture informatique mettant en oeuvre le procédé selon l'une quelconque des revendications 1à 10, caractérisée en ce qu'elle comporte un poste client et un serveur reliés par un réseau de communication et incluant chacun des moyens de mémoire le poste client stockant dans ses moyens de mémoire - navigateur Web en charge du protocole d'accès au serveur; le serveur stockant dans ses moyens de mémoire: - serveur Web gérant le protocole de communication avec le poste client<B>;</B> - servlet qui assure la gestion des données de l'annuaire conformément habilitations, et la gestion des habilitations ; - moteur de servlet couplée à la servlet gérant les ressources de la servlet, - annuaire comprenant les données gérées ; - base des habilitations ; et un fichier de configuration décrivant la.structuration des données l'annuaire. Architecture selon la revendication 11, caractérisée en ce le poste client comporte en outre une applet destinée à gérer l'interface utilisateur.

1 Architecture selon l'une quelconque des revendications 1 et 12, caractérisée en ce qu'elle exploite les ressources de l'intranet.