3.2 Conception
3.2.1 Architecture fonctionnelle
Figure 12 : Architecture fonctionnelle de la plateforme
Supervision et exploitation à distance des
plateformes de services via le modèle client-serveur et à
l'aide
du GSM comme protocole de communication.
Mémoire de fin d'études d'Ingénieur de
Conception de Génie Informatique. ENSP 56
3.2.2 Description de l'architecture
1. L'utilisateur s'authentifie via la page connexion de
l'application mobile. L'application mobile appelé supervisorSMS est
téléchargeable à travers une url.
a. Vérifie s'il existe dans l'active directory. S'il
existe ouvre une session sécurisée où la plateforme et
l'utilisateur vont échanger des données cryptées. Cette
session expirera au bout temps d'inactivité par soucis de
sécurité.
b. S'il n'existe pas dans l'active directory, on le cherche dans
la base de données de la plateforme. S'il existe dans la base de
données, on est dans le cas de 1.a
c. S'il n'existe nulle part alors la plateforme envoie une
demande de création de l'utilisateur par SMS à l'administrateur.
Ce dernier est libre de le créer ou pas. Par contre si le compte est
créé, la plateforme envoi un SMS de notification pour le
renseigner que son compte est créé. L'utilisateur doit contacter
l'administrateur pour rentrer en possession de ses paramètres de
connexion. L'utilisateur a le droit de modifier son profil.
2. L'utilisateur saisi sa commande à partir du
téléphone. Le logiciel (supervisorSMS installé dans le
téléphone) se charge de crypter son SMS et le transmet à
la plateforme en passant par la passerelle de SMS et MMS.
3. La communication entre la passerelle et la plateforme se fait
à l'aide des appels de
méthodes puisqu'elle forme la méme application et
tourne sur le même serveur.
4. La plateforme reçoit le SMS crypté, le
décrypte, cherche le niveau de criticité de la commande
a. Vérifie si cette commande existe sinon envoi un SMS
pour justification.
b. L'envoi et la réception des SMS entre le
téléphone et la plateforme se fait à l'aide d'un lexique
de commandes.
c. La plateforme vérifie s'il a les habilitations
d'exécuter cette commande sinon la commande ne sera pas
exécutée.
d. Dans le cas contraire, la commande sera envoyée au
service approprié pour exécution.
i. La plateforme vérifie le niveau de criticité
(en fonction du niveau de criticité de la commande, la plateforme
demande la confirmation avant l'exécution de la commande)
Supervision et exploitation à distance des
plateformes de services via le modèle client-serveur et à
l'aide
du GSM comme protocole de communication.
Mémoire de fin d'études d'Ingénieur de
Conception de Génie Informatique. ENSP 57
ii. La plateforme utilise le protocole SSH pour l'envoi des
commandes à distance.
iii. Par souci de sécurité la session est maintenu
ouverte jusqu'à la fin de l'exécution de la commande.
5. Le service exécute la commande
a. renvoie le résultat à la plateforme dans le cas
où l'exécution de la commande nécessite une
réponse.
b. Dans le cas contraire renvoie un accusé de
réception. Pour notifier que l'exécution de la commande s'est
bien déroulée.
6. Dès réception de la réponse ou de
l'accusé de réception, la plateforme
a. Envoi un mail (signé avec un certificat) à
l'utilisateur ayant émis la commande avec SMS de notification.
b. Dans le cas contraire envoi juste un SMS de notification.
7. La communication entre les services et la plateforme se fait
à l'aide des protocoles SSH.
8. En cas de problème remonté la plateforme doit
informer les utilisateurs par mail et par SMS
a. Par mail le problème sera plus
détaillé
b. Par contre par SMS le problème serait
résumé vu le format imposé par le SMS
9. Toutes les transactions effectuées par la plateforme
sont journalisées.
i. Pour permettre la traçabilité des actions
effectuées par les utilisateurs. Les fichiers de journalisations sont
accessibles via la plateforme
ii. Visualiser l'historique des logs à partir du
navigateur.
L'application mobile permet des échanges de SMS
cryptés. Cette application utilise le cryptage AES. Toute cette
procédure est représentée par la Error! Reference
source not found..
La sécurité de notre plateforme est basée
sur les différentes parties suivantes :
· L'authentification : il
s'agit du fait que les utilisateurs doivent s'identifier pour pouvoir
accéder au système. Les utilisateurs peuvent s'identifier
eux-mêmes dès leur entrée dans le système, sinon le
système leur demande de s'identifier lorsqu'ils tentent d'accéder
à une ressource protégée sans s'être
identifiés au préalable. La combinaison identificateur-mot de
passe constitue le mode le plus fréquent d'identification d'un
utilisateur auprès du
Supervision et exploitation à distance des
plateformes de services via le modèle client-serveur et à
l'aide
du GSM comme protocole de communication.
Mémoire de fin d'études d'Ingénieur de
Conception de Génie Informatique. ENSP 58
système. Une fois l'utilisateur authentifié, le
système peut déterminer si celui-ci est autorisé à
accéder aux ressources demandées.
o Pour le coté mobile s l'utilisateur envoi une commande
sans être authentifié, le système envoi un SMS de demande
d'authentification.
o Sur la plateforme, l'utilisateur n'a accès que s'il
s'est authentifié.
· La gestion des utilisateurs et des profils :
centraliser l'administration des identités des utilisateurs, de
leurs pouvoirs et de leurs autorisations est souhaitable dans de nombreux
environnements. La gestion des utilisateurs et des groupes inclut des pages Web
où les utilisateurs peuvent enregistrer et gérer leurs
informations de compte.
· L'autorisation ou le contrôle
d'accès : après avoir déterminé
l'identité de l'utilisateur, le serveur un utilisateur est
autorisé à accéder aux pages de la plateforme en fonction
de ses droits d'accès. Cette autorisation passe par la
détermination du profil auquel appartient l'utilisateur, d'où une
consultation du serveur LDAP par la plateforme ou de la base de
données.
· Le SSO : l'objet du SSO est
de centraliser l'authentification afin de permettre à l'utilisateur
d'accéder à toutes les ressources (machines, systèmes,
réseaux) auxquels il est autorisé d'accéder, en
s'étant identifié une seule fois sur le réseau via notre
plateforme. L'objectif du SSO est ainsi de propager l'information
d'authentification aux différents services du réseau, voire aux
autres réseaux et d'éviter ainsi à l'utilisateur de
multiples identifications par mot de passe. Ceci n'est possible qu'après
la configuration du SSO dans le système. Dans notre cas un utilisateur
ne peut pas avoir plusieurs sessions ouvertes avec les mêmes
paramètres de connexion, que ce soit du côté mobile ou de
la plateforme.
Supervision et exploitation à distance des
plateformes de services via le modèle client-serveur et à
l'aide
du GSM comme protocole de communication.
Mémoire de fin d'études d'Ingénieur de
Conception de Génie Informatique. ENSP 59
Figure 13 : diagramme de séquencement
Supervision et exploitation à distance des
plateformes de services via le modèle client-serveur et à
l'aide
du GSM comme protocole de communication.
Mémoire de fin d'études d'Ingénieur de
Conception de Génie Informatique. ENSP 60
| 
