Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Application Symfony de Gestion de droits sur différents réseaux

Par Fabrice PEUDENNIER Publié le 15/12/2019 à 10:59:46 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Le sujet

La dispersion de données

Un système de master – slave sur nos serveurs qui centraliseront les informations, ce système nous permettra de mettre à jour toutes nos instances. Chacun de nos serveurs aura aussi comme rôle de mettre à jour les autres, si ceux-ci ne sont pas joignable par le master.

La problématique

L’ensemble du contexte présenté dans les parties précédentes, m’ont permis de mettre en évidence la problématique suivante :

« Comment la création d’une plateforme d’administration, peut-elle simplifier la tâche des administrateurs et leur faire gagner du temps, en automatisant des actions récurrentes ? »

Le contexte

Alors que le nombre d’applications utilisées par les utilisateurs ne cesse de croitre de par les demandes, pour un besoin spécifique ou pour une amélioration d’une ancienne plateforme dont la prise en mains n’est pas facile; les personnes devant attribuer les droits et les autorisations aux nouveaux personnels ou aux personnes changeants de section ou de bureau, se retrouvent à devoir utiliser plusieurs plateformes pour définir les droits d’un utilisateur, et ce, à chaque fois qu’il est nécessaire de les modifier.

Il faut comprendre qu’une application peut se trouver sur différents réseaux, certaines applications utilisent, pour des raisons de sécurité, des mécanismes asynchrones de communication et se trouvent sur des réseaux de confidentialités différents. A fortiori sans pouvoir communiquer avec ses autres instances, cela veut dire qu’elle ne peut pas récupérer les modifications d’un utilisateur si celles-ci ne sont pas saisies sur son réseau. Donc chaque modification d’un utilisateur, il doit être répercuter sur les réseaux disposant de l’application en question. Nous pouvons donc nous rendre compte que certaines tâches sont redondantes et quelles pourraient être simplifiées et automatisées.

C’est donc dans cette optique qu’est venue l’idée de la création d’une plateforme permettant la centralisation de l’administration des droits et des permissions des utilisateurs sur toutes les applications.

C’est sur cette plateforme que toutes les permissions et que tous les droits des utilisateurs seront enregistrés, dans un premier temps, avant d’être envoyés sur les serveurs principaux de gestion de droits comme les active directory et autres annuaires utilisateurs.

Il a donc fallu faire en sorte que les applications qui passaient par une autre plateforme d’authentification passent désormais par celle-ci.

Mais ce n’est pas le seul problème rencontré. Toutes les applications ne peuvent communiquer avec tous les réseaux, cela veut dire que ma plateforme d’authentification doit se trouver dans différents réseaux pour pouvoir être accessible par toutes les applications.

Cela [XMLmind] aussi qu’une modification sur un utilisateur et sur un réseau doit être envoyée aux autres plateformes d’authentification pour les mettre à jour. Or certaines applications ne peuvent pas passer par ma plateforme d’authentification, mais uniquement par des « active directory » ou autres annuaires utilisateurs. Il faudra dans ce cas-là, les mettre à jour aussi.

Une grande partie des applications ayant été développées avec le Framework Symfony, il m’est donc beaucoup plus facile de développer une solution qui pourra être intégrée dans chaque application. Cette solution aura pour but de venir chercher les permissions de chaque utilisateur à un seul et même endroit. Toutes les modifications des permissions sur ce serveur centralisé seront envoyées aux autres serveurs de gestions des droits, réciproquement lorsque ces serveurs subissent des modifications de permissions d’utilisateur, ils les envoient à notre serveur centralisé.

Méthodologie

Méthodes utilisées au Ministère des Armées

Il existe aujourd’hui plusieurs dizaines de méthodes de gestion de projet et de développement dans le domaine de l’informatique. Mais deux catégories de méthodes sortent du lot, d’un côté les Rational Unified Process avec entre autres le modèle en cascade, cycle en V ou encore en spirale qui adoptent tous un modèle de cycle de vie linéaire. De l’autre côté, on a les méthodes agiles comprenant Scrum, DSDM[1] ou encore l’Extreme Programming avec comme principales caractéristiques d’impliquer au maximum le client et de reposer sur un cycle de développement itératif, incrémental et adaptatif.

Cycle en [XMLmind] :

Comme son nom l’indique, il s’agit ici de prévoir des phases séquentielles où il faut valider l’étape précédente pour passer à la suivante. Le chef de projet doit alors s’engager sur un planning précis de réalisation du projet en prévoyant des jalons de débuts et de fins de phases ainsi que les tâches à effectuer.

Avec cette méthode il faut la parfaire dès le départ car elle ne permet pas de retour en arrière. Une décision ou un problème rencontré dans une phase peut remettre en cause partiellement ou totalement les phases précédemment validées.

Dans un cycle « en cascade » les risques sont détectés tardivement puisqu’il faut attendre la fin du développement pour effectuer la phase de test. Plus le projet avance, plus l’impact des risques augmente : il sera toujours plus difficile et coûteux de revenir en arrière lorsqu’on découvre une anomalie tardivement.

Afin d’anticiper au mieux ces risques il est nécessaire de produire des documents très détaillés en amont (recueil des besoins, cahier des charges, zoning, wireframe etc…) qui seront validés par le client. Néanmoins, ces documents restent théoriques et conceptuels et, jusqu’à ce que le dispositif soit testé dans des conditions réelles, le client validera le contenu papier (conception, maquette, développement fonctionnalités etc…) mais sera toujours plus sensible à ce qu’il pourra tester lui-même lors de la recette.

