Personnalisation de la connexion aux applications Web

Vous pouvez créez une page de connexion par formulaire et une page d'erreur pour authentifier un utilisateur.

Avant de commencer

Un client Web ou un navigateur peut authentifier un utilisateur auprès d'un serveur Web à l'aide d'un des mécanismes suivants :
  • Authentification de base HTTP : Un serveur Web demande au client Web de s'authentifier et le client Web transmet un ID utilisateur et un mot de passe dans l'en-tête HTTP.
  • Authentification client HTTPS : Ce mécanisme nécessite qu'un utilisateur (client Web) possède un certificat de clé privé. Le client Web envoie ce certificat à un serveur Web qui demande les certificats client. Il s'agit d'un mécanisme d'authentification puissant qui utilise le protocole HTTP (Hypertext Transfer Protocol) avec SSL (Secure Sockets Layer).
  • Authentification par formulaire : Un développeur contrôle l'aspect des écrans de connexion à l'aide de ce mécanisme d'authentification.

L'authentification de base HTTP (Hypertext Transfer Protocol) transmet un mot de passe utilisateur du client Web vers le serveur Web codé en base 64 simple. L'authentification par formulaire transmet un mot de passe utilisateur à partir d'un navigateur vers le serveur Web au format texte. C'est pourquoi l'authentification de base HTTP et l'authentification par formulaire ne sont pas très fiables sauf si le protocole HTTPS est utilisé.

Le descripteur de déploiement de l'application Web contient des informations sur le mécanisme d'authentification à utiliser. Lorsque l'authentification par formulaire est utilisée, le descripteur de déploiement contient également des entrées pour les pages de connexion et d'erreur. Une page de connexion peut être soit une page HTML, soit une page JSP (JavaServer Pages). Cette page s'affiche côté client Web lorsque vous accédez à une ressource sécurisée (servlet, fichier JSP, page HTML) dans l'application. En cas d'échec de l'authentification, une page d'erreur s'affiche. Vous pouvez rédiger des pages de connexion et d'erreur afin de répondre aux besoins spécifiques de votre application et contrôler l'aspect de ces pages. Lors de l'assemblage de l'application, l'assembleur peut définir le mécanisme d'authentification pour l'application et définir les pages de connexion et d'erreur dans le descripteur de déploiement.

La connexion par formulaire applique la méthode de servlet sendRedirect, qui comporte plusieurs implications pour l'utilisateur. La méthode sendRedirect est utilisée deux fois au cours de la connexion par formulaire :
  • La méthode sendRedirect affiche d'abord la page de connexion par formulaire dans le navigateur Web. Elle redirige ensuite ce dernier dans la page protégée sollicitée à l'origine. La méthode sendRedirect(String URL) ordonne au navigateur Web d'utiliser la requête GET HTTP pour obtenir la page spécifiée dans l'adresse Web. Si HTTP POST est la première demande à un fichier de page de servlet ou JavaServer (JSP) protégé et qu'aucune authentification ou connexion précédente n'a eu lieu, HTTP POST n'est pas acheminé à la page demandée. En revanche, HTTP GET est acheminée, car la connexion par formulaire emploie la méthode sendRedirect, qui se comporte comme une demande HTTP GET qui tente d'afficher la page demandée après l'établissement d'une connexion.
  • Avec HTTP POST, vous risquez d'être confronté à une situation où un formulaire HTML non protégé recueille des données auprès des utilisateurs, puis les soumet pour traitement à des servlets ou fichiers JSP protégés, alors que les utilisateurs ne sont pas connectés pour la ressource. Pour éviter ce cas de figure, structurez votre application ou vos droits d'accès Web de sorte que les utilisateurs soient obligés d'utiliser une page de connexion par formulaire avant que l'application n'effectue de quelconques actions HTTP POST sur des servlets ou fichiers JSP protégés.
Remarque : Vérifiez que les fichiers inclus dans votre page de connexion au formulaire (tels que les feuilles de style externes, ou images) sont non protégés.

