Les fondamentaux – Architecture Citrix Secure Gateway – Part 2

Salutations Citrixiens en herbe,

Je continue dans la lancée d’une mise en place de Citrix Secure Gateway. Cette article suit donc le post “Les fondamentaux – Architecture Citrix Secure Gateway – Part 1”.

Une fois que vous avez en tête les différents composant, je vais vous décrire comment techniquement tout cela s’enchaîne. Tout ce que je décris en dessous se déroule en très peu de seconde, mais il s’en passe des choses en fait, bonne lecture à tous:

1- l’utilisateur ouvre un navigateur Web et lance une URL en HTTPS. L’url correspond au nom FQDN d’une passerelle Citrix Secure Gateway (tescitrixoupas.demo.fr par exemple),

2- La passerelle CSG envoie son certificat serveur vers le navigateur Web. Le poste utilisateur doit donc posséder le certificat racine de l’entité certifiante qui a créée le certificat serveur,

3- Une fois la liaison SSL établie, la passerelle CSG présente la page d’authentification de la Web Interface. Donc par défaut, l’utilisateur est en HTTPS vers la CSG et CSG communique en HTTP avec la Web Interface (ce flux peut être aussi sécurisé par un certificat SSL),

4- L’utilisateur entre son identification, Web Interface soumet cette identification au serveur XenApp via le port XML de XenApp. XenApp interroge l’Active Directory ou la NDS Novell ou la base SAM local, et si le compte est valide, il retourne la liste des applications aux-quelles l’identifiant à droit et l’envoie à la Web Interface,

5- La Web Interface construit donc une page HTML avec les icônes des applications publiées.

6- L’utilisateur clique sur une icône d’application publiée,

7- Web Interface interroge le serveur XenApp, pour connaître l’adresse IP du serveur XenApp de la ferme le plus disponible à l’instant T,

8- Web Interface soumet cette adresse IP au Secure Ticket Authority. le STA sotcke cette adresse IP et donne un ticket de session tronqué à Web Interface,

9- Web Interface construit un fichier de connexion .ica à partir d’un fichier template. Ce fichier de connexion .ica comprend l’adresse FQDN de la passerelle CSG, le ticket de session STA tronqué, l’identifiant du STA (qui n’est exploitable que par la CSG), le nom de l’application publiée et pleins d’autres options de session. Ce fichier est envoyé via le canal SSL vers le poste utilisateur,

10- Ce fichier .ica est interprété par un client Citrix. Ce dernier tente d’ouvrir une session ICA sous SSL vers la passerelle CSG,

11- La passerelle CSG envoie son certificat serveur vers le poste utilisateur. le poste utilisateur doit donc avoir le certificat racine de l’autorité de certification qui à créée le certificat serveur de la passerelle CSG,

12- une fois le tunnel SSL créée, le client ICA ouvre une session ICA vers la passerelle CSG en présentant les informations contenu dans le fichier .ica. La passerelle CSG envoie le ticket de session STA vers celui qui l’a créée et lui demande si ce ticket de session est bien valide. Si oui le STA envoie l’adresse IP du serveur XenApp, qu’il avait stocké à la demande de la Web Interface, à la passerelle CSG,

13- la passerelle établie une connexion ICA sous le port 1494 vers le serveur XenApp.

Donc l’utilisateur se connecte toujours à la passerelle CSG en ICA sous SSL (port 443) et la passerelle CSG se connecte en ICA (port 1494 ou 2598).

J’espère que ça vous éclaire un peu plus 😉

A bientôt pour la partie 3

PS: je vais décrire ce type de connexion sécurisée en plusieurs partie, histoire de ne pas faire de long article (chiant à lire ;))

Patrice Jacques-gustave