Méthode Agile (SCRUM) :

Le [XMLmind] de vie de Scrum est rythmé par des itérations de quatre semaines que l’on appelle sprints.

Avant chaque sprint, on effectue une réunion de planification appelée le sprint planning meeting qui consiste à sélectionner les exigences prioritaires pour le client dans le backlog du produit qui seront développées, testées et livrées au client : le backlog du sprint (sous-ensemble du backlog du produit).

Des mêlées sont organisées quotidiennement durant le sprint afin de contrôler l’avancement et de s’assurer que les objectifs sont tenus. À la fin du sprint, une démonstration des derniers développements est faite au client ce qui donnera lieu à un bilan qualitatif sur le fonctionnement de l’équipe et la qualité du travail fourni.

L’avantage principale de cette méthode est la flexibilité. En effet, le fait qu’elle place le client, et donc indirectement le projet, au centre des démarches permet au client d’adapter ses besoins en cours de développement en évitant à l’équipe une perte de temps conséquente.

Cet avantage peut être très appréciable dans le cadre de mon sujet de stage car, même si le service avait déjà une idée concernant le projet final voulu, les contraintes lors du développement et le manque de transparence font que les besoins peuvent très vite évoluer. De plus cette méthode permettait, grâce à la mêlée quotidienne de tenir informé, les chefs de projets concernant mon travail.

Vous [XMLmind] en annexe 3 un tableau récapitulant les différences avec la méthode en cascade.

Conclusion : A la suite cette comparaison et car cette méthode nous semble adaptée au projet, l’équipe et moi-même avons choisi d’utiliser la méthode Scrum.

Celle-ci nous permettant d’avoir une souplesse sur le développement mais aussi autorisant à mes maitres de stages de pouvoir nous dire ce qui ne va pas sur nos développements sans que nous ayons tout à refaire.

Grâce à cette méthode, il m’a fallu apprendre à estimer de la durée d’une tache avant même de l’avoir commencé pour me permettre de ne pas dépasser la durée du Sprint.

Choix méthodologique et outils

Pour la [XMLmind] en place de ce projet, il faudra utiliser différentes technologies et connaissances.

Choix méthodologique

La première connaissance est celle qui nous permettra de gérer le projet comme il se doit et de pouvoir tenir nos chefs de projet au courant de nos avancements et des problèmes que nous rencontrons.

Et comme nous avons pu le voir précédemment dans la comparaison des deux méthodes de gestion de projet, la méthode Agile nous apporte un net avantage en termes de souplesse de développement. Elle nous permet donc une meilleure interaction avec nos chefs projet et nous permet d’apporter de nouvelles idées au projet sans que celui-ci soit entièrement à refaire. Cette méthode n’est autre que la méthode SCRUM.

Choix technologiques

Le choix des technologies a été fait non seulement pour avoir une continuité dans l’utilisations des normes et des technologies avec l’ensemble des projets mais aussi afin de garder une certaine cohérence. C’est donc pour cela qu’une partie des technologies utilisé est imposé.

La technologie permettant de créer la plateforme web, et l’ensemble des outils qui lui seront nécessaire, est le PHP mais avec un framework web, Symfony 2, que je ne connaissais pas. Car même si tous les frameworks ont une forte ressemblance de par l’utilisation du modèle MVC, MMVC ou même HMVC chacun d’eux à ses spécificités et utilise un mode de fonctionnement plus ou moins différent. Il m’a fallu apprendre l’utilisation des routes, la création de Bundles mais aussi son système d’authentification.

Pour la suite du projet, j’ai eu besoin d’utiliser le système d’authentification des « Active Directory Kerberos », car chaque utilisateur se connectant à sa session passe par ce système. Cela a nécessité l’apprentissage du fonctionnement de ce système et de la manière dont il est couplé avec mon serveur pour pouvoir avoir une interaction avec lui et permettre l’authentification des utilisateurs sur les applications.

L’utilisation de cette technologie, n’est pas un choix mais une reproduction de ce qui est utilisé dans ce ministère. C’est pour avoir un développement le plus proche possible de l’environnement de production que nous avons choisi d’implémenté ce système.

Pour permettre la récupération des droits sur les Active Directory et sur les annuaires utilisateur Linux, nous n’avons pas utilisé le Python qui aurais pu être un choix judicieux car ce langage peut être exécuter sur des machines Linux et même Windows.

Mais cela nous aurait fait implémenter un nouveau langage au projet et pour garder une certaine cohérence, nous sommes donc restés sur le PHP. Mais cette fois-ci en ligne de commande, car grâce à ce langage, mes scripts sont exécutés aussi bien sur des machines Windows que des machines Linux.

Pour permettre la synchronisation des serveurs et l’envoie des données modifier, un système de WebHook a été mis en place. D’autre système de synchronisation des données auraient pu être utilisé. Mais ceux ne permettre en rien l’envoie des données juste après leur modification, ce qui nous aurait fait perdre du temps sur les mises à jour des bases de données.

Symfony [XMLmind] permet facilement d’appeler une fonction avant ou après la modification ou création d’un objet (l’objet est l’ensemble des éléments qui seront sauvegardé en base de données plus quelques fonctions utiles pour son fonctionnement). La mise en place de ce système est un choix judicieux car celui-ci nous permet de ne pas perdre de temps sur la synchronisation des serveurs et de ce fait de limité au maximum les corruptions de données.