Procédure

  1. Créez une page de connexion par formulaire en définissant son aspect et notamment les éléments requis pour effectuer une authentification par formulaire.
  2. Créez une page d'erreur. Vous pouvez programmer les pages d'erreur afin d'effectuer une nouvelle tentative d'authentification ou d'afficher un message d'erreur approprié.
  3. Placez les pages de connexion et d'erreur dans le fichier d'archive Web (.war) relatif au répertoire supérieur. Par exemple, si la page de connexion est définie sous la forme /login.html dans le descripteur de déploiement, elle doit être placée dans le répertoire supérieur du fichier WAR. Un assembleur peut également effectuer cette étape à l'aide de l'outil d'assemblage.
  4. Créez une page de déconnexion par formulaire et insérez-la dans l'application uniquement si l'application Web requiert un mécanisme d'authentification par formulaire.

    Par défaut, l'URL de la page de déconnexion doit pointer l'hôte auquel la demande a été adressée ou son domaine. Sinon, une page de déconnexion générique s'affiche. Si vous avez besoin que cette URL pointe vers un hôte différent, vous devez définir la propriété com.ibm.websphere.security.logoutExitPageDomainList dans le fichier security.xml avec la liste des URL autorisées pour la page de connexion. Vous pouvez choisir d'autoriser l'utilisation de n'importe quelle page de sortie de déconnexion en définissant la propriété com.ibm.websphere.security.allowAnyLogoutExitPageHost sur la valeur true. Si vous définissez cette propriété sur true, vous risquez d'exposer vos systèmes à des redirections d'URL malveillantes.

Exemple : Connexion par formulaire

Vous pouvez utiliser les fonctions de connexion de WebSphere Application Server implémenter et configurer des procédures de connexion par formulaires. Utilisez les technologies suivantes relatives aux fonctionnalités de connexion de WebSphere Application Server et Java™ Platform, Enterprise Edition (Java EE) :
  • Connexion par formulaire Java EE
  • Filtre de servlets Java EE avec connexion
  • Extension IBM® : connexion par formulaire
L'exemple de connexion par formulaire fait partie du module Technology Samples. Pour plus d'informations sur les modalités d'accès à l'exemple de connexion par formulaire, voir Accès aux modèles.
Utilisation de la connexion par formulaire
Pour que l'authentification se déroule normalement, l'opération de connexion par formulaire doit toujours comporter l'action j_security_check. L'exemple suivant explique comment coder le formulaire sous la forme d'une page HTML :
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="text" name="j_password" autocomplete="off">  
<\form>

La zone d'entrée j_username permet d'obtenir le nom d'utilisateur et la zone d'entrée j_password le mot de passe utilisateur.

Lors de la réception d'une demande d'un client Web, le serveur Web envoie la page de formulaire configuré au client et conserve la demande originale. Lorsque le serveur Web reçoit le page de formulaire remplie, il en extrait le nom d'utilisateur et le mot de passe afin d'authentifier l'utilisateur. Si l'authentification aboutit, le serveur Web redirige l'appel vers la demande d'origine. En cas d'échec, il redirige l'appel vers la page d'erreurs configurée.

Vous trouverez ci-après un exemple de page de connexion au format HTML (login.html) :
<!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.0 Transitional//EN">
<html>
<META HTTP-EQUIV = "Pragma" CONTENT="no-cache">
<title> Security FVT Login Page </title>
<body>
<h2>Form Login</h2>
<FORM METHOD=POST ACTION="j_security_check">
<p>
<font size="2"> <strong> Enter user ID and password: </strong></font>
<BR>
<strong> User ID</strong> <input type="text" size="20" name="j_username">
<strong> Password </strong>  <input type="password" size="20" name="j_password" autocomplete="off">
<BR>
<BR>
<font size="2">  <strong> And then click this button: </strong></font>
<input type="submit" name="login" value="Login">
</p>

</form>
</body>
</html>
Vous trouverez ci-après un exemple de page d'erreur dans un fichier JSP :
<!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.0 Transitional//EN">
<html>
<head><title>A Form login authentication failure occurred</head></title>
<body>
<H1><B>A Form login authentication failure occurred</H1></B>
<P>Authentication may fail for one of many reasons. Some possibilities include:
<OL>
<LI>The user-id or password may be entered incorrectly; either misspelled or the 
wrong case was used.
<LI>The user-id or password does not exist, has expired, or has been disabled.
</OL>
</P>
</body>
</html>
Lorsque l'assembleur configure l'application Web afin d'effectuer une authentification par formulaire, le descripteur de déploiement contient la configuration de connexion, comme indiqué ci-après :
<login-config id="LoginConfig_1">
<auth-method>FORM<auth-method>
<realm-name>Example Form-Based Authentication Area</realm-name>
<form-login-config id="FormLoginConfig_1">
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>
Voici un exemple de structure de répertoires de fichiers WAR (Web Application Archive) illustrant les pages de connexion et d'erreurs pour la configuration de connexion précédente :
META-INF
     META-INF/MANIFEST.MF
     login.html
     error.jsp
     WEB-INF/
     WEB-INF/classes/
     WEB-INF/classes/aServlet.class
