Identité ASP.NET + Authentification Windows (mode Mix - Formulaires + Windows)
J'ai fait de mon mieux pour effectuer une recherche sur le Web avant de poser cette question. J'ai vu des questions similaires sur stackoverflow, mais aucune réponse satisfaisante n'a été formulée depuis longtemps. C’est une autre tentative pour obtenir une réponse à cette question récurrente.
Le problème
Comment créer un site Web ASP.NET MVC 5 qui utilise "Auth Windows" pour les utilisateurs Intranet et "Autorisation des formulaires" pour les utilisateurs Internet? Nous aimerions accomplir cela en utilisant ASP.NET Identity. De plus, nous ne souhaitons pas utiliser les groupes Active Directory pour les autorisations. Pour les utilisateurs Intranet, nous voulons les authentifier à l'aide d'Active Directory, puis nous nous tournons vers ASP.NET Identity pour gérer leurs rôles et autres données de profil.
Ce sera bien si nous ne demandons pas à l'utilisateur final de choisir la méthode d'authentification. L'application Web doit connecter les utilisateurs de l'intranet de manière transparente. Ils ne devraient même pas savoir qu'il existe un écran de connexion. De même, les utilisateurs Internet ne devraient pas être invités à entrer leurs identifiants de domaine. Ils devraient voir immédiatement l'écran de connexion basé sur un formulaire.
Existe-t-il un moyen recommandé de résoudre ce problème? Ou pourriez-vous nous dire si l’une des solutions suivantes est appropriée?
_ { http://world.episerver.com/blogs/Dan-Matthews/Dates/2014/8/Mixing-Forms-and-Windows-Authentication/
_ { https://github.com/MohammadYounes/MVC5-MixedAuth } _
FYI Ceci est un article de 2004, peut-être pas utile maintenant: https://msdn.Microsoft.com/en-us/library/ms972958.aspx }
Configuration de IIS
Activez le statut de l’authentification anonyme dans IIS pour l’ensemble du site et l’authentification Windows pour certains dossiers du répertoire racine (par exemple,/WindowsLogin). Dans ce dossier, placez le fichier aspx (pour le projet WebForms) ou créez ApiController (pour le projet MVC).
Configuration du site
Sur la page de connexion, ajoutez le bouton “Connexion avec un compte Windows/ActiveDirectory” (de la même manière qu'il est d'usage d'ajouter des boutons Connexion avec Twitter, Facebook, Gmail, etc.). Lorsque l'utilisateur appuie sur ce bouton, il est redirigé vers la page ou le contrôleur du dossier/WindowsLogin, qui nécessite une authentification Windows. Si le site utilise des fonctionnalités d'authentification unique, localisez-les dans cette page ou ce contrôleur. Dans le cas contraire, sauvegardez-y uniquement les utilisateurs de Session pour Windows. Si l'utilisateur a accédé à cette page ou à ce contrôleur, il avait déjà été authentifié en tant qu'utilisateur Windows.
L’un des moyens possibles pourrait être de créer deux sites dans IIS, mais en ayant le même dossier cible, où se trouvent les sources du site. Le premier site est destiné aux utilisateurs internes avec le mode d'authentification Windows activé et la liaison au port 80, tandis que le second site est destiné aux utilisateurs externes avec le mode anonyme activé et la liaison au port 8080, par exemple. Ensuite, sur le pare-feu, vous devrez configurer NAT, afin que toutes les demandes provenant du réseau local ou du VPN soient redirigées vers le serveur local IIS sur le port 80 et toutes les demandes provenant d’Internet soient redirigées vers le port 8080 de IIS serveur.
Le terme utilisé pour cela est l'authentification en mode mixte. Je l'ai fait plusieurs fois. Vous devez seulement modifier votre site principal. Voici comment je l'ai fait.
Conservez votre site principal MVC tel quel, mais exécutez-le en tant que anonyme ou sous Windows Auth.
Site interne
Créez un site d’URL de redirection: Configurez ce site en tant qu’authentification de la fenêtre pour extraire l’ID utilisateur à partir d’Active Directory. Donnez à vos utilisateurs cette URL et/ou faites-leur le lien sur lequel ils cliquent sur votre intranet. Ensuite, ce site appelle votre site MVC et transmet les informations d'identification de l'utilisateur (identifiant de connexion).
une. Cela peut être effectué via une chaîne chiffrée sur l'URL ou une valeur chiffrée dans un cookie. Vous pouvez également chiffrer avec une valeur de date/heure d'expiration.
b. (À partir de l'authentification des formulaires) Créez un ticket d'authentification de formulaires avec cet ID utilisateur. Exécutez toute autre logique de connexion que vous avez. Terminé.
Site externe - Aucune modification requise. Permet aux utilisateurs de se connecter tels quels.
J'ai fait une preuve de concept de cela il y a quelque temps, lors de mon précédent travail, donc les détails sont flous et je n'ai pas de code auquel me référer ...
Les exigences étaient:
- URL unique pour accès interne (LAN) et externe (Internet)
- Deux types d'utilisateurs, les utilisateurs du domaine et les utilisateurs externes (non-AD)
- Authentification Windows pour les utilisateurs du domaine à la fois en interne et en externe
- La possibilité d'entrer des détails de connexion de domaine lors de l'utilisation d'iPad (pas d'authentification Windows)
L'idée de base de la solution que j'ai proposée est que nous avons utilisé la stratégie de groupe Active Directory pour ajouter une chaîne personnalisée à l'agent d'utilisateur d'en-tête de requête http. Le contenu importe peu. En fait, nous avons utilisé une longue chaîne de caractères aléatoire.
https://technet.Microsoft.com/en-us/library/cc770379.aspx
Ensuite, la page d'arrivée du site vérifie si cela se produit et, le cas échéant, redirige vers un répertoire virtuel, avec l'authentification de Windows, vérifiant si leur compte AD a rempli le jeton d'authentification ASP.NET, puis les a redirigés vers leur page d'accueil.
Si l'en-tête personnalisé n'est pas là, il affiche simplement le formulaire de connexion normal.
La seule autre chose à faire était d’ajouter une vérification AD adresse email/mot de passe au formulaire de connexion normal afin que, si un utilisateur du domaine accédait au site à partir d’un périphérique non-Windows (iPad), il pouvait utiliser ses informations de connexion habituelles.
Voulez-vous gérer les formulaires et l'authentification AD à partir d'une URL? J'ai utilisé thinktecture (revendications basées sur l'auth) comme cadre pour WIF et marshaling diverses formes d'authentification. Cependant, pour gérer si, à partir d'une URL, je devais gérer une certaine logique lors de la connexion qui associait l'utilisateur à AD ou à des formulaires. Dans un projet plus récent, cela était géré par la gestion des utilisateurs lorsque nous avons créé le compte d'utilisateur (il était associé à l'ANNONCE de l'authentification des formulaires). Ensuite, lors de la connexion de l’utilisateur, il préfacerait le nom de domaine AD dans le cadre de la connexion. Il y a un certain nombre de façons de mettre cela en œuvre, c’est juste celui que j’ai utilisé. Un exemple, au lieu d’exiger le domaine, utilisez simplement le nom d’utilisateur, puis recherchez des indicateurs AD ou basés sur des formulaires sur le nom d’utilisateur, puis gérez l’authentification en conséquence.
EDIT Juste une mise à jour en relisant votre question. Les internautes et les intranet sont-ils les mêmes? Si tel est le cas, vous devez vous contenter d'une authentification basée sur des formulaires et gérer les utilisateurs de la base de données du produit indépendamment de AD. S'ils sont identiques, ils peuvent se connecter avant le nom de domaine au nom d'utilisateur. si vous vouliez compter uniquement sur AD.
Pourquoi ne pas mettre le code de votre site Web sur le serveur, le copier sur deux sites Web distincts et gérer les changements d’authentification en configurant le fichier web.config. (l'un serait configuré avec une authentification anonyme et l'autre avec une authentification Windows.)
Ce n'est pas aussi élégant que d'autres méthodes, mais c'est relativement indolore. Il y a deux sites mais le contenu (à l'exception de web.config) est identique.