Grâce à l’ensemble des compétences que j’ai acquises pendant mes années d’études : administration d’Active Directory, langage de programmation web, méthode de conduite de projet, j’ai pu mettre en place un cahier des charges pour décrire concrètement le problème et expliquer le choix de mes solutions aux chefs de projets et à mon tuteur.

Analyse de la solution

Déroulement du projet

Pour commencer la réalisation du projet, j’ai dû recenser les besoins pour la rédaction du cahier des charges. Celui-ci servant de base pour la compréhension du problème et pour la solution utilisée.

Suite à la réalisation de ce cahier des charges, j’ai divisé l’ensemble de mes développements en tâches pour les répartir dans mes taches de développement. Ces tâches, après une étude de la complexité de leur réalisation et l’écriture de user-story[2], se sont vues assigner un coefficient de temps en journées. Grâce à ce coefficient, j’ai pu prioriser l’ensemble des taches, ce qui m’a permis de créer un diagramme de Gantt[3] (voir annexe 4) pour avoir une représentation graphique de la durée de développement des différents bundles et scripts.

Une fois cette analyse des taches terminées j’ai alors pu commencer à sélectionner certaines tâches pour effectuer mon premier sprint.

Cahier des charges

Spécification générale

Une application centrale de gestions des utilisateurs, que nous nommerons « Le Portail » est développée par l’autre stagiaire, elle est en cours de développement. L'objectif de ce projet est de créer plusieurs composants pour valoriser la base de données de l’application. Le modèle logique de données a été créé par le stagiaire travaillant avec moi, il a aussi créé deux bundles composés de classes basées sur le système ORM, ce qui me permet de les réutiliser dans d’autres bundles pour effectuer des requêtes SQL.

Lorsqu'un utilisateur veut utiliser une application web, il faut vérifier si celui-ci est bien authentifié mais il faut aussi savoir si celui-ci possède les droits d'accès à cette application. L'utilisateur peut aussi posséder d’autres droits, allant du simple ajout à la modification de données ou même la suppression de celle-ci.

Pour le développement de certaines fonctionnalités, les applications peuvent avoir besoin d'informations sur les utilisateurs. Par exemple, lors de la demande d'accès à une application, l'utilisateur passe par une chaine de validation, il faut savoir à qui cet utilisateur doit faire sa demande d'accès pour avoir les permissions sur une application ou s’il les possède déjà.

Un utilisateur fait partie d’un organigramme, celui-ci étant une représentation de la hiérarchie pour un service. De plus un échelon de l’organigramme tout comme un utilisateur peut avoir des droits qui lui sont assignés comme à un utilisateur.

Par ailleurs, plusieurs serveurs de gestion des droits devront exister en parallèle sur plusieurs réseaux. Lors de la modification de données sur un utilisateur ou ses droits, il serait souhaitable que ces modifications soient répercutées automatiquement sur les serveurs de gestions de droits et d'utilisateurs des autres réseaux. Il peut aussi être intéressant d'avoir des outils pour s'assurer que les bases de données de toutes les instances du Portail soient synchronisées.

A qui est-il destiné

Le projet est surtout destiné aux administrateurs qui doivent maintenir les annuaires des droits des utilisateurs et aux développeurs qui ont besoin d'une solution de gestion de droit sûre et efficace. En effet, centraliser la gestion des droits dans un seul portail permettra de mutualiser le coût de développement et de maintenance de cette fonctionnalité.

Il permettra aux utilisateurs de se connecter à leurs applications en toute transparence.

Actuellement

Actuellement les droits d’un utilisateur sur une application peuvent varier en fonction du réseau. Il est possible aussi que les droits changent d’une application à l’autre sur le même réseau.

Les administrateurs doivent se connecter à différentes plateformes ou applications pour modifier ou ajouter des permissions à un utilisateur. Ceux-ci doivent même changer de réseaux pour affecter des permissions.

Objectif

Il faudra créer un outil Symfony qui sera intégré dans les applications et qui permettra l'identification de l'utilisateur. Cette identification permettra de ce fait de savoir si l'utilisateur a des droits sur une application ou non.

Un [XMLmind] outil Symfony récupérant toutes les informations de l’utilisateur et sa hiérarchie sera aussi nécessaire, car lorsqu'un utilisateur demande l'autorisation d'utiliser une application, il faut passer par une chaine de validation qui est composée de personnes étant au-dessus de lui hiérarchiquement. Il faut pouvoir, lorsqu’un utilisateur est modifié, renvoyer les nouvelles informations sur les autres réseaux afin de les mettre à jour.

Lors de la création, modification ou suppression d'un utilisateur sur le Portail, ces modifications devront être répercutées dans la base de données du Portail et, si besoin, mettre à jour les serveurs comme l'Active Directory et les droits d'accès à certains réseaux.

Solutions techniques

Une solution Maître-Esclave

Le Portail sera déployé en mode Maître-Esclave. Cela devrait faciliter la synchronisation des données et son utilisation. La mise en place de ce procédé est assez simple à comprendre, nous installerons un serveur sur un réseau où il peut avoir accès à l’ensemble des autres réseaux ou à un maximum de réseaux, que nous nommerons « réseau-maitre », et pourra communiquer avec les autres réseaux. La topologie de ce réseau est donc en étoile, même si certains réseaux ne seront accessibles que par l’intermédiaire d’un autre réseau. C’est la plus courante actuellement, elle est aussi très souple en matière de gestion et de dépannage réseau.

