Exporter (0) Imprimer
Développer tout

Combinaison des formulaires et de la sécurité Windows dans ASP.NET

Paul Wilson, MVP
WilsonDotNet.com

S'applique à :
   Microsoft® ASP.NET

Résumé : Depuis longtemps, les développeurs ASP.NET cherchent une méthode qui leur permettrait de combiner les formulaires et la sécurité Windows. Paul Wilson leur fournit une solution adéquate qui capture le nom d'utilisateur Windows, quand cela est possible, ou, sinon, redirige les utilisateurs vers un écran d'ouverture de session. (8 pages imprimées)

Téléchargez le code source de cet article.

Sommaire

Introduction
Authentification par formulaires
Sécurité Windows IIS
Erreurs 401 personnalisées IIS
Ouverture de session personnalisée à l'aide de formulaires
Redirection vers l'URL d'origine
Conclusion

Introduction

De nombreux développeurs Microsoft® ASP.NET cherchent une méthode qui leur permettrait de combiner les formulaires et la sécurité Microsoft® Windows®. La réponse a toujours été du style « ASP.NET ne gère pas l'authentification mixte. ». Examinons donc ce problème d'un point de vue professionnel, sans rentrer dans les détails techniques. Ce que nous voulons vraiment, c'est une méthode qui permette de capturer automatiquement le nom d'utilisateur des utilisateurs de l'Intranet et de rediriger les autres utilisateurs vers un écran d'ouverture de session personnalisé pour qu'ils puissent entrer leur nom d'utilisateur et leur mot de passe. Cela est-il possible ? Surtout, nous devons essayer d'arrêter de réinventer ce qui existe déjà.

Authentification par formulaires

La première chose à faire est de décider du type d'authentification ASP.NET à utiliser. Même si vous souhaitez seulement combiner l'authentification Windows et l'authentification par formulaires, la tâche n'est pas si aisée. Chaque application ASP.NET peut effectuer un seul type d'authentification. Il faut donc choisir. L'authentification Windows fournit uniquement le nom d'utilisateur, qu'il s'agisse de l'utilisateur du processus ASP.NET ou de l'utilisateur client en cours si Microsoft® Internet Information Services (IIS) est configuré pour désactiver l'accès anonyme. Une fois que vous avez accepté ce fait, il apparaît clairement que seule l'authentification par formulaires peut être personnalisée.

Commençons donc par définir l'authentification par formulaires dans le fichier web.config de notre application. Vous devez en outre vérifier à ce stade que votre application ASP.NET est également une application IIS, car cela est requis pour tous les types d'authentification. Il faut aussi spécifier votre autorisation dans web.config, afin de refuser l'accès aux utilisateurs anonymes. La sous-balise des formulaires d'authentification définit plusieurs attributs, dont l'un est loginUrl, qui est le lien vers lequel ASP.NET redirige automatiquement tous les utilisateurs non autorisés pour tout accès.

Vous devez ensuite choisir la page de votre application ASP.NET qui servira de loginUrl. Dans tous les cas d'authentification par formulaires que j'ai rencontrés par le passé, la page sélectionnée était une page Login.aspx. Toutefois, ce n'est pas du tout ce que vous voulez, car vous souhaitez d'abord authentifier vos utilisateurs avec la sécurité intégrée Windows, pour éviter, si possible, la page d'ouverture de session. Votre loginUrl doit donc être une page utilisant la sécurité intégrée Windows. Vous devez par conséquent terminer la configuration de l'authentification par formulaires en définissant loginUrl sur WinLogin.aspx.

Sécurité Windows IIS

Vous devez ensuite gérer la sécurité intégrée Windows au niveau de WinLogin.aspx. Cette opération s'effectue en plusieurs étapes. Il vaut mieux procéder séparément, afin de faciliter leur implémentation. Ce processus consiste à rejeter les utilisateurs anonymes, à obtenir les informations d'authenfication Windows du client, à capturer son nom d'utilisateur Windows et enfin à transmettre ces informations à l'authentification par formulaires. Notez que, dans le cas que nous allons traiter, la sécurité intégrée Windows échoue par la suite. Notez également l'absence de fichier html dans WinLogin.aspx ; il s'agit uniquement d'un test de sécurité intégrée Windows.

Commençons par le rejet des utilisateurs anonymes et l'obtention des informations d'authentification Windows du client. Cette description du problème doit clairement faire apparaître que IIS est la solution dont vous avez besoin dans ce cas, étant donné que ces deux fonctionnalités y ont déjà été intégrées. Il vous suffit de les utiliser. À l'aide de IIS Manager, cliquez avec le bouton droit de la souris sur le fichier WinLogin.aspx, cliquez sur Propriétés, puis sur l'onglet Sécurité de fichier, pour modifier le contrôle d'accès et d'authentification pour ce fichier uniquement. Désélectionnez simplement Activer les connexions anonymes et sélectionnez Authentification intégrée Windows.