Fermeture de session par formulaire

La fermeture de session par formulaire est un mécanisme qui permet de se déconnecter sans devoir fermer toutes ses sessions de navigateur Web. Une fois la déconnexion effectuée à l'aide de ce mécanisme, l'accès à une ressource Web protégée nécessite une nouvelle authentification. Cette fonction n'est pas requise par les spécifications J2EE mais fournie en complément dans le système de sécurité WebSphere Application Server.

Supposons que vous souhaitiez vous déconnecter après avoir ouvert une session d'application Web et effectué des actions. La fermeture de session par formulaire fonctionne comme suit :
  1. L'URI de fermeture de session par formulaire est spécifiée dans le navigateur Web et charge le formulaire approprié.
  2. L'utilisateur clique sur Envoyer dans le formulaire pour se déconnecter.
  3. Le code de sécurité de WebSphere Application Server déconnecte l'utilisateur. Au cours de ce processus, le serveur d'applications exécute les processus suivants :
    1. Il efface les cookies LTPA (Lightweight Third Party Authentication) / de connexion unique.
    2. Il invalide la session HTTP.
    3. Il supprime l'utilisateur du cache d'authentification.
  4. Lors de la déconnexion, l'utilisateur est redirigé vers une page de sortie appropriée.

La fermeture de session par formulaire ne nécessite l'ajout d'aucun attribut spécifique dans un descripteur de déploiement. La page de fermeture de session par formulaire est une page HTML ou un fichier JSP (JavaServer Pages) inclus dans l'application Web. Cette page ressemble à la plupart des formulaires HTML mais elle comporte une action Post spéciale (comme la page de connexion par formulaire). Cette action Post est reconnue par le conteneur Web, qui l'envoie à un servlet interne spécial de déconnexion par formulaire. L'action Post de la page de déconnexion par formulaire doit s'appeler ibm_security_logout.

Une page de sortie peut être spécifiée dans le formulaire de déconnexion. Il peut s'agir d'un fichier HTML ou JSP qui fait partie de l'application Web vers laquelle l'utilisateur est redirigé lorsqu'il ferme sa session. De plus, la page de déconnexion permet d'utiliser une URL complète sous la forme http://nom_hote:port/URL. Cette page de sortie est spécifiée sous forme de paramètre dans la page du formulaire de fermeture de session. Si cette page n'est pas spécifiée, un message HTML de fin de session par défaut est affiché.

Voici un exemple de formulaire HTML de fermeture de session. Ce formulaire configure la page de sortie de manière à ce que, lorsque l'utilisateur ferme sa session, il soit redirigé vers la page de connexion.
<!DOCTYPE HTML PUBliC "-//W3C/DTD HTML 4.0 Transitional//EN">
<html>
		<META HTTP-EQUIV = "Pragma" CONTENT="no-cache">
		<title>Logout Page </title>
		<body>
		<h2>Sample Form Logout</h2>
						<FORM METHOD=POST ACTION="ibm_security_logout" NAME="logout">
						<p>
						<BR>
						<BR>
						<font size="2"><strong> Click this button to log out: </strong></font>
						<input type="submit" name="logout" value="Logout">
						<INPUT TYPE="HIDDEN" name="logoutExitPage" VALUE="/login.html">
						</p>
						</form>
		</body>
</html>

Que faire ensuite

Une fois les pages de connexion et d'erreur développées, ajoutez-les à l'application Web. Au moyen de l'outil d'assemblage, configurez un mécanisme d'authentification et intégrez la page de connexion et celle d'erreur dans le descripteur de déploiement de l'application.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_pofolo
Nom du fichier : tsec_pofolo.html