En revanche l’équipement central qui relie tous les nœuds constitue un point unique de défaillance. Mais un utilisateur ne pourra avoir accès au Portail du réseau maitre que s’il se trouve sur celui-ci. Puis des instances esclaves du Portail seront installées sur tous les autres réseaux.

Cela permettra aux administrateurs d’avoir accès au Portail depuis leur réseau. À chaque modification qu’un administrateur effectuera sur une instance, ce portail écrira un fichier sur son réseau avec la liste des modifications qui lui ont été apportées.

Le [XMLmind] maitre est en écoute sur tous les réseaux pour voir si une de ses instances n’a pas subi de modification et, si c’est le cas, il viendra alors lire les modifications effectuées pour se mettre à jour.

Une fois ces modifications intégrées, il les fera remonter au serveur maître qui, lui, les enverra sur les autres réseaux pour qu’eux aussi puissent se mettre à jour.

Pour que cette solution soit viable j’ai choisi d’utiliser un système de WebHook, celui-ci a été validé par mon maitre de stage et les chefs de projet. Ce système sera détaillé dans une des parties suivantes.

Symfony

Symfony est un Framework PHP pour créer des sites web et des applications web. Symfony n’est en rien nécessaire pour la création de site web ou d’application, ce n’est qu’un outil permettant de développer mieux et plus vite. Il permet la création d’applications en respectant les contraintes d’entreprises et cela permet une meilleure maintenance et facilite les mises à jour.

Symfony permet au développeur de gagner du temps en réutilisant des modules génériques. Pour le développement de ses outils, il met en place un système de Bundle. Ces bundles sont en fait des sortes de plugins qu’il est possible d’intégrer dans d’autres projets utilisant Symfony. Chaque Bundle est indépendant mais il est possible de créer des dépendances pour pouvoir utiliser les fonctions ou classes d’un Bundle dans un autre Bundle.

L’utilisation de ce [XMLmind] permet de structurer de développement des projets. Il nous facilite le cloisonnement du code, ce qui ajoute une certaine modularité au projet, mais surtout la possibilité de désactivé certaine fonctionnalité sans pour autant arrêter de faire fonctionner l’application principale.

C’est aussi dans un but de cohérence que cette technologie a été choisi, car comme dit plus haut, mon service travaillant déjà sur certaines de leurs applications avec technologie, il parut normal d’utiliser la même. Car cela permet à l’équipe, si elle en a besoin de modifier le projet sans avoir s’adapter à la technologie utilisée et perdre du temps à sa compréhension.

Structure de la base de données

Pour mettre en place la base de données nous avons utilisé Symfony. Car celui-ci intégrant un ORM, c’est une technique de programmation faisant le lien entre la base de données et les objets, elle permet de transformer une table en un objet facilement manipulable via ses attributs, cela nous a grandement facilité la création de la base donnée.

Comme dit précédemment, la base de données et les classes (objets) ont été créé par un autre stagiaire. Mais ayant des besoins de fonctionnement différents des siens, nous avons dû réfléchir pour faire évoluer cette base de données et répondre au mieux à nos besoins.

Nous avons donc décidé d’utiliser l’héritage de Symfony dans la base données. Et nous avons créé une classe Acteur qui se divisera en quatre types :

  • L’utilisateur, une personne réelle

  • L’application qui se comporte comme un utilisateur

  • L’organigramme [XMLmind] peut posséder des droits et permet d’attribuer des droits à tout un échelon (appelé Org Chart pour Organizational Chart)

  • Générique, un acteur qui permettra l’exécution de certains scripts

(Annexe 5)

Il existe une table par type d’acteur, ainsi que la table acteur. Ces quatre tables héritent alors de la table acteur ce qui leur permet de posséder des champs en commun, ainsi que le lien entre acteurs et droits.

Il nous a été demandé de mettre en place un système de droits, celui-ci ayant comme contrainte de pouvoir attribuer les droits sur une période donnée. Nous avons donc mis en place un système de date de début et date de fin dans une table de liaison entre un acteur et un droit. On peut donc attribuer un droit à un acteur pour une durée donnée. Si on attribue ce droit sans préciser de date de fin, alors celui-ci est détenu par l’acteur jusqu’à modification par un administrateur. De plus les droits ne sont pas supprimés. Lorsque l’on veut retirer un droit à une personne, on modifie la date de fin comme étant le jour-même. On sait donc quels droits un acteur a possédé par le passé et pendant quelle période. Pour permettre une gestion des autorisations entre les acteurs et les droits et afin de mettre en place un système de hiérarchie, un droit peut posséder des liens vers d’autres droits qui seront les droits fils, de même un droit peut posséder des liens vers d’autres droits qui seront les droits pères. Par exemple le droit super-administrateur possède le droit administrateur comme fils, lui-même possède un ensemble de droits et ainsi de suite.

Webservice

Un Webservice est un programme informatique permettant la communication et l’échange de données entre une application et un système. Il s’agit donc d’un ensemble de fonctionnalités exposées sur internet ou intranet, par et pour des applications ou machines, sans intervention humaine, de manière synchrone ou asynchrone.

Le [XMLmind] de service mis en place est de type REST (REpresentational State Transfer), il expose entièrement ces fonctionnalités comme un ensemble de ressources (URI[4]) identifiables et accessibles par la syntaxe et la sémantique du protocole HTTP.

Notre WebService contrairement aux autres ne comporte que des méthodes GET. Une méthode GET, est URL interroger pas une application ou une machine mais que ne faite que retourner des informations. En aucun cas, les données qui sont base de données ne pourront être altérées et aucun ne pourra aussi être ajoutées.

