Authentification et autorisation ASP.NET – CodeProject – Bien choisir son serveur d impression

Cet article explique comment implémenter l'authentification et l'autorisation ASP.NET. Cet article commence par les concepts d'authentification et d'autorisation, puis explique les trois méthodes importantes d'authentification et d'autorisation, à savoir Windows, les formulaires et le passeport. Au fur et à mesure que l'article avance, il explique en détail l'authentification de base, digérée et intégrée. Cet article explique également comment utiliser l'authentification par formulaire pour implémenter l'authentification personnalisée et l'authentification par signature unique. L'un des concepts importants abordés dans cet article est la génération de tickets dans les cookies et la manière dont le rôle et le rôle d'ASP.NET peuvent nous aider à augmenter la productivité.

Ceci est un petit Ebook pour tous mes amis .NET qui couvre des sujets tels que WCF, WPF, WWF, Ajax, Core .NET, SQL, etc. Vous pouvez télécharger le même à partir de ici ou bien vous pouvez me prendre sur mon entraînement quotidien gratuit @ de ici

Avant de continuer, nous devons comprendre quatre vocabulaires importants que vous verrez dans cet article, encore et encore: – authentification, autorisation, principe et identité. Commençons d’abord par l’authentification et l’autorisation. Si vous recherchez sur le site Web www.google.com la signification de l’authentification et de l’autorisation dans le dictionnaire, vous arriverez à quelque chose en dessous: –

Authentification: – prouver l'authenticité

Autorisation: – processus d’approbation ou de permission sur les ressources.

La même signification de dictionnaire s’applique également à ASP.NET. En ASP.NET, l’authentification signifie identifier l’utilisateur ou, en d’autres termes, ne rien faire à part valider qu’il existe dans votre base de données et qu’il est le bon utilisateur.
L'autorisation signifie qu'il a accès à une ressource particulière sur le site Web d'IIS. Une ressource peut être une page Web ASP.NET, des fichiers multimédia (MP4, GIF, JPEG, etc.), un fichier compressé (ZIP, RAR), etc.
Donc, le premier processus qui se passe est l'authentification, puis l'autorisation. Vous trouverez ci-dessous une représentation graphique simple de l’authentification et de l’autorisation. Ainsi, lorsque l'utilisateur entre "ID utilisateur" et "Mot de passe", il est d'abord authentifié et identifié par le nom d'utilisateur.
Désormais, lorsque l'utilisateur commence à accéder aux ressources telles que les pages, l'authentification ASPDOTNET, les vidéos, etc., il est vérifié s'il dispose de l'accès nécessaire aux ressources. Le processus d’identification des droits sur les ressources est appelé «autorisation».

En termes simples, identifier «il est shiv» est une authentification et identifier que «Shiv est admin» est une autorisation.

À tout moment, si vous souhaitez savoir qui est l'utilisateur et quel type d'authentification il utilise, vous pouvez utiliser l'objet d'identité. Si vous voulez savoir à quel type de rôles il est associé, vous devez utiliser l’objet principal. En d'autres termes, pour obtenir les détails de l'authentification, nous avons besoin de l'objet d'identité et pour connaître les détails de l'autorisation de cette identité, nous avons besoin de l'objet principal.

Par exemple, ci-dessous est un exemple de code simple qui montre comment utiliser une identité et un objet principal pour afficher le nom et vérifier les rôles.

