IIS7 l'Authentification en Mode Mixte

Nous sommes prêts à commencer la migration de certains de nos IIS6 sites de IIS7, et l'application utilise l'Authentification par Formulaires. Nous avons commencé à recevoir les demandes des différents sites pour l'utilisation de l'Authentification Windows pour les utilisateurs. Alors que c'est assez facile à mettre en œuvre (et j'ai montré à l'interne qu'il n'y a pas de problème avec l'application, comme prévu) la question est alors de savoir comment continuer à garder l'authentification de Formulaires pour quand Intégrée de Windows ne fonctionne pas. J'ai vu plusieurs procédures pas à pas sur la façon de l'avoir configurée sur IIS6, et je pourrais faire la même chose sur IIS7, mais puis-je activer le Mode Classique de traitement. Toute solution devrait également être de retour portable à IIS6, si possible, de garder l'arbre de construction simple.

Alors, quelles sont mes options? Puis-je configurer l'application avec l'Authentification Windows Intégrée dans IIS7, les Formes Auth dans le web.config, et de rediriger les erreurs 401 à une "page d'erreur" leur permettant de se connecter en utilisant les formulaires, puis retour à la régulière app?

Le cas où des Formes est susceptible d'être nécessaire va être réservés pour les travailleurs à Contrat, notre personnel de soutien, et si quelqu'un a besoin d'accéder sur leur site à partir de leur Extranet. Donc, essentiellement, c'est pour notre personnel pour vous connecter à vérifier la fonctionnalité et à confirmer les rapports de bug. Je propose de nous maintenir juste que pour notre personnel de soutien à travailler, nous avons besoin d'un login Windows qui va toujours en live, et puis nous allons appliquer local responsabilité qui peut se connecter sur le site, mais je me suis dit que nous ferions mieux d'avoir des Formes d'Authentification.

Toute pensée? Je peux poster les liens des articles que j'ai déjà lu, si cela peut aider le forum mieux étroite mes besoins.

tl;dr: Comment faire de l'authentification en mode mixte (formes, windows) dans IIS7 sans changer de classique pipeline et être encore capable d'utiliser l'accumulation dans IIS6 si possible.