Cette partie est intégrée dans le Portail de gestion de droits. Elle permet, aux applications qui ont eu l’autorisation de l’interroger, de retourner les informations demandées par l’application ou la machine.

Par exemple si nous allons sur :

http://mondomaine.com/api/getuserrights.json/doe?token=fsd53f4df354sdf83sdf4s13faqsqf

Mon WebService vous retournera la liste des droits de l’utilisateur « doe ».

Le dernier paramètre qui est une suite de lettres et de chiffres (« fsd53f4df354sdf83sdf4s13faqsqf ») est enfaite une clef qui permet au WebService de savoir qu’elle application viens l’interroger et de ce faite de savoir si elle a le droit de le faire ou non.

Il permet aussi de retourner différent type d’information comme ; la liste des droits d’un utilisateur, ses informations, les droits d’une application et d’autres informations encore.

Ce bundle est divisé en différentes parties :

  • Les contrôleurs qui nous permettent de pouvoir définir les routes à interroger pour récupérer les informations que nous voulons.

  • Les manageurs qui sont découpés en quatre, un pour les applications, un pour les organigrammes, un pour les droits et un pour les utilisateurs. Ce sont des classes composées de plusieurs fonctions qui, elles, feront des requêtes SQL pour aller interroger la base de données, récupérer les informations demandées s’il y en a et les retourner sous la forme d’un tableau en JSON.

  • La documentation n’est pas comme toutes les autres documentations car celle-ci est aussi disponible depuis une URL, cela la rend beaucoup plus pratique et accessible. De plus, il est possible sur cette documentation de voir toutes les URLs des requêtes possibles, mais aussi leurs paramètres et le type attendu. Elle permet aussi un mode sandbox pour pouvoir effectuer des requêtes directement depuis la page de la documentation.

Ce [XMLmind] sera donc installé sur chaque serveur de gestion de droits qui sera lui-même déployé dans différents réseaux.

Lors de la création de bundles, certaines parties ont été plus compliquées que d’autre à faire. Comme par exemple la récupération des droits d’un utilisateur, car chaque droit peut avoir un parent et un enfant, ce qui signifie qu’il a fallu faire une récursivité pour la récupération. De plus chaque utilisateur doit récupérer aussi la liste des droits de son organigramme.

Authentification

Comme évoqué au paravent dans le rapport, les utilisateurs qui se connecteront sur certaines applications web devront être automatiquement connectés à leur compte au chargement du site.

Cela a été possible par l’utilisation d’une technologie fournie par le MIT, l’authentification Kerberos. Nous utilisons des serveurs ActiveDirectory qui ont implémenté le protocole Kerberos pour l’authentification de leurs utilisateurs. Au moment où l’utilisateur se connecte sur la session de son ordinateur, un token est créé sur le poste et sur le serveur pour vérifier que l’utilisateur est bien authentifié. Ce système demande une légère configuration au niveau du serveur web, car celui-ci doit récupérer le token de l’utilisateur pour pouvoir vérifier son authentification sur les applications.

C’est à ce moment-là que le bundle d’authentification vient faire son travail. Il s’appuie sur le système d’authentification de Symfony et le surcharge pour lui permettre d’effectuer une requête sur le webservice de l’application de gestion de droits. Pour pouvoir communiquer avec le webservice, ce bundle utilise la librairie PHP cURL pour lui permettre de faire des requêtes en GET, POST ou autre type avec des paramètres eux aussi en GET ou en POST.

Pour simplifier la relecture du code et le rendre plus lisible, j’ai décidé de créer une classe « Client » qui est composée de méthodes et d’attributs permettant de simplifier l’utilisation de cURL dans ce bundle. C’est à la suite de cette modification et après discussion avec mes chefs de projets que nous nous sommes aperçus que cela pourrait être utile de le transformer en un bundle externe réutilisable dans d’autre projet. Je détaillerai donc ce bundle (Bundle WebserviceClient) dans l’une des parties suivantes.

Bundle d’information

Ce bundle a pour vocation d’être utilisé dans d’autres applications. Il permettra de récupérer les informations d’un utilisateur sans difficulté. Il permettra à une application de récupérer l’organigramme de l’utilisateur, mais aussi sa hiérarchie et d’autres informations propres à l’utilisateur qui pourrait être utiles dans l’interaction avec l’application. Il s’appuie lui aussi sur le webservice pour récupérer l’ensemble des informations dont il a besoin.

Webhook

Un Webhook est un mécanisme qui permet de faire appel à des fonctions de retour permettant d’interagir avec un site web ou une application. Le principe d’un webhook est de notifier une application qu’un événement a eu lieu. Comme par exemple l’écriture d’un fichier, sa suppression etc.

Dans [XMLmind] cas, ce mécanisme a pour but de permettre la communication entre une instance du Portail et son serveur maitre.

Nous avons choisi ce mécanisme, car il nous permet d’avoir un temps de latence entre la modification d’information et exécution du processus d’envoi de la modification.

Ce mécanisme est divisé en deux parties, l’une qui provient de Symfony et l’autre qui est un service tournant en tache de fond sur Linux.

La première partie est enfaite une fonction qui peut être appeler avant ou après la modification ou la création d’un objet (utilisateur, application, organigramme, droits etc.). De ce fait nous pouvons lancer l’exécution d’un script de synchronisation après que l’action se soit déroulée correctement.

