Figure 133 : Cinématique de fonctionnement du FrontServer
1. Sur requête venant du navigateur, et si la ressource est protégée, le WebAgent du FrontServer contrôle la présence du jeton d’authentification. Le jeton permet de déterminer l’identité (User-id e-Sentry) de l’utilisateur.
2. Si ce jeton n’est pas valide ou bien est absent, la requête est redirigée vers la fonction d’authentification du serveur e-Sentry.
3. L’authentification s’effectue par un dialogue direct HTTP entre le Navigateur et le serveur de sécurité e-Sentry. Si l’authentification par certificat utilisateur n’est pas envisagée, il est possible de masquer le serveur de sécurité derrière la fonction uniquement reverse Proxy (sans contrôle WebAgent) du FrontServer.
4. Sur authentification réussie de l’utilisateur, le serveur d’authentification relance la requête initiale, cette fois accompagnée du jeton d’authentification. Le WebAgent du FrontServer analyse cette requête pour déterminer à quelle ressource protégée elle est associée. Ce contrôle s’effectue sur la base des informations configurées par l’administrateur de sécurité dans le fichier de configuration locale du WebAgent. Ce contrôle permet de déterminer le nom du service e-Sentry associé à la requête.
5. Muni de ces deux informations : identifiant de l’utilisateur et nom du service demandé, le WebAgent du FrontServer va s’efforcer d’obtenir les informations d’accréditation (bloc d’accréditation) de l’usager sur ce service. Pour cela, le WebAgent du FrontServer va consulter en priorité son ‘cache’ local. Si le bloc d’accréditation n’est pas présent ou est périmé, il va lancer une requête vers le module d’accréditation du serveur de sécurité e-Sentry. Le WebAgent va exploiter le bloc d’accréditation pour, par exemple :
ð contrôler les filtres possibles posés sur les ressources demandées
ð vérifier que l’on est bien dans les heures d’accès autorisée à la ressource
ð extraire et charger automatiquement le champ d’authentification HTTP : Id et mot de passe associé à la protection de cette application
ð positionner des variables dans la 'QueryString' ou dans un ‘header quelconque’ du protocole HTTP
ð Ces différentes paramètres seront trouvés par l’application dans les variables d’environnement Web standards.
6. Suite à ces opérations, la fonction ‘Reverse-Proxy du FrontServer va convertir l’URL reçue en URL effective, et adresser la requête au serveur Web applicatif concerné.
7. Les échanges suivants s’effectueront entre le Navigateur et l’application Web, mais toujours en transitant par le FrontServer et par le contrôle de chaque requête par le WebAgent intégré.