Les articles de ESSI# - Identification par formulaire ASP.NET

RACINE
 

Identification par formulaire ASP.NET

Voir dans une fenêtre à part Cliquez ici pour voir la page dans un explorateur séparé.


Introduction

Cliquez pour télécharger Cliquez ici pour obtenir les sources de l'application Web.


En réponse à des projets personnels, j'ai eu besoin de sécuriser l'accès à une partie de mon site web. Je me suis donc penché sur le "comment faire avec .NET".
Dans l'urgence, j'ai réalisé un bricolage à base de variables sessions (stockées dans un cookie sur le poste du client, on peut les consulter du serveur à la demande) avec un genre de "si pas loggué alors bye". Cette solution remplissait mes besoins, mais n'était pas de plus élégantes ...

ASP.NET propose 4 moyens pour sécuriser votre Web :
  1. None : aucune ou plutôt custom.
  2. Passport : par compte MS Passport, mais pas gratuit.
  3. Windows : en créant des comptes sur votre machine
  4. Forms : en utilisant des formulaires :)
J'ai opté pour la quatrième (les formulaires) car ils me semblaient simples à mettre en place et requièraient le minimum de manipulations sur la machine (à la différence de l'identification Windows). Et ne parlons pas du mode Passport, payante.

Je rappellerai que les formulaires se basent sur un mécanisme simple : vous (client) possédez un cookie (petit fichier texte) dans lequel est déposé un login/password (rempli par la page de login justement). A chaque accès aux pages de l'application (répertoire), ASP.NET vérifie que vous possédez bien un tel cookie, et que les informations contenues sont valides (bien formées, et vous êtes quelqu'un d'autorisé). Si vous n'êtes pas accrédité, vous êtes automatiquement redirigé vers la page d'identification. En cas d'identification réussie, vous serez renvoyés vers la page que vous demandiez à l'origine.

Pour utiliser .NET framework, vous devez avoir installé sur votre poste AU MOINS :
  1. Windows XP Pro ou 2000 avec SP2 ou NT4 avec SP6a
  2. Internet Explorer 5.01
  3. IIS (mais pas dans tout les cas)
  4. .NET Framework SDK (evidemment !!)
  5. un éditeur de votre choix (emacs ou VS.NET suivant les courants de pensée et les moyens)

Je prends pour pré-requis que mon lecteur a un niveau même faible en C# (voir de Java au vues de ressemblances syntaxiques), mais possède des connaissances ASP ou ASP.NET (voir de la pratique).



Voici la liste des différents styles visuels utilisés dans ce cours (et les suivants) :
Si vous voyez ceci ... ...ça veut dire cela.
IDisposable Interface C'est un lien vers une page d'aide du .NET Framework SDK. Ce lien ne fonctionnera que si le .NET framework SDK ANGLAIS est installé sur votre poste courant.
Si vous avez la version française, modifiez les liens comme suit :
ms-help://MS.NETFrameworkSDK/... en
ms-help://MS.NETFrameworkSDK.Fr/...