La deuxième partie du mécanisme est l’utilisation d’un script python qui attend l’écriture d’un fichier dans un dossier bien précis, configuré au préalable. Dans ce fichier, se trouve l’action à effectuer et toutes les options, comme par exemple les tables modifiées en base données avec les valeurs à ajouter. Une fois la tâche terminée, le script répond par le même procédé, cela nous permet de voir s’il y a eu des erreurs ou non.

Ce Webhook est utilisé à deux endroits très stratégiques, pour la communication entre le serveur maitre et les serveurs esclaves, mais aussi entre une instance du Portail et les différents EndPoints[5] qui sont les serveurs Active Directory, serveurs samba et autres.

Pour comprendre le fonctionnement du Webhook, vous pouvez vous référer à l’annexe 6.

Script de synchronisation

Ces scripts de synchronisation, sont développés en PHP, car Symfony nous permet de lancer en ligne de commande tout en gardant un accès au contexte de développement. Garder un accès au contexte de développement est assez primordial car cela nous donne accès aux classes des objets de la base données et de ce fait nous facilite la communication avec la base de données.

Ces scripts ont aussi une autre utilité et non des moindres qui est le filtrage des données. Car étant donné que je travaille dans un environnement ou les réseaux n’ont pas tous le même niveau de confidentialité, il nous est important que les données passant d’un réseau à l’autre soit filtré. Comme par exemple sur un réseau nous retrouverons le nom complet d’un utilisateur alors que sur un autre plus confidentiel nous ne retrouverons que la première lettre de son nom.

Bundle WebserviceClient

Symfony n’ayant [XMLmind] de méthodes de base ou de classes pour effectuer des requêtes HTTP sur une URL externe, j’ai pris la décision de créer une classe me permettant de la faire. Après étude de cette classe avec mes chefs de projet, nous avons décidé de la transformer en bundle pour nous permettre de l’utiliser dans d’autres projets.

Le but de ce bundle est de nous permettre d’effectuer des requêtes sur des URLs externes, pour nous permettre d’effectuer cela, j’ai pris la décision d’utiliser le module php cURL. Celui-ci étant utilisé dans beaucoup de projet, c’est pour cela aussi que j’ai décidé d’en faire une classe.

Cette classe nous permet de définir, la méthode utilisée, l’URL à interroger, les paramètres GET, ceux en POST et l’ajout de headers.

Je n’ai ajouté que des fonctionnalités basiques mais qui sont utilisées dans beaucoup de cas et qui répondent aux besoins du projet. Il m’aurait été possible de rajouter des méthodes et options à ce bundle, mais cela aurait empiété sur mon temps de développement et sur mon sprint.

Originalité du projet

Alors que le nombre d’utilisateurs ne cesse de croitre et que le nombre d’applications utilisées par ces utilisateurs est en perpétuelle augmentation, les administrateurs chargés de la gestion des permissions des utilisateurs sur les applications et des droits de ces mêmes applications, ont donc de plus en plus de travail.

De [XMLmind] certaines actions doivent être effectuées plusieurs fois mais sur différent réseaux, cela signifie que l’administrateur devra se déplacer pour effectuer la même action que dans le réseau précédant et pour la même application ou le même utilisateur.

Avant la réalisation de ce projet, aucune application ou script ou même plateforme ne permettait à des utilisateurs de gérer ne serait-ce que les droits d’un autre utilisateur sur une application ou même les droits de cette même application.

C’est suite à une analyse sur la redondance des tâches et la perte de temps qu’il y avait pour assigner les droits d’une personne ou d’application, mais aussi dans un souci d’optimisation et de simplification des tâches, que l’idée de créer une plateforme centrale permettant de gérer les droits d’un utilisateur et d’une application a fait son apparition.

Technologiques

Alors que certaines des applications développées n’utilisent pas le Framework Symfony, il a été choisi de l’utiliser ici, dans un but de facilité la maintenance et pour une simplification du portage de certaines parties de code vers d’autres applications. Mais aussi et surtout pour garder une certaine continuité dans l’utilisation des normes et des technologies avec les membres du service.

L’utilisation de ce Framework, nous permet donc de faire des développements beaucoup plus modulaires, ce qui permet un gain de temps énorme, car la structure de développement reste identique peu importe le sujet et certains modules peuvent être réutilisé. Une application qui a besoin d’un module d’authentification sur un Active Directory, ne se verra plus développer un module spécifique mais un module qui pourrait être porté sur d’autres applications si celles-ci en ont besoin. Cela signifie aussi que le développement de ces modules doit être assez générique pour permettre son utilisation sur différents projet.

Un développement modulaire implique aussi des contraintes, car les modules peuvent être utilisés par d’autres applications que celle initialement prévue. Le code doit donc être clair et commenté, mais surtout une documentation doit être rédigée pour permettre aux personnes voulant les utiliser de le comprendre et de les mettre en place rapidement, sans perdre de temps. C’est pour cela qu’il m’a été demandé pour chaque module développé de faire un fichier résumant le but du module et ses fonctions mais aussi d’écrire quelques exemples d’utilisation pour permettre une meilleure compréhension.

Managériale

Le projet étant un développement prévu pour rester en interne, nous aurions pu penser qu’utiliser un cycle en cascade, aurait pu largement suffire. Car les besoins sont bien connus et le projet est déjà posé.

Mais dans ce projet, nous avons dû faire face à quelques soucis qui nous ont orientés vers d’autre développement, nous avons eu des idées qui n’avaient pas été envisagées auparavant et qui ont apporté une facilité dans la solution. Pour permettre toutes ces modifications et leur incorporation dans le développement, une méthode Agile telle que la méthode Scrum était parfaite.