Malheureusement, cela ne suffit pas à obtenir automatiquement le nom d'utilisateur. La solution réside dans une trace de page ou dans l'utilisation d'un décompilateur dans la méthode OnEnter de WindowsAuthenticationModule. Le nom d'utilisateur est une variable de serveur appelée LOGON_USER. Il vous suffit de capturer le nom d'utilisateur à l'aide de Request.ServerVariables["LOGON_USER"], puis d'appeler FormsAuthentication.RedirectFromLoginPage pour la connexion à l'authentification par formulaires. Cette méthode unique définit le cookie d'authentification et redirige l'utilisateur vers la page d'origine.

mixedsecurity_fig01.gif

Figure 1. Désactivation de l'accès anonyme et activation de Windows

Erreurs 401 personnalisées IIS

Si vous souhaitiez uniquement utiliser la sécurité intégrée Windows, votre travail s'arrêterait là. Mais vous voulez également gérer les cas où la sécurité intégrée Windows échoue pour certains utilisateurs, en les redirigeant d'une façon ou d'une autre vers votre écran d'ouverture de session personnalisé pour obtenir leurs informations d'authentification utilisateur. Notez également que l'implémentation de la sécurité intégrée Windows dépend du navigateur, étant donné que les navigateurs autres qu'Internet Explorer présentent à l'utilisateur une boîte de dialogue d'ouverture de session qu'ils peuvent annuler pour faire échouer la connexion. Vous devez par conséquent comprendre ce qui se passe lorsque la vérification de la sécurité intégrée Windows échoue.

Que se passe-t-il donc dans ce cas ? L'utilisateur reçoit une erreur 401. ASP.NET comporte une fonctionnalité permettant de capturer et de rediriger la plupart des erreurs dans le fichier web.config, mais, malheureusement, les erreurs 401 et 403 sont des exceptions qui doivent par conséquent être gérées d'une autre façon. Encore une fois, la description du problème doit faire apparaître clairement que IIS est la solution idéale. Même si vous pouvez déclencher l'authentification en envoyant un code de statut 401 pour éviter de configurer IIS, je ne connais aucun moyen d'éviter d'utiliser IIS pour gérer une erreur 401.

À l'aide de IIS Manager, cliquez avec le bouton droit de la souris sur le fichier WinLogin.aspx, cliquez sur Propriétés, puis sur l'onglet Messages d'erreur personnalisés pour modifier les différentes erreurs 401 et affecter une redirection personnalisée. Malheureusement, cette redirection doit être un fichier statique et ne traitera pas une page ASP.NET. La solution que je propose est de rediriger ce fichier vers un fichier Redirect401.htm statique, avec le chemin physique complet, contenant du script Java ou une meta-balise, pour accéder enfin au formulaire d'ouverture de session ASP.NET réel, appelé WebLogin.aspx. Notez que, au cours de ces étapes, vous perdez le ReturnUrl d'origine, car la redirection d'erreurs IIS requérait un fichier html statique exempt d'éléments dynamiques. Nous aborderons ce problème ultérieurement.

mixedsecurity_fig02.gif

Figure 2. Redirection d'erreurs 401 vers une page d'erreurs personnalisée

Ouverture de session personnalisée à l'aide de formulaires

L'étape suivante consiste à créer l'écran d'ouverture de session d'authentification par formulaires, appelé WebLogin.aspx. L'interface utilisateur doit au minimum contenir des zones de texte permettant à l'utilisateur d'entrer son nom d'utilisateur et son mot de passe, ainsi qu'un bouton de soumission pour ouvrir la session. Vous pouvez cependant ajouter d'autres fonctionnalités d'ouverture de session. Vous aurez également besoin d'ajouter votre propre code d'authentification dans le gestionnaire d'événements du bouton d'ouverture de session, étant donné que j'ai opté pour exemple très simple se contentant de tester si le nom d'utilisateur et le mot de passe sont identiques. Vous pouvez en outre ajouter la gestion des rôles, qu'il s'agisse de vos propres rôles personnalisés ou de groupes Windows.

À ce stade, vous disposez d'un utilisateur authentifié et de son nom d'utilisateur. Vous pourriez simplement appeler FormsAuthentication.RedirectFromLoginPage pour vous connecter encore une fois à l'authentification par formulaires, mais cela ne fonctionne pas, car nous avons perdu le ReturnUrl d'origine. Vous devez donc définir séparément le cookie d'authentification, à l'aide de FormsAuthentication.SetAuthCookie, puis rediriger manuellement l'utilisateur vers le ReturnUrl d'origine, opération que nous allons bientôt aborder. À première vue, cela devrait marcher, mais en fait vous effectuez une nouvelle boucle vers WinLogin.aspx.