Ok, c'est pas forcément une bonne idée de Microsoft, mais c'est ainsi ... :(
--> téléchargez le source
C'est un lien vers un fichier téléchargeable hosté sur le même site.

Identification par formulaire

Mise en place


Cliquez pour télécharger Cliquez ici pour obtenir les sources de l'application Web.


On supposera que nous avons l'architecture suivante pour notre article :
\
 login.aspx      --> La page Login/Password
 login.aspx.cs
 default.aspx    --> Une des pages à protéger
 default.aspx.cs
 web.config      --> Le fichier de configuration de l'application

 bin\
  formsauth.dll  --> La DLL contenant le projet
Sachez que vous ne protégez pas qu'une page avec cette méthode : vous protégez toutes les pages présentes dans le répertoire. C'est grâce au fichier web.config que ASP.NET prends en compte à chaque accès de page. Il vérifie (notamment) que les restrictions de sécurités que vous exigez sont mises en place. Ainsi, dans notre cas, tout accès à default.aspx par une personne non enregistrée se soldera par une redirection vers la page de login. Et si l'étape de login est validée, alors la page demandée à l'origine s'affichera (donc default.aspx).

Petite précision, ASP.NET a besoin pour l'identification par formulaires d'une page nommée default.aspx. Par conséquent, fournissez lui en une, même si elle ne fait qu'une redirection ...En effet, c'est vers cette dernière que l'utilisateur est redirigé s'il accède de lui-même à la page de login.

Web.config

C'est le fichier qui contient les informations de configuration de votre application web. C'est dans celui-ci que nous allons demander de la sécurisation.

Si vous utilisez Visual Studio .NET pour créer vous applications web, ce dernier vous génère un fichier web.config de base. Si vous n'en avez pas, recopiez celui présent dans l'archive (sinon, complétez votre ancien).
<configuration>  
  <system.web>

    ...
  
    <authentication mode="Forms">
        <forms name=".BLADEUPLOADCOOKIE" loginUrl="login.aspx" protection="All" timeout="20">	  
	  <credentials passwordFormat = "SHA1">               
	    <user name="test" password="A94A8FE5CCB19BA61C4C0873D391E987982FBBD3" />	       
	    <user name="toto" password="0B9C2625DC21EF05F6AD4DDF47C5F203837AA32C" />          
	  </credentials>        
	</forms>    
    </authentication>

    <authorization>        
      <deny users="?" />    
    </authorization>

    ...

  </system.web>
</configuration>

authentication

C'est dans cet élément que vous précisez le mode d'identification (dans notre cas "Forms"). Ceci implique maintenant la précense de certains sous éléments.
forms
attribut utilité
namele nom du cookie. ATTENTION ! Celui-ci doit être unique (sinon, risque de collision avec le cookie du voisin)
loginUrlle nom de la page qui jouera le rôle d'identification. Typiquement, "login.aspx".
protectionLa valeur "All" indique que le cookie sera protégé au maximum (encryption + validation)
timeoutla durée de vie en minutes du cookie. Si aucune activitée n'est détectée pendant cette période, le cookie est détruit. Sinon, sa durée de vie est prolongée d'autant.
credentials
Vous choisissez le format de hashage du mot de passe (Clear == texte clair, SHA1 == crypté, MD5 == crypté). Vous disposez ensuite à l'intérieur de cet élément des sous éléments de type user qui font correspondre un identifieur (name) en clair à une valeur de hashage correspondant au mot de passe de l'utilisateur (password).

Dans notre application, l'utilisateur "test" (reciproquement "toto") a pour mot de passe "test" (recip. "tutu").

: pour générer une valeur de hashage correspondant à un mot de passe (string) voulu, utilisez :
hash = System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile (le-mot-de-passe, 
                                                                                   algo-hashage);
Avec le-mot-de-passe qui vaut évidement votre mot de passe secret et algo-hashage qui vaut "sha1" ou "md5" suivant vos choix ...
Plus d'info dans l'aide .NET : FormsAuthentication.HashPasswordForStoringInConfigFile Method

authorization

L'élément <deny users="?" /> signifie que tout les utilisateurs anonymes seront refusés.
Pour plus d'info : ASP.NET Authorization

Login.aspx

Une bonne page de login comporte nécessairement un champ pour le login (ou identifiant) et un pour le password (ou mot de passe), ainsi qu'un bouton pour valider. Enrobez le tout avec deux lignes d'explication, un bouton reset pour faire joli. Et si le coeur vous en dit, fignolez en rajouttant des FieldValidator chargés de vérifier que les champs sont bien remplis.

Voici le code utile de notre page de login :
 1: private void Button1_Click(object sender, System.EventArgs e) {
 2:   if (FormsAuthentication.Authenticate(tboxLogin.Text, tboxPassword.Text)){
 3:     FormsAuthentication.RedirectFromLoginPage(tboxLogin.Text, false);
 4:   }
 5:   else {
 6:     //message d'erreur et compagnie
 7:     lblLoginInvalide.Visible = true;
 8:   }
 9: }
  • Ligne 2 (Authenticate) : vous demandez à ASP.NET si ce login (tboxLogin.Text) et le password correspondant (tboxPassword.Text) sont connus et authorisés à passer la phase d'identification.
  • Ligne 3 (RedirectFromLoginPage) : login ok, vous demandez à être redirigé vers la page qui a demandé l'identification (ou default.aspx si aucune). Vous passez en paramètres (dans l'ordre) le username (pas obligatoirement le même que celui de l'identification) et si le cookie doit être persistant entre les sessions.
  • Ligne 7 : vous racontez des horreurs au malheureux utilisateur dyslexique des doigts qui n'a pas réussis à se logguer.

Voici un exemple de page de login ...
une page de login

Un exemple de page de login


Default.aspx

ASP.NET a besoin pour l'identification par formulaires d'une page nommée default.aspx. Par conséquent, fournissez lui en une, même si elle ne fait qu'une redirection ...En effet, c'est vers cette dernière que l'utilisateur est redirigé s'il accède de lui-même à la page de login.

Peu importe ce que comporte votre page : vos dernières photos de vacances, un dossier ultra-secret du FBI ou un simple Hello. Par contre, il serait interressant de posséder un bouton (par exemple) de "logout". En effet, le cookie a une durée de vie, et tant qu'il est valide, vos pages sont accessibles par le browser web. Ce n'est pas très malin si la personne autorisée part et laisse le browser à quelqu'un de malveillant ou de trop curieux.

Voici les 2 lignes de code qui doivent être effectuées au click :
private void Button1_Click(object sender, System.EventArgs e) {
  FormsAuthentication.SignOut();
  Response.Redirect ("login.aspx");
}
Dans la première, on renonce de manière impérative à nos droits acquis par la phase de login (destruction du cookie) et par la deuxième, on va voir ailleurs (la redirection vers la page de login est facultative).

Compilation

Mettez vous dans la racine du projet, et un tapez un vénérable :
csc /out:bin\monprojet.dll /t:library *.cs
S'il n'y a pas d'erreur, vous devriez être sur le bon chemin. Testez vite votre application !!!

Testez plusieurs choses : l'accès à une page du site, à la page de login, etc ...

Essayez ceci : logguez vous, délogguez et accédez à une page "protégée" que vous venez de visiter en tapant directement son url. Quoi ?! La page s'affiche ? L'identification ASP.NET par formulaire c'est des fadaises ? Mais non mais non ! Ce que vous voyez est la page HTML résultat de votre page ASPX qui est dans le cache de votre navigateur ... pour preuve, essayez de faire une action (clic ou autre) sur cette page et vous serez redirigé poliement vers la page de login.

Le mot de la fin

Conclusion

J'espère que cet article que j'ai essayé de faire concis mais assez détaillé pour se passer de pointeurs externes "excessifs". Il répond à une problèmatique précise, et je vous enjoins à suivre les pointeurs ci-dessous pour aller plus loin (notamment Forms Authentication Using An XML Users File).

Si vous avez des remarques concernant cet article ((im)précisions, remarques, ...) faites moi signe ;)!!

Remerciements

Monsieur Laurent ELLERBACH, responsable relation études supérieures chez Microsoft France, pour ses idées et son soutien logistique.

Sources

Sur le Web :
Sur le Web :
  • Designing Microsoft ASP.NET Applications (cher) ISBN : 0-7356-1348-6 chez MSPress

 




par Alain Vizzini (vizzini@essi.fr )
pour l'ESSI & Microsoft, création 02-03-2003, dernière màj 02-03-2003


+ 17.000 pages vues depuis le 14 oct. 2002