Le développement est découpé en sprints de 2 semaines, ces sprints comportent entre quatre et huit tâches. Pour choisir quelles tâches seraient à mettre dans le sprint, des réunions avaient lieu à la fin de chaque sprint précédent. Certaines tâches étaient jugés plus compliqué et donc plus longue, ce qui parfois réduisais le nombre de tâches par sprint à seulement trois ou quatre.

De [XMLmind] réunions de dix minutes avaient lieu tous les matins, pour discuter des problèmes rencontrés la veille et pour faire un point sur la réalisation des tâches. Ces réunions permettaient aux chefs de projet de m’aider mais aussi de me guider si je butais lourdement sur un problème. Elles leur ont permis de voir aussi comment je travaillais et comment j’abordais les tâches à réaliser mais surtout les problèmes. Ce qui leurs permettaient de me dire si je partais dans une mauvais direction ou si mon idée était à approfondir.

Les réunions qui avaient lieu en fin de Sprint, me permettais de voir si mon analyse sur la durée de développement d’une tâche était correct ou bien au contraire totalement erronée. Ces réunions permettaient à mes chefs de projet et moi-même de définir les prochains développements que je ferai pendant le prochain sprint. Elles avaient aussi pour but de nous permettre de définir la priorité des tâches mais aussi de pouvoir les adapter ou modifier si les besoins avaient changé ou si quelqu’un avait eu une nouvelle idée.

Stratégique

Nous allons commencer par définir ce qu’est une stratégie mais surtout son rôle, pour ensuite expliquer les choix que nous avons fait.

Qu’est-ce que la stratégie

Malgré le fait que le client ici, soit l’administration elle-même, cela ne retire rien au fait que la stratégie choisie devra, respecter les besoins métier, être innovante et savoir reconnaitre ses points faibles.

Pour une entreprise développant des applications pour elle-même ces 3 points sont assez cruciaux car chacun d’eux va avoir un impact sur le déroulement du projet et sur son développement.

Respecter les besoins métier, il est très important de respecter ce pourquoi l’application a été faite et non développer des fonctionnalités qui ne seront que très peu utilisées. Ces fonctionnalités pourraient être gourmandes en temps de développement. Un client ne paye pas pour avoir une application innovante en premier lieu, surtout si celle-ci ne répond pas à ses besoins principaux.

L’innovation ne passe pas forcément par la création de nouvelles fonctionnalités, comme par exemple permettre de changer la couleur du fond, d’ajouter une image ou même de mettre la couleur de texte que je souhaite. L’innovation passe aussi par la façon dont sont effectuées les actions, c’est-à-dire comment a été développée cette fonctionnalité ou comment a été créée la structure de données. Tout un ensemble de choses que le client ne verra peut-être pas peut être considéré comme innovation. Car ces solutions permettent une maintenance plus facile et donc plus rapide, elles permettent aussi un gain de temps sur l’affichage des pages ou même un gain de temps sur l’enregistrement des informations en base de données.

Reconnaitre ses points faibles permet de mener des actions correctives. Le déni est la marque de fabrique des échecs. Il est important de savoir dans quel domaine nous avons des lacunes car cela permet aux autres développeurs d’apporter plus d’attention et des correctifs sur les points spécifiques.

Les choix effectués

Il a été choisi de développer le projet sous forme de bundle, pour des raisons d’isolation du code mais aussi dans un souci de respecter et de continuité des normes choisi par l’équipe.

Le fait de développer sous forme de bundle, me permet de faire des revues de codes avec mes chefs de projets (vérifier si la façon dont j’ai développé certaine fonctionnalité est bien fait et s’ils auraient fait pareil) et donc cela m’évite d’avoir à leur donner le projet au complet qui contient plus de trois cent fichiers et ne leur donner que l’essentiel le bundle soit environ une dizaine de fichiers.

Il est important aussi de noter que le fait de créer des bundles permet aussi une gestion des fonctionnalités sur un projet beaucoup plus facilement. Par exemple mon projet contient différentes parties, comme une interface de gestion, un webservice, un système d’authentification et d’autre fonctionnalité encore. Si lors d’un déploiement de projet sur un réseau, les utilisateurs n’ont pas besoin du WebService, il nous suffira juste de ne pas mettre le code de celui-ci et cela n’impactera en rien le fonctionnement des autres fonctionnalités.

Grace à ce développement scindé, j’ai pris l’initiative par la suite de développer aussi certaines fonctionnalités en bundles, avec l’accord de mes chefs de projets. Celles-ci se sont vue déjà réutilisé dans certain projet. C’est à ce moment-là aussi que l’on peut se rendre compte de l’importance des bundles mais aussi de la documentation que nous apportons au bundle. Car c’est cette documentation qui permet une prise en main et une utilisation rapide des bundles par les autres personnes du service.

Analyse du résultat

La gestion de projet

La prise en main des méthodes de gestion de projet c’est fait assez rapidement et sans problème. Ayant déjà appliqué des méthodes agiles et surtout la méthode Scrum dans mes entreprises précédentes, il m’a été plus facile de les appliquer. J’ai pu avoir estimation des taches assez précise, ce qui a permis de pas avoir de taches se reportant d’un sprint à l’autre. Le fait d’avoir une estimation précise des taches m’a permis de plus me concentrer sur le développement du projet et non sur l’analyse des taches.

Le projet

Pour ce qui est de l’application de gestion de droits, nous avons un site fonctionnel avec toutes les fonctionnalités demandées.