Serait-il préférable (à la stackoverflow.com/questions/2432845/... ) pour avoir deux "projets" sous ma génération principal qui sont strictement pour la délivrance de machine spécifique des cookies par le Web.config MachineKey et, ainsi, de conserver les mécanismes d'authentification distincte de l'app de l'utilisation et de conserver les Formes sur l'application principale? Que pourrait être la route la plus facile à prendre.
Sans doute j'ai besoin de faire quelque chose comme ceci: 15seconds.com/Issue/050203.htm mais qui semble tellement barbare quand il pourrait résider sous une pile.
Aussi, pour tous ceux qui lisent ce après que j'ai posté la question d'origine et quelques réponses: Si l'utilisateur navigue sur le site et ne PAS entrer leurs informations d'identification pour la réponse 401-ils obtenir des coups de pied à un ASP.NET par défaut 401 page d'erreur. Je n'ai pas compris comment faire pour rediriger à ce point de mes formulaires de la page par défaut (mais peut-être que j'ai arrêté de regarder trop tôt?)

OriginalL'auteur jcolebrand | 2010-03-29

Non, ce n'est pas tout à fait raison, mais je ne peux pas faire un bloc de code dans un commentaire de réponse, donc je vais poster une nouvelle réponse ...

Le bloc de code suivant me permet de contrôler anon accès de IIS7 sans avoir à bricolons dans la métabase (où les changements d'interface graphique sur IIS6 appliquée)

<location path="WindowsLogin.aspx" >
    <system.web>
        <authorization>
            <deny users="?" />
            <allow users="*" />
        </authorization>
    </system.web>
    <system.webServer>
        <security>
            <authentication>
                <anonymousAuthentication enabled="false" />
                <windowsAuthentication enabled="true" />
            </authentication>
        </security>
    </system.webServer>
</location>

Non pas que je suis en train d'insinuer que IIS7 a une métabase à l'esprit que vous...

OriginalL'auteur jcolebrand

2

merci pour en revenir à moi, j'ai été tour de jeu avec plusieurs implémentations sur et en dehors depuis quelques semaines maintenant, que j'ai lu sur internet (javascript, 401, 2 répertoires virtuels), mais encore havnt vraiment trouvé quelque chose qui fonctionne comme je le voulais. Nous seront potentiellement s'étendre à plus d'un client avec différents matériels/configurations, même les différentes versions de iis, donc il voulait être aussi générique que possible. Ive viennent contre un mur de briques sur un couple de suggestions de solutions...

quand vous dites pour IIS7+ vous avez supprimé anon accès au web de config, je suppose comme ceci: -
```
<location path="Authent/WinLogin.aspx" > 
  <system.webServer>
    <security>
      <authorization>
        <add accessType="Deny" users="?" />
      </authorization>
    </security>
  </system.webServer>
</location>
```
Non, ce n'est pas tout à fait raison, mais je ne peux pas faire un bloc de code dans un commentaire de réponse, donc je vais poster une nouvelle réponse ...

OriginalL'auteur kmoo01
1

J'ai passé quelques jours à essayer d'obtenir ce travail, avec une légère différence... je voulais que le premier écran de connexion de présenter les formulaires de connexion avec un bouton en dessous de "se connecter Avec l'Authentification Windows".

J'ai finalement renoncé à toutes ces techniques, que je n'ai jamais pu tout à fait obtenir des résultats satisfaisants. Ma solution a été comme suit, et fonctionne parfaitement:
- Créer un site web distinct "LoginWithIntegratedSecurity"
- Avec la sécurité intégrée
- Ce site web crée un temporaire "Utilisateur Clé de Hachage" dans la base de données, qui permet d'identifier l'utilisateur
- Renvoie à LogonPage dans les Formulaires d'Authentification de site web avec de Hachage de la clé dans l'url
- LogonPage dans les Formulaires d'Authentification vérifie la clé de Hachage, et les journaux de l'utilisateur après la base de données de vérifier
Donc, si l'Utilisateur clique sur le bouton "se connecter avec l'Authentification windows", le serveur redirige vers l'authentification windows site (en passant de la "ReturnUrl"). Ce site défis et les journaux de l'utilisateur, puis la renvoie, encore une fois en passant de la "ReturnUrl" ainsi que le HashKey.

Tout cela se passe très vite, et semble assez homogène.

Je sais que c'est une hacky solution de contournement, mais pour mon cas il a bien fonctionné.

wow, c'est un énorme solution de contournement. J'ai deux fichiers dans mon répertoire, avec différents niveaux d'authentification.
Oui, je suppose. Mais ce Hachage de la Clé de connexion est utile pour plusieurs autres pièces, telles que la synchronisation des connexions et des liens à partir d'autres systèmes. Je n'ai pas envie externe (aucun intégré) utilisateurs d'être confrontés à des informations d'identification Intégrées invite.
Alors comment faire pour les empêcher de voir que?
Par le fait d'avoir une "Connexion avec Windows" bouton en dessous de l'ouverture de session de Formulaires, de sorte que les utilisateurs externes peuvent se connecter avec les formes, alors que les utilisateurs peuvent cliquer sur ce bouton qui redirige côté serveur pour un vide de sécurité intégrés de la page, qui affiche l'invite (si nécessaire), puis la renvoie avec la clé de hachage. Le seul bit de la sécurité intégrée de la page que les utilisateurs voient jamais est la popup.
En passant, j'imagine que vous le savez déjà, mais juste au cas où, j'ai vu une solution raisonnable pour revenir à l'écran de connexion de l'autoroute 401, qui est décrit ici msdn.microsoft.com/en-us/library/ms972958.aspx.

OriginalL'auteur Paul Grimshaw

Vous devez vous connecter pour publier un commentaire.