Response.Write (User.Identity.Name + "
");
Response.Write (User.Identity.AuthenticationType + "
");
Response.Write (User.Identity.IsAuthenticated + "
");
Response.Write (User.IsInRole ("Administrators") + "
"); 

Maintenant, si vous exécutez ce code dans IIS en mode anonyme, il n’affiche aucun détail, comme indiqué ci-dessous.

Si vous exécutez le code ci-dessus dans IIS en utilisant un mode d'authentification tel que celui présenté ci-dessous «Authentification de base», tous les détails s'affichent comme indiqué ci-dessous.

Il y a trois façons de faire authentification et autorisation dans ASP.NET:
• Authentification Windows: – Dans cette méthodologie, les pages Web ASP.NET utiliseront des utilisateurs et des groupes de fenêtres locales pour authentifier et autoriser des ressources.

• Authentification par formulaire: – Il s’agit d’une authentification basée sur un cookie. Le nom d’utilisateur et le mot de passe sont stockés sur les ordinateurs clients sous forme de fichiers cookie ou sont envoyés via une URL pour chaque requête. L'authentification basée sur un formulaire présente à l'utilisateur une page Web HTML qui lui demande ses informations d'identification.

• Authentification par passeport: – L'authentification par passeport est basée sur le site Web du passeport fourni
par Microsoft. Ainsi, lorsque l’utilisateur se connecte avec ses identifiants, il sera atteint par le site Web du passeport (par exemple, hotmail, devhood, Windows Live, etc.) où l’authentification sera effectuée. Si l'authentification réussit, un jeton sera renvoyé sur votre site Web.

• Accès anonyme: – Si vous ne voulez aucune sorte d'authentification, alors vous opterez pour un accès anonyme.

Les objets GenericPrincipal et GenericIdentity représentent les utilisateurs authentifiés à l'aide de l'authentification par formulaire ou d'autres mécanismes d'authentification personnalisés. Avec ces objets, la liste de rôles est obtenue de manière personnalisée, généralement à partir d'une base de données.
Les objets FormsIdentity et PassportIdentity représentent les utilisateurs authentifiés respectivement avec les authentifications Forms et Passport.

Lorsque vous configurez votre application ASP.NET en tant qu'authentification Windows, elle utilisera des utilisateurs et des groupes Windows locaux pour l'authentification et l'autorisation de vos pages ASP.NET. Vous trouverez ci-dessous un cliché simple qui montre les utilisateurs et les rôles Windows sur mon ordinateur.

Nous allons faire un petit exemple pour comprendre comment l’authentification et l’autorisation fonctionnent avec Windows. Nous allons créer 2 utilisateurs, un administrateur et un autre utilisateur simple nommé Shiv. Nous allons créer deux pages ASPX simples, une page ‘User.aspx’ et une page ‘Admin.aspx’. L’utilisateur «Administrateur» aura accès aux pages «Admin.aspx» et «User.aspx», tandis que l’utilisateur «Shiv» n’aura accès qu’à la page «User.aspx».

Étape 1: – Création du site web.

L'étape suivante consiste à créer un site Web simple comportant 3 pages (User.aspx, Admin.aspx et Home.aspx), comme indiqué ci-dessous.

Étape 2: – Créer un utilisateur dans le répertoire Windows

La prochaine étape consiste à accéder au répertoire Windows et à créer deux utilisateurs. Vous pouvez voir sur mon ordinateur que nous avons «Administrateur» et «Shiv».

Étape 3: – Configurez le fichier ‘web.config’

Dans le fichier ‘web.config’, définissez le mode d’authentification sur ‘Windows’ comme indiqué dans les extraits de code ci-dessous.

Nous devons également nous assurer que tous les utilisateurs sont refusés, à l'exception des utilisateurs autorisés. L'extrait de code ci-dessous à l'intérieur de la balise d'autorisation interdit à tous les utilisateurs. «?» Indique tout

Utilisateur inconnu.

Étape 4: – Autorisation d'installation
Nous devons également spécifier la partie autorisation. Nous devons insérer l’extrait ci-dessous dans le fichier ‘web.config’ en indiquant que seuls les utilisateurs ‘Administrateur’ auront accès à

‘Admin.aspx’.

Étape 5: -Configurer les paramètres IIS
L'étape suivante consiste à compiler le projet et à le télécharger dans un répertoire virtuel IIS. Sur le répertoire virtuel IIS, nous devons nous assurer de supprimer les accès anonymes et de vérifier l'authentification Windows intégrée, comme indiqué dans la figure ci-dessous.

Maintenant, si vous exécutez l’application Web, vous obtiendrez une zone d’identifiant et de mot de passe, comme indiqué ci-dessous.

Une fois que vous avez entré vos identifiants, vous devriez pouvoir voir home.aspx comme indiqué ci-dessous.

Si vous n’êtes pas administrateur (c’est-à-dire, dans ce cas, son "shiv") et que vous accédez à "Admin.aspx", une erreur sera générée, comme indiqué dans la figure ci-dessous.

Si vous souhaitez savoir qui est l’utilisateur et avec quels droits d’autorisation il s’est connecté, vous pouvez utiliser ‘WindowsPrincipal’ et ‘WindowsIdentity’. Ces deux objets représentent les utilisateurs authentifiés avec l'authentification Windows. Vous pouvez également obtenir les rôles de ces utilisateurs.

Dans l'article ci-dessus, étape par étape, vous devez avoir remarqué les options ci-dessous sur IIS (Integrated, Digest et Basic). Ces trois cases à cocher décident de la manière dont les informations d'identification du nom d'utilisateur et du mot de passe Windows sont transmises du bureau du client à IIS.
Il existe trois manières différentes de transmettre le nom d'utilisateur et le mot de passe Windows à IIS: –
• basique
• digérer
• Les fenêtres
Lors de la prochaine session, nous comprendrons en profondeur ces 3 options.

Lorsque l’authentification de base est sélectionnée, les "identifiants" et "mot de passe" sont transmis au format codé Base64. c'est-à-dire pourquoi le nom est une authentification de base. ‘Base64’ est un encodage et non un cryptage. Il est donc très facile de craquer. Vous pouvez en savoir plus sur le codage ‘Base64’ à l’adresse http://en.wikipedia.org/wiki/Base64. C'est une forme de protection très faible.

Vous trouverez ci-dessous une petite démonstration de la facilité avec laquelle une authentification de base est déchiffrée. Vous pouvez voir dans la figure ci-dessous que nous avons vérifié la vérification ‘Basicauthentication’ et que nous avons exécuté l’outil fiddler pour afficher les données.

Nous avons ensuite copié les données ‘Authorization: Basic’ et exécuté le programme ci-dessous. LOL, nous pouvons voir notre userid Windows et mot de passe.

Vous trouverez ci-dessous un extrait de code expliquant comment décoder le codage ‘Base64’.

chaîne publique statique DecodeFrom64 (string encodedData)


octet[] encodedDataAsBytes = System.Convert.FromBase64String (encodedData);

string returnValue = System.Text.Encoding.ASCII.GetString (encodedDataAsBytes);

return returnValue;

L’authentification de base, autrement dit le codage ‘Base64’, est utilisé pour transmettre des données binaires et les convertir en texte afin qu’elles puissent être exécutées sur le réseau. Certains protocoles peuvent interpréter vos données binaires comme des caractères de contrôle. Par exemple, le protocole FTP pour certaines combinaisons de caractères binaires peut interpréter de la même manière que les fins de lignes FTP.

À la fin des jours, ce n’est pas un algorithme de chiffrement, c’est un mécanisme de codage. C’est pourquoi, dans notre section précédente, nous avons montré à quel point il était facile de décoder l’authentification de base.

Le problème associé à l'authentification de base est résolu en utilisant l'authentification Digest. Nous avons vu dans notre section précédente à quel point il était facile de déchiffrer l'authentification de base. L'authentification Digest transfère les données sur le réseau sous forme de hachage MD5 ou de résumé de message. Ce hachage ou digestion est difficile à déchiffrer.
En d’autres termes, l’authentification Digest remplace l’authentification de base boiteuse.

L’un des gros problèmes de l’authentification Digest est qu’il n’est pas supporté par certains navigateurs.

L'authentification Windows intégrée (anciennement appelée NTLM et également appelée authentification Challenge / Réponse de Windows NT) utilise l'authentification Kerberos v5 ou l'authentification NTLM, selon la configuration du client et du serveur.
(Le paragraphe ci-dessus est extrait de http://msdn.microsoft.com/en-us/library/ff647076.aspx).
Essayons de comprendre en quoi consistent l’authentification NTLM et Kerberos, puis nous tenterons de comprendre d’autres aspects de l’authentification intégrée.
NTLM est un protocole d'authentification par réponse. Voici comment se déroule la séquence d'événements: –
• Le client envoie le nom d'utilisateur et le mot de passe au serveur.
• Le serveur envoie un défi.
• Le client répond au défi avec un résultat de 24 octets.
• Les serveurs vérifient si la réponse est correctement calculée en contactant le contrôleur de domaine.
• Si tout est correct, la demande est acceptée.

Kerberos est un traqueur multiple (3 têtes) qui garde les portes des hades. De la même manière, la sécurité Kerberos compte 3 participants authentifiant le service, le serveur de services et le serveur d'octroi de tickets. Essayons de comprendre, étape par étape, comment ces 3 entités participent pour assurer la sécurité.

Courtesy: – http://24-timepass.com/postimg/three-headed-dog.jpg
Kerberos utilise une clé symétrique pour l'authentification et l'autorisation. Voici comment ça marche pour Kerberos: –

• À l'étape 1, le client envoie le nom d'utilisateur et le mot de passe à AS (authentification du service).
• AS authentifie l'utilisateur et s'assure qu'il est un utilisateur authentifié.
• AS demande ensuite au TGT (service d'octroi de ticket) de créer un ticket pour l'utilisateur.
• Ce ticket sera utilisé pour vérifier si l'utilisateur est authentifié ou non. En d'autres termes, lors d'une interaction client ultérieure, aucun mot de passe ne sera envoyé pendant l'interaction.

Une des choses que vous avez sûrement remarquées, c’est que les cases à cocher sont une authentification intégrée, une digestion et une authentification de base. En d'autres termes, nous pouvons vérifier les trois en même temps. Si vous cochez toutes les 3 options en même temps, en fonction de la sécurité du navigateur, l’une des méthodes ci-dessus aura la priorité.

Voyons comment la priorité de sécurité fonctionne comme pour la sécurité du navigateur.
• le navigateur fait une demande; il envoie la première demande en tant qu'Anonyme. En d'autres termes, il n'envoie aucune information d'identification.

• Si le serveur n'accepte pas Anonymous, IIS répond par un message d'erreur "Accès refusé" et envoie une liste des types d'authentification pris en charge par le navigateur.

• Si Windows NT Challenge / Response est la seule méthode prise en charge, le navigateur doit la prendre en charge pour communiquer avec le serveur. Sinon, il ne peut pas négocier avec le serveur et l'utilisateur reçoit un message d'erreur "Accès refusé".

• Si la méthode de base est la seule prise en charge, une boîte de dialogue apparaît dans le navigateur pour obtenir les informations d'identification, puis les transmet au serveur. Il tente d'envoyer ces informations d'identification jusqu'à trois fois. Si tout cela échoue, le navigateur n'est pas connecté au serveur.

• Si Challenge / Réponse de base et Windows NT sont pris en charge, le navigateur détermine la méthode utilisée. Si le navigateur prend en charge Challenge / Réponse Windows NT, il utilise cette méthode et ne revient pas à la version standard. Si Windows NT Challenge / Response n'est pas pris en charge, le navigateur utilise Basic.
Vous pouvez en savoir plus sur la priorité à l’adresse http://support.microsoft.com/kb/264921.

Dans les mots d'ordre, la priorité est: –

1. Défi Windows NT (sécurité intégrée)
2. Digest
3. de base

L'authentification par formulaire est une authentification basée sur un cookie / URL où le nom d'utilisateur et le mot de passe sont stockés sur les ordinateurs clients sous forme de fichiers de cookie ou cryptés sur l'URL pour chaque demande si les cookies ne sont pas pris en charge.
Vous trouverez ci-dessous les différentes étapes de l’authentification des formulaires: –
• Étape 1:- L'utilisateur entre "ID utilisateur" et "mot de passe" via un écran de connexion personnalisé développé pour l'authentification et l'autorisation.

• Étape 2:- Une vérification est faite pour s'assurer que l'utilisateur est valide. L’utilisateur peut être validé à partir de fichiers ‘web.config’, de SQL Server, de la base de données client, de Windows Active Directory et de divers autres types de sources de données.

• Étape 3:- Si l'utilisateur est valide, un fichier texte de cookie est généré sur le client. Ce fichier de test de cookie signifie que l'utilisateur a été authentifié. Dès lors, lorsque l'ordinateur client navigue sur d'autres ressources de votre site ASP.NET, la validation n'est pas effectuée à nouveau. Le fichier de cookie indique que l'utilisateur s'est connecté.

Alors, expliquons pas à pas comment configurer l’authentification des formulaires. Comme indiqué dans les sections précédentes, vous pouvez stocker l’utilisateur dans des fichiers ‘web.config’. Ce n'est certainement pas la meilleure façon de stocker l'utilisateur dans des fichiers «web.config», mais cela nous aidera vraiment à comprendre l'authentification par formulaires. Une fois que nous comprenons la même chose, nous pouvons passer à de meilleures versions improvisées de l’authentification des formulaires.

Étape 1:- La première chose à faire est de créer une entrée dans le fichier web.config avec le mode d’authentification tel que présenté ci-dessous. Nous devons également fournir les éléments suivants: –

• LoginUrl: – Cette propriété nous aide à fournir la page de démarrage de l'authentification et de l'autorisation.

• defaultUrl: – Une fois que l'utilisateur est validé, il sera redirigé vers cette valeur, actuellement son “Home.aspx”.

• Sans cookie: – Comme indiqué précédemment, l'authentification par formulaires utilise des cookies. Vous pouvez modifier ce comportement de quatre manières: –

oAutoDetect: – En fonction de la configuration de votre navigateur, il peut utiliser des cookies ou transmettre les informations d'authentification cryptées via l'URL du navigateur.

o UseCookies: – Vous voudriez que le mécanisme d'authentification par formulaires crée un cookie lorsque l'authentification est réussie.

o UseURI: – Vous souhaitez transmettre des données chiffrées via la chaîne de requête d'URL du navigateur.

o UseDeviceProfile: – C'est la valeur par défaut. Lorsque vous définissez cette valeur, le mécanisme d’authentification des formulaires recherchera
«C: WINDOWS Microsoft.NET Framework v2.0.50727 CONFIG Navigateurs» pour voir si le navigateur prend en charge les cookies et décide ensuite s’il doit ou non utiliser les cookies. En d'autres termes, il ne vérifie pas au moment de l'exécution réelle si les cookies sont activés dans le navigateur.

• Informations d'identification: – Dans la balise d'informations d'identification, nous avons également des utilisateurs avec nom et mot de passe. Comme indiqué précédemment, nous utiliserons d’abord l’authentification par formulaire avec le nom d’utilisateur stocké dans les fichiers web.config.

Différentes valeurs de personnalisation pour la propriété "cookieless".

Si vous définissez le cookieless comme ‘UseDeviceProfile’, il utilisera les données du navigateur du fichier ci-dessous. Vous pouvez voir comment le navigateur Ericsson ne prend pas en charge les cookies. Par conséquent, si vous vous connectez avec le navigateur ericsson et que la valeur est ‘UseDeviceProfile’, l’authentification par formulaire transmettra les données à travers les chaînes de requête.

Étape 2:- Une fois que vous avez défini les valeurs de la balise «forms», il est temps de vous assurer que les utilisateurs anonymes ne pourront pas naviguer sur votre site. Vous pouvez définir la même chose en utilisant la balise d'autorisation, comme indiqué dans l'extrait de code ci-dessous.

Étape 3:- Nous devons également définir quel utilisateur a accès à quelle page. Dans ce projet, nous avons créé deux pages “Admin.aspx” et “User.aspx”. «Admin.aspx» est accessible uniquement à l'utilisateur «Shiv», tandis que «Admin.aspx» et «User.aspx» sont accessibles aux deux utilisateurs.

Les paramètres web.config ci-dessous montrent comment définir l'utilisateur sur les pages.

Étape 4 :- Nous créons maintenant notre page personnalisée qui acceptera l’identifiant et le mot de passe.

Dans le bouton cliquez, nous fournissons le code ci-dessous. «FormsAuthentication.Authenticate» recherche dans le fichier Web.config le nom d'utilisateur et les mots de passe. Le «FormsAuthentication.RedirectFromLoginPage» crée des cookies à la fin du navigateur.

Si vous exécutez votre application, entrez les informations d'identification appropriées. Vous devriez pouvoir voir un fichier txt cookie créé comme indiqué dans la figure ci-dessous.

Si vous désactivez les cookies à l'aide des paramètres du navigateur, les informations d'identification seront transmises via une chaîne de requête, comme indiqué dans la figure ci-dessous.

Pour effectuer une authentification personnalisée, vous devez simplement remplacer la déclaration «FormsAuthentication.Authenticate» par votre validation. Par exemple, dans le code ci-dessous, nous avons utilisé la classe ‘clsUser’ pour effectuer l’authentification, mais nous avons encore utilisé le mécanisme de création de cookies fourni par le système ‘FormAuthentication’.

clsUser objUser = new clsUser ();
if (objUser.IsValid (txtUser.Text, txtPass.Text))

FormsAuthentication.RedirectFromLoginPage (txtUser.Text, true);

Nous avons utilisé un mécanisme d’authentification des formulaires pour générer des cookies, ce qui a largement minimisé nos efforts de développement. De nombreuses autres tâches que nous effectuons toujours, telles que: –
• Création de tables d'utilisateurs et de rôles.
• Implémentation au niveau du code pour la maintenance de ces tables.
• Interface utilisateur pour l’identifiant et le mot de passe.

Nous sommes sûrs que vous avez dû effectuer la tâche ci-dessus pour chaque projet encore et encore. Bonnes nouvelles!!! Toutes les choses ci-dessus sont maintenant simplifiées avec l'introduction de la composition et des rôles. Pour mettre en œuvre l'appartenance à ASP.NET et les rôles, nous devons suivre les étapes suivantes: –

• Exécutez aspnet_regsql.exe à partir du dossier ‘C: WINDOWS Microsoft.NET Framework v2.0.50727’. Entrez les informations d'identification SQL Server et exécutez le fichier exe. Ceci installera toutes les procédures stockées et les tables nécessaires, comme indiqué dans la figure ‘Objet créé par aspnet_regsql.exe’.

• Spécifiez la chaîne de connexion dans le fichier ‘web.config’ dans lequel vos tables de rôles ASP.NET et vos procédures stockées sont créées.

• Spécifiez le fournisseur d'appartenance ASP.NET et connectez-le avec la chaîne de connexion fournie à l'étape précédente.

• Nous devons également spécifier le fournisseur de rôle et le connecter avec la chaîne de connexion fournie lors de la session précédente.

Vous pouvez maintenant utiliser la classe «Appartenance» pour créer des utilisateurs et des rôles, comme indiqué dans les 2 illustrations ci-dessous.

Vous pouvez avoir une idée de la facilité d'utilisation de développer l'authentification et l'autorisation en utilisant l'authentification par formulaires
et appartenance à ASP.NET et rôles.

L'authentification et l'autorisation dans n'importe quelle application nécessite 2 choses: –
• Mécanisme permettant de générer un cookie: – Fourni par authentification par formulaire.

• Tables personnalisées dans SQL Server pour stocker les utilisateurs et les rôles: – Fournies par le fournisseur ASP.NET et les rôles.

En d’autres termes, en utilisant la combinaison de la génération de tickets via l’authentification de formulaires, le fournisseur ASP.NET et les rôles, nous pouvons proposer une solution simple et rapide pour implémenter l’authentification et l’autorisation dans les applications ASP.NET.

Nous aimerions souvent mettre en œuvre l'authentification unique sur plusieurs sites. Cela peut être fait en utilisant l'authentification par formulaires. Vous pouvez implémenter l'authentification par formulaires dans les deux sites Web avec la même clé d'ordinateur. Une fois la validation effectuée sur un site Web, un fichier texte de cookie sera créé. Lorsque cet utilisateur se rend sur un autre site Web, le même fichier de cookies est utilisé pour s'assurer que l'utilisateur est correct ou non.
Veuillez noter que vous devez avoir la même clé d'ordinateur dans les deux fichiers web.config de votre application Web.

Vous pouvez consulter un article très détaillé sur Single Sign à l'adresse http://msdn.microsoft.com/en-us/library/ms972971.aspx. Vous pouvez également télécharger le code à partir de http://download.microsoft.com/download/B/7/8/B78D1CED-2275-4AEE-B0BE-0DEA1A2A9581/MSDNEnterpriseSecurity.msi
Ce qui précède explique comment un intranet interne et une application Internet se connectent via une installation d’authentification unique.

Le diagramme ci-dessus est tiré de http://msdn.microsoft.com/en-us/library/ms972971.aspx

L’authentification du passeport est basée sur le site Web du passeport fourni par Microsoft. Ainsi, lorsque l’utilisateur se connecte avec les informations d’identité, il sera atteint sur le site Web du passeport (par exemple, hotmail, dévhood, Windows Live, etc.) où l’authentification sera effectuée. Si l'authentification réussit, un jeton sera renvoyé sur votre site Web.
Je quitte cette section pour le moment, je mettrai à jour cette information plus en détail prochainement

Vous pouvez télécharger le code source de ce tutoriel à partir de ici

Authentification unique dans le sous-domaine SingleSignon.aspx

Excellente référence sur différents mécanismes d'authentification

http://msdn.microsoft.com/en-us/library/ee817643.aspx

Article MSDN qui explique comment effectuer l'authentification par formulaire http://support.microsoft.com/kb/301240

Article MSND qui explique l'identité et les principaux objets http://msdn.microsoft.com/en-us/library/ftx85f8x(v=VS.85).aspx

La page Modèles et pratiques qui fournit un tableau illustrant la plage des paramètres d'authentification IIS. http://msdn.microsoft.com/en-us/library/ff649264.aspx

Ordre de priorité pour l'authentification Windows, l'authentification de base et l'authentification Digest http://support.microsoft.com/kb/264921

Bel article sur l'authentification des formulaires qui va en profondeur http://www.4guysfromrolla.com/webtech/110701-1.shtml

Authentification des formulaires expliquée avec de beaux diagrammes de séquence http://www.asp.net/security/tutorials/an-overview-of-forms-authentication-vb

Beau PDF des meilleures pratiques pour l’authentification des formulaires http://www.foundstone.com/us/resources/whitepapers/aspnetformsauthentication.pdf