Cette plateforme permet donc la gestion d’utilisateurs et de leurs droits, il est donc beaucoup plus facile pour les administrateurs, de donner les permissions pour une application ou de les révoquer.

Il est possible de gérer les applications mais aussi leurs permissions, cela permet de gérer leur maintenance mais aussi leur accès à d’autres applications.

Pour l’administration des permissions, il a été ajouté la possibilité de gérer les organigrammes, ajouter ou supprimer un utilisateur et leurs assigner des permissions.

L’intégration de ma partie, qui comprend le Webservice et tous les mécanismes de mise à jour entre les serveurs, a été faite sans réel soucis.

Le Webservice intégré à cette application est déjà interrogé par certaines applications, dont une développée par un autre stagiaire.

Cette application a donc été déployée sur différents réseaux. Elle est utilisée par différents utilisateurs, certains ne remarqueront jamais qu’ils utilisent notre plateforme, ils ne font que se connecter à un logiciel tierce et ne voient en rien les changements effectués car ils n’utilisent que la partie authentification de mon site et de mon bundle.

Alors que certains utilisateurs, qui eux sont dans la gestion des droits, permissions et applications, devront automatiquement se connecter sur mon interface web et effectuer leurs modifications. Mais grâce à celle-ci, ces utilisateurs ne perdront plus de temps à devoir naviguer entre différents logiciels pour effectuer leurs tâches et différents réseaux pour effectuer les mêmes actions que sur le précédent, c’est notre application qui les fera pour eux.

Mon application est utilisée par des centaines d’utilisateurs pour certains directement et pour d’autre indirectement.

C’est grâce au développement modulaire que fournit Symfony, qu’il a été possible de faire un déploiement des bundles d’authentification et d’information rapidement sur les applications tierces, ce qui m’a fait gagner énormément de temps.

Cette [XMLmind] étant développée avec Symfony est très modulaire, comme dit précédemment, cette modularité est aussi un gros avantage pour sa durée de vie. Le corps de cette application ayant déjà été développé, pour rajouter des fonctionnalités ou modifier le design pour le rajeunir un peu, il n’y aura pas besoin de redévelopper une application de zéro. Des modules pourront lui être rajouter, ce qui lui permettra gérer d’autre types d’information. De plus possédant une partie Webservice, il sera possible de rajouter des fonctionnalités pour lui permettre de communiquer avec d’autres applications tout aussi facilement.

Rétrospective

Stage

Lors de ce stage j’ai pu mettre en place l’ensemble de mes compétences acquises pendant mon cursus scolaire, aussi bien niveau technique que niveau stratégique. Pour ce qui est du niveau managérial, j’ai dû uniquement gérer ma propre personne, donc je n’ai pas réellement pu mettre en pratique, les méthodes de management que j’eu l’occasion de voir durant mes études.

Pour ce qui est de la partie technique, mes compétences en PHP que j’ai pu acquérir en tant qu’autodidacte, complétées par mes cinq ans d’études et surtout par mon année et demi de stage. Cela m’a permis d’acquérir des compétences dans l’utilisation de Frameworks, mais aussi dans la façon de développer, en nommant les variables logiquement, en donnant des noms explicites aux fonctions et surtout en rajoutant des commentaires qui permettront à la personne reprenant le projet, de comprendre plus rapidement le but d’une fonction ou d’une classe.

Durant ce stage il a fallu me familiariser avec l’utilisation d’un nouveau Framework que je ne connais que de nom. Les Frameworks se ressemblant un peu, la prise en main n’a pas été très compliquée, mais ce Framework utilise souvent des bundles et je ne connaissais que brièvement ce système. Une fois celui-ci pris en main, je me suis aperçu de son utilité mais aussi de sa facilité à permettre le portage de morceaux de code d’un projet vers un autre.

La méthode de gestions de projets utilisée au cours de mon stage est l’une des méthodes que j’ai pu étudier au cours de mes années d’études.

La méthode Scrum est la méthode choisie pour réaliser ce projet. Cette méthode nous permet une plus grande flexibilité de développement et une évolution au cours du projet. Elle me laisse, de ce fait, une place pour mes idées et mes améliorations que je pense avoir apportées au projet.

C’est aussi la méthode que j’ai pu expérimenter pendant un an et demi durant mon stage précédent. De ce fait j’ai pu me perfectionner à son utilisation et à sa pratique.

J’ai aussi pu acquérir une meilleure évaluation du temps estimé pour la réalisation d’une tache. Cela m’a permis de respecter aux mieux les délais fixés au cours des sprints.

Ce stage aura permis de me perfectionner dans le niveau technique mais aussi dans le niveau méthologique. Il m’aura apporté énormément de choses comme le travail en équipe, la rigueur dans le développement mais aussi l’analyse des besoins.

Les développements effectués durant ce stage se sont plutôt bien passés et sans soucis majeur. Le travail fournis a eu l’air de satisfaire les chefs de projet. Il a respecté toutes les conditions imposées et les idées que j’ai pu avoir ont elles aussi étaient acceptées.

De plus étant déjà familiarisé avec la méthode de développement mise en place dans le service, j’ai pu prendre mes repères assez vite et être rapidement opérationnel. J’ai pu créer mes listes de tâches à réaliser et estimer leur temps, qui ont tous été respectés, sauf un qui a pris plus de temps que prévu car une partie administration système était à mettre en place.

Annexes

Tableau comparatif des méthodes de managements

Diagramme de Gantt

Structure de la base de données

Diagramme de séquence du WebHook

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels