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
- 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 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.
Procédure
Exemple : Connexion par formulaire
- Connexion par formulaire Java EE
- Filtre de servlets Java EE avec connexion
- Extension IBM® : connexion par formulaire
<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.
<!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>
<!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>
<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>
META-INF
META-INF/MANIFEST.MF
login.html
error.jsp
WEB-INF/
WEB-INF/classes/
WEB-INF/classes/aServlet.class
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.
- L'URI de fermeture de session par formulaire est spécifiée dans le navigateur Web et charge le formulaire approprié.
- L'utilisateur clique sur Envoyer dans le formulaire pour se déconnecter.
- 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 :
- Il efface les cookies LTPA (Lightweight Third Party Authentication) / de connexion unique.
- Il invalide la session HTTP.
- Il supprime l'utilisateur du cache d'authentification.
- 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é.
<!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>