Pourquoi n'aboutissez-vous donc pas à votre page WebLogin.aspx ? Vous ne disposez pas encore des autorisations appropriées. Vous avez commencé par configurer votre authentification par formulaires pour qu'elle rejette les utilisateurs anonymes, ce qui permet judicieusement à ces utilisateurs d'accéder à loginUrl, mais il s'agit uniquement de WinLogin.aspx. Vous devez donc également autoriser explicitement WebLogin.aspx à autoriser les utilisateurs anonymes. Ce résultat est facilement obtenu grâce à l'utilisation d'une section de réadressage dans le fichier web.config, avec le chemin WebLogin.aspx. Le tour est joué : vous avez réussi à combiner les formulaires et la sécurité Windows dans ASP.NET.

Redirection vers l'URL d'origine

À présent, le dernier problème à régler est de suivre l'URL d'origine, afin que la redirection puisse s'effectuer correctement. Le module d'authentification par formulaires ajoute automatiquement une ReturnUrl querystring à WinLogin.aspx, mais la sécurité intégrée Windows empêche toute exécution de cette page par des utilisateurs autres que Windows. Ensuite, IIS vous oblige à rediriger ces utilisateurs vers un fichier html statique, ce qui a pour conséquence de perdre querystring. Au lieu de cela, vous devez donc suivre l'URL d'origine avec un système plus persistant, comme des cookies ou une session. Mais nous devons tout d'abord trouver un moyen de capturer l'URL d'origine pour l'enregistrer.

L'authentification par formulaires fonctionne grâce à un HttpModule qui intercepte et traite toutes les demandes, puis redirige les utilisateurs non authentifiés avant le chargement initial de la page demandée. Vous devez donc également vous connecter à la demande à un moment antérieur, comme dans global.asax, qui contient déjà un événement AuthenticateRequest que vous pouvez gérer pour capturer l'URL. Par conséquent, vérifiez simplement que la demande n'est pas authentifiée, puis définissez son chemin sur la valeur du cookie ReturnUrl que vous renverrez dans votre page WebLogin.aspx.

Cela semble logique, mais vous effectuez en fait une nouvelle boucle vers WebLogin.aspx et non vers l'URL d'origine. À ce stade, si vous effectuez un débogage, le problème est facilement mis en évidence : lorsque la demande WebLogin.aspx est effectuée, le cookie ReturnUrl est écrasé. Il vous suffit donc, dans ce cas, de ne pas modifier le cookie. Une autre situation peut se produire : l'utilisateur peut se rendre directement sur WebLogin.aspx, qui ne dispose plus du cookie ReturnUrl. Il vous suffit donc de vérifier et de gérer ce point supplémentaire. Vous avez finalement réussi à combiner les formulaires et la sécurité Windows, tout comme la redirection vers l'URL d'origine.

mixedsecurity_fig03.gif

Figure 3. Combinaison des formulaires et de la sécurité Windows dans ASP.NET

Conclusion

Penchons-nous un moment sur ce que nous venons de faire et pourquoi cela a semblé si compliqué. Le problème était de combiner les formulaires et la sécurité Windows. Les développeurs ont tendance à s'arrêter immédiatement aux détails techniques, c'est-à-dire qu'il est impossible de combiner différents types d'authentification. Mais peu importe aux utilisateurs le nombre de types d'authentification, alors, pourquoi s'en soucier ? Nous devons au contraire nous pencher sur ce que les utilisateurs veulent vraiment, à savoir, dans ce cas, simplement capturer leur nom d'utilisateur Windows, si cela est possible, et, sinon, être redirigés vers un écran d'ouverture de session.

À propos de l'auteur

Paul Wilson est un architecte de logiciels vivant à Atlanta et qui a récemment rejoint l'équipe de développement de PRG-Schultz. Son contrôle WilsonWebForm autorise l'utilisation de nombreux formulaires et des formulaires de non-renvoi dans ASP.NET. C'est un Microsoft Most Valuable Professional (ce qui signifie en français Participant le plus méritant) en ASP.NET, un modérateur des forums ASP.NET Microsoft, un Microsoft Certified Solution Developer (en français, Développeur de solutions certifié), un Microsoft Certified Application Developer (Développeur d'applications certifié), un Microsoft Certified Data Base Administrator (Administrateur de bases de données certifié) et un Microsoft Certified Systems Engineer (Ingénieur système certifié). Vous pouvez visiter son site Web sur http://www.wilsondotnet.com/ Lien externe au site MSDN France Site en anglaisou lui envoyer un courrier électronique à l'adresse Paul@WilsonDotNet.com Lien externe au site MSDN France Site en anglais.



Dernière mise à jour le mardi 6 avril 2004



Afficher:
© 2